A deterministic fallback path.
This workbench is an illustrative deterministic fallback demo, not a live optimizer. In a deployment, Relays filters candidates for protocol, endpoint, tools, credentials, and profile coverage before selecting a route.
Route policyIllustrativeSummarise a support thread. Needs tool calling.
Routes are pinned to a region when you define them. A route outside the rule is never attempted.
Rate-limited routes are attempted, fail, and hand off to the next eligible route.
Your approved order
zhipu/glm-5.3tool calling · structured output · EU pinSelectedFirst eligible route in your order
moonshot/kimi-k3tool calling · structured output · long context · EU pinNot reachedThe order settled before this route
openai/gpt-5.6-lunatool calling · vision · structured output · US pinNot reachedThe order settled before this route
- anthropic/sonnet-5tool calling · vision · structured output · long context · reasoning · US pin
Not reachedThe order settled before this route
- openai/gpt-5.6-soltool calling · vision · structured output · long context · reasoning · US pin
Not reachedThe order settled before this route
- anthropic/fable-5tool calling · vision · structured output · long context · reasoning · US pin
Not reachedThe order settled before this route
Route receipt
SyntheticSelected
zhipu/glm-5.3
First route in your order that cleared every capability and policy rule.
- Request
- Summarise a support thread
- Attempts
- 1
- Skipped by rule
- 0
- Tokens
- 1,840 in · 512 out
- Region pin
- EU
Selected zhipu/glm-5.3 after 1 attempt and 0 skipped routes.
Synthetic policy, synthetic figures. Nothing on this page reaches a provider.
One profile, three operating choices.
The router uses Jev for a bounded task-domain distribution and a versioned benchmark-informed profile for model estimates. The profile is evidence for a routing decision, not a guarantee of task success.
| Mode | How it chooses |
|---|---|
| Performance | Choose the highest estimated quality among eligible, profiled candidates. |
| Cost | Choose the lowest estimated request cost within the configured quality tolerance. |
| Speed | Choose the lowest measured latency within the configured quality tolerance; unknown latency stays unknown. |
Fallback without the rewrite.
When a provider fails or rate-limits, the next eligible route runs. You approved the order before the incident, so nothing in your application changes during one.
- One client call
Your SDK, your model alias, unchanged.
- zhipu/glm-5.3
Failed. Rate limited, 429.
- moonshot/kimi-k3
Accepted. Next eligible route in the order.
- Same shape, same stream
No client rewrite, no redeploy.
Illustrative walk · synthetic providers and statuses
The second attempt parses like the first.
A fallback changes the provider, not the response contract. The code that parsed attempt one parses attempt two, with no branch for which route answered. Streaming, tool calls, reasoning and prompt caching all survive the handoff.
First attempt returns
Second attempt returns
Every route leaves evidence.
A route is only defensible if you can read it back. Every decision, attempt, token count and estimated cost stays attached to the request that caused it.
- Decision
- Which route ran and the rule that put it first.
- Attempts
- Every route that was called, in order, with the status it returned.
- Cost
- Tokens and estimated cost, tied to the request that caused them.
- request
- req_8f2c41d0
- workload
- Refactor an auth middleware
- policy
- long context · tool calling
- zhipu/glm-5.3Skipped, no long context
- moonshot/kimi-k3Failed, rate limited 429
- anthropic/sonnet-5Selected, 200 accepted
- tokens
- 31,204 in · 2,916 out
- est. cost
- $0.012
Start with the workflow, not the route.
Bring us the process, examples, systems, and approval boundary. We will configure the infrastructure it needs.
