> ## Documentation Index > Fetch the complete documentation index at: https://www.edgee.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Routing Strategies > Reusable, budget-driven routing policies applied to an organization, a squad, or a single coding agent. A routing strategy is a named, reusable policy that decides **which model serves a request, and which provider serves that model**. You build it once and apply it to a scope — your whole organization, a squad, or one coding agent key. Where [reroute](/docs/features/retry-and-fallback#reroute) is a flat list of substitute models, a strategy is a set of rewrite rules that can **change as spend accumulates**: start on a premium model, move to a cheaper one at 60% of the budget, and optionally stop entirely at 100%. ``` Budget: $200 / month, per member 0% 60% 85% 100% ├──────────────────────┼────────────────┼───────────────┤ │ claude-opus-5 │ claude-sonnet-5│ glm-5.2 │ ← block or stay │ (anthropic) │ (anthropic) │ (zai) │ └──────────────────────┴────────────────┴───────────────┘ stage 1 stage 2 stage 3 ``` ## Two shapes A strategy is an ordered list of stages, and the number of stages decides what it is. | Shape | Stages | Budget | Behavior | | ----------------- | ------ | ------------ | --------------------------------------------------------------------- | | **Permanent** | 1 | Not required | Rules apply to every request, whatever the spend | | **Budget cap** | 1 | Required | Rules apply to every request; requests are rejected at 100% of budget | | **Budget stages** | 2+ | Required | The active stage is chosen from live spend against the budget | The console labels strategies with these three names in the strategy list. A budget is required whenever thresholds need something to resolve against — that is, for any escalating strategy, and for any strategy that blocks at 100%. A single-stage strategy that never blocks needs no budget. ## Rules Each stage holds an ordered list of rewrite rules. A rule has three parts: | Part | What it does | | ------------ | ---------------------------------------------------------------------------------- | | **Match** | The model the agent asked for — an exact `author/model` id, or `*` for every model | | **Route to** | The model to serve instead, as `author/model` | | **Provider** | Which provider serves that model | Within a stage, **the first matching rule wins**. A stage with no rules is a pass-through: requests in that stage are served as-is. The provider is a specific endpoint from the model catalog, so region-scoped entries like `bedrock_us-east-2` or `azure_eastus` are valid choices — you are pinning where the model runs, not just which vendor supplies the credentials. ## Budgets A budget is set **when you apply the strategy**, not on the strategy itself — the same strategy can run against a $50 budget on one squad and a $500 budget on another. Three things define it: | Setting | Options | | ---------- | ------------------------------------------------------------------------------------------------------------ | | **Amount** | The budget in USD. Must be greater than 0 — stage thresholds are percentages of it | | **Period** | Daily, monthly, or all-time | | **Mode** | **Per member** (the amount applies to each member individually) or **shared** (one pool for the whole scope) | A single coding agent is always shared — there is no per-member distinction for a scope of one. ### Stage thresholds Each stage becomes active at a percentage of the budget. The first stage always starts at 0%, and each subsequent threshold must be higher than the one before it. A stage is in force from its own threshold up to the next stage's, or to 100% for the last one. A strategy holds up to 5 stages, with thresholds at least 5 percentage points apart and the last one no higher than 98%. ### At 100% Once spend reaches the full budget, a strategy either keeps going or stops: | Setting | Behavior | | -------------------------- | ------------------------------------------------------ | | **Stay on last** (default) | Keep serving from the most escalated stage | | **Block at 100%** | Reject further requests until the budget window resets | Blocked requests return an HTTP 429 to the agent. ## On-error fallback A strategy can name a single fallback model, and the provider that serves it, used when the staged provider errors after normal [retries](/docs/features/retry-and-fallback#retry-behavior). This takes over error handling for the scope: while a strategy is in force, a failing request goes to the strategy's fallback model rather than down the scope's own [fallback](/docs/features/retry-and-fallback) chain. ## Creating a strategy Routing strategies are org-wide configuration, so they are **admin-only**. Non-admins do not see the Strategies section at all. Click **Strategies** in the console sidebar, then **New strategy**. Give it a name (required, max 100 characters) and an optional description (max 500 characters). Name it for the policy, not the model — `cost-controlled`, `bedrock-only`, `opus-then-glm`. Pick the model to match (`*` for everything), the model to route to, and the provider that serves it. The first stage always starts at 0%. Click **Add stage**. Its threshold lands halfway between the previous stage and 100%, and you can move it along the escalation timeline from there. A new stage starts **empty**, and an empty stage is a pass-through — give it rules, or requests in that band are served as-is. Leave it on stay to keep serving from the last stage, or set **Block at 100%** to turn the budget into a hard cap. The strategy appears in the list. Saving it does not change any traffic — nothing routes differently until the strategy is applied to a scope. ## Applying a strategy Open a strategy and use its **Apply** action. Pick the scope, then set the budget it resolves against: | Scope | What it covers | | ---------------- | ---------------------------------------------- | | **Organization** | Every request in the org | | **Squad** | Every member of that [squad](/docs/features/squads) | | **Coding agent** | One coding agent key | Assignments resolve **org > squad > key**, the same precedence as the rest of the [AI Gateway settings](/docs/features/squads#how-settings-resolve): an org-level strategy overrides a squad's, which overrides a key's. The apply dialog tells you which strategy a scope currently carries before you replace it. Assigning a strategy to a scope takes over that scope's routing: its [reroute](/docs/features/retry-and-fallback#reroute) list is ignored entirely while the strategy is in force, and error handling moves to the strategy's own fallback model. Removing the assignment restores the previous behavior. Deleting a strategy clears every assignment that referenced it, and those scopes fall back to their inherited settings. ## Monitoring The Strategies list shows live spend against budget for every scope a strategy is applied to. For a per-member budget, the figure shown is the member closest to escalating — the one whose spend will move the stage next. Individual members can see their own position without admin access: the budget in force for them, the stage currently active, and the model and provider it routes to. Routing decisions land in the logs like any other. Requests served by a strategy are flagged as rerouted, so you can tell at a glance which stage a session was running on — see [Observability](/docs/features/retry-and-fallback#observability). ## Self-hosted gateways Strategies work on [self-hosted gateways](/docs/self-hosting/overview) as well as the hosted one. A strategy assigned to your organization is included in the configuration your gateway pulls, so it picks up the same policy on its next refresh — build it once in the console and both deployments route the same way. A malformed strategy is dropped and logged rather than applied, and the key it was attached to keeps serving without it. A bad policy degrades to "no strategy" instead of failing every request on the key. ## Next steps The error-driven and unconditional routing that strategies supersede. Group members so a strategy can target a team rather than the whole org.