Routing

Routing policies let a workspace decide which models a key may call, and what happens when the primary model is slow, failing, or over budget.

Open Workspace → Routing (workspace managers).

What a policy contains

Field	Purpose
Name	Human-readable label
Status	Active or paused
Model scope	All models, or an allow-list
Fallback mode / chains	Ordered alternatives when the primary fails
Priority	Integer from 1–1000 for conflict resolution
API key scope	Which keys this policy applies to

Suggested production setup

1. Create a policy named for the workload (prod-chat, batch-summaries).
2. Restrict model scope to the models you actually budgeted for.
3. Add a fallback chain (for example primary Claude → OpenAI → Gemini flash).
4. Bind only the production API keys.
5. Keep a lower-priority exploratory policy for staging keys.

Operational tips

• A primary model cannot fall back to itself.
• Pausing a policy immediately stops it from applying; deleting a policy unbinds its keys.
• After enabling fallbacks, use Call Logs to see which provider actually answered.
• Combine routing with key-level spend / RPM limits so a runaway loop cannot drain the workspace.

When to use routing

• You need higher availability than any single upstream.
• You want latency- or error-based failover without changing application code.
• Different keys should see different model catalogs (prod vs research).