Routing strategies

A strategy defines which model serves a request and what to try if that route fails. It can apply continuously or change in stages as a budget is consumed. Saving a strategy does not change traffic. Assign it to a scope to activate it.

​

Create a strategy

Open Rerouting Strategies and start a new strategy. Choose your goals in the wizard: substitute models, use open-weight models, add backups, or cut cost as the budget burns. Continue to configure the policy, or choose Skip — start from a template.

1. Choose a template or answer the wizard’s questions.
2. Give the policy a descriptive name, such as Platform cost guardrail.
3. Review each model match, destination model, and provider. Templates are starting points: check model access and credentials for your organization.
4. Configure error fallbacks and, for a staged policy, budget thresholds.
5. Choose whether to continue on the last stage or block when the budget reaches 100%.
6. Save, then apply the strategy to the intended scope.

​

Rules and matching

A rule matches an exact model, a model family, or * for all models. Exact model matches take priority over family matches, which take priority over *. A rule selects the destination model and provider. A stage without a matching reroute passes the original model through. Where offered, configure reasoning effort and subscription reuse. Subscription reuse only applies to compatible routes; it does not guarantee that every fallback is covered by a provider subscription. Check the served route and billing mode in Logs.

​

Budgets and stages

For example, with an illustrative $200 monthly shared budget, a 70$140. The first stage starts at 0%; later stages take over at their thresholds. The editor allows up to five stages. A strategy can suggest a default budget. Review the effective amount, period, and mode when applying it; the same policy can serve scopes with different budgets.

• Daily, monthly, or all-time: the accounting window.
• Per member: each member has their own amount.
• Shared: the scope consumes one pool.
• Stay on last: continue with the final stage after the budget is consumed.
• Block at 100%: reject further requests when the budget is exhausted. An all-time budget does not have a periodic reset.

​

On-error fallback

Configure backup models in the order they should be tried. Strategies support rule-specific fallback, stage fallback, and a strategy-level ordered error fallback chain. Review the editor’s available controls rather than assuming a reroute automatically has a backup. The strategy replaces the effective scope’s legacy Fallback & Reroute lists. With no eligible backup, the request can return an error. See Retry and fallback.

​

Apply and verify

1. Use the strategy’s Apply action and select the organization, squad, member, or coding agent offered to your role.
2. Review the assignment’s budget and resolved stage amounts.
3. Apply it and confirm that the scope appears in the strategy list.
4. Launch a new session and inspect its served model and provider in Logs.

Assignment precedence is organization → squad → member → key. An organization strategy takes priority over a squad or individual assignment. Review inherited settings before changing a lower scope. The list shows assignments and budget consumption. For a per-member budget, the displayed member closest to the threshold helps identify who escalates next; it is not a shared team balance.

​

Change or remove a strategy

Editing an assigned strategy affects the scopes using it. Check its assignments before saving a change. Remove a scope’s assignment to return to inherited routing; deleting a strategy removes its assignments. Recheck a fresh request after either action.

​

Self-hosted gateways

Connected licensed deployments receive organization configuration. For headless deployments, configuration and usage synchronization need separate setup. Do not assume hosted budget enforcement works without current usage data; see Self-hosting.