Routing strategies

A routing strategy decides which model actually serves a request. It rewrites the model a coding agent asks for, can change its rules as a budget is spent, and says what to try when a model fails.

Strategies run in the gateway. Developers keep their agent and their configuration; a request for Opus can be served by an open-weight model without anything changing on their machine.

There are two kinds of strategy:

How a strategy works

A strategy is a list of rules. Each rule maps the model the agent asked for to the model that should serve it:

Opus (any version)    →  Kimi K3     reroute
Sonnet (any version)                 no rerouting, passes through
*                     →  DeepSeek    everything else

A rule matches an exact model, a model family (any version of Opus, for example), or * for every model no other rule matched. The most specific match wins: exact model, then family, then *. A model with no matching rule goes to the model the agent asked for.

For each target you pick the provider that serves it and, when the model supports it, a reasoning effort. On an agent with its own subscription, such as Claude Code, a rule can also stay on the subscription: the request keeps the developer's credentials and is billed to their plan, not to your Edgee account.

A rule can carry a fallback instead of a reroute: a model to use when the requested one is unavailable or returns a 429. That is what keeps a session running when a developer hits their Claude plan cap. A fallback covers the model the agent asked for, so a rule either reroutes or falls back, not both. The exception is a budget per model, where the reroute only starts at the cap.

Budgets

A strategy handles spend in one of three ways:

The budget amount set in the editor is a default. When you assign the strategy, you choose the period (daily, monthly, or all time), whether it is counted per member or as a shared pool, and you can give each squad or member its own amount. One strategy can serve several teams with different budgets.

Create a strategy

In the console, open Rerouting Strategies, click New strategy, then Manual setup.

Pick the traffic source and how spend is handled

The source (Claude Code, Codex, GitHub Copilot, all agents, or a standard API key) only decides which models the editor suggests first. It is not enforced.

Then pick No budget, Budget per model, or Budget stages.

Set the routing

Claude Code rules start from its model families, each with no rerouting. Pick a target for the models to reroute, or add a fallback. The picker shows each model's provider and price, cheapest first, with the models your BYOK keys cover at the top.

With budget stages, set the budget, drag the handles to place the stage boundaries, and write each stage's rules. Copy from stage 1 saves retyping.

Decide what happens at the cap

For budget stages only: once the budget is spent, keep routing with the last stage, or block requests until the budget resets.

Name it and assign it

Give the strategy a name, pick who it runs for, and set the budget period and counting. A strategy does nothing until it is assigned.

Smart routing

Smart routing lets the gateway pick the model. It classifies every task as low, medium, high, or max complexity and sends it to the model you chose for that level. Cheap models on the low levels are where the savings come from.

Click New strategy, then Smart routing. Pick where the traffic comes from, then a model for each level, optionally with its provider and reasoning effort, then assign it. There are no rules or budget to write. Like any strategy, it only reaches the keys of the source you picked.

For Claude Code, Codex, and GitHub Copilot, a level can stay on the developer's own subscription: turn on Stay on … in the model picker and choose among the models that subscription serves. Tasks at that level then run on the developer's plan instead of Edgee's credentials.

On every key it reaches, smart routing takes priority over any other strategy. The strategies list flags the strategies it overrides, fully or partly.

Assign a strategy

Assign a strategy to the whole organization, a squad, or one or more members. A strategy built for standard API keys attaches to the keys themselves. Each scope carries one strategy; assigning another replaces it.

Admins can assign strategies anywhere. Members can create personal strategies and apply them to themselves or their own keys. Strategies applied by an admin show as read-only to the members they cover.

When several strategies reach the same request, one wins:

1. Smart routing always takes priority over any other strategy.
2. Otherwise, the broadest scope wins: organization → squad → member → API key. An organization strategy overrides a squad, member, or key assignment.

To check a strategy is working, start a new session and look at the served model and provider in Logs.

Good to know

• A scope with a strategy cannot also carry a hard usage limit. Use a strategy that blocks at the budget instead.
• Blocking stops agents mid-task. Set an alert so the team hears about it before the budget runs out.
• A strategy can only route to models allowed by Model access.
• Editing a strategy changes routing for every scope it is assigned to.
• Self-hosted gateways in connected mode receive strategies from the console. See Self-hosting.