Fallbacks & Sticky Routing — ML Junction docs

Fallback policy

Field · Range/default · Meaning
provider · true · Allow fallback to another provider route
model · true · Allow configured model-family fallback
max_total_attempts · 1 through 10; default 5 · Hard limit across retries and fallbacks
max_retries_per_route · 0 through 3; default 1 · Retries allowed on the same route
same_or_lower_price · false · Reject a more expensive fallback
preserve_context_window · true · Reject routes that would reduce required context capacity
preserve_privacy · true · Reject routes that weaken the selected privacy posture
max_price_increase_percent · 0 through 1000 · Bound the fallback price increase

Sticky routing

Sticky routing keeps related requests on the same healthy route when possible. This improves behavioral consistency and can improve provider-side prompt-cache reuse. Health and policy checks still override affinity.

Field · Values · Meaning
enabled · true or false · Enable affinity
scope · conversation, api_key, custom · How requests share an affinity assignment
affinity_key · String up to 200 characters · Required for a custom affinity domain
ttl_seconds · 60 through 86400 · Affinity lifetime; default 3600

Sticky routing is a preference, not an availability guarantee. A disabled, unhealthy, circuit-open, or capability-incompatible route must be bypassed.

Continuation affinity and fallback

A valid reasoning continuation token is stronger and more exact than ordinary sticky routing: the origin route, provider model, and eligible provider account are tried first so provider-native state is only replayed where it belongs. It still does not disable the platform fallback plan. If the origin is missing, unhealthy, uncredentialed, or fails, native replay is removed and the remaining eligible candidates continue from visible history.

Expired continuation affinity degrades immediately to normal routing with REASONING_CONTINUATION_EXPIRED.. Missing route/provider/account degrades with PRIOR_REASONING_NOT_REUSABLE.. A provider failure can advance to the next candidate after configured same-route retries.. Explicit provider/route constraints, allow-lists, disabled fallbacks, capability requirements, privacy rules, and charge caps are still enforced.. The provider that successfully completes the fallback response becomes the origin of the newly returned continuation token.

Canonical URL: https://mljunction.com/docs/fallbacks-sticky