Routing & fallbacks

Define a primary route, a compatible fallback, and a bounded retry policy.

Define the capability contract

Before assigning a fallback, list the inputs, output schema, and tools the application requires. Both the primary and alternative model must satisfy that contract. Otherwise a successful HTTP response may still be unusable.

Workspace routing preferences

Choose a default model in Routing. PrismHub manages the connection to your selected model. Where available, routing preferences and up to three fallback models appear in your workspace. An explicit model choice takes priority; requests already producing output are not restarted.

Use a bounded policy

The example below is application-level pseudocode, not a PrismHub request parameter. Implement the policy in your orchestration layer or map it to the features of your configured gateway.

Application policy · illustrative configuration

{
  "primary_model": "your-primary-model",
  "fallback_model": "your-compatible-alternative",
  "deadline_ms": 30000,
  "max_attempts": 2,
  "retryable_statuses": [
    429,
    500,
    502,
    503,
    504
  ],
  "never_retry_unchanged": [
    400,
    401,
    403
  ]
}

Classify, then act

Return validation and credential failures to the caller for correction.
Respect a provider’s Retry-After guidance where available.
Check the remaining deadline before starting another attempt.
Record each attempt under a shared application request identifier.

Protect tool side effects

A repeated model request can generate a repeated tool call. Keep deduplication, idempotency, and authorization in your application. Never assume a model fallback makes an external action safe to repeat.

Try the routing explorer