Skip to main content

Steer a Team Through a Route

Tasks

Name a route on an Access Binding's model grant so the binding's subjects reach that route for the granted models. For how grants and routes interact, see Access Bindings steer routing.

This example sends the platform team's claude-* requests to Amazon Bedrock, while everyone else keeps using Anthropic.

Before you start​

  • Add both providers. See Add a provider.
  • Make sure a route serves the models for everyone else: here, a route named claude with the model pattern claude-* and the Anthropic provider as its member.
  • Add the route the team should use, for example claude-bedrock with the Bedrock provider as its member. Each model pattern belongs to one route, and callers without a grant that names a route use the most specific route. So give the team's route a pattern that matches the same models but is less specific, such as claude*: everyone else keeps reaching claude (claude-* is more specific), and only grants that name claude-bedrock reach Bedrock. A grant steers to a route only for models its patterns match. See Add a route.
warning

While no Access Binding grants any model, every caller may use every model. The first binding that grants a model ends that: from then on, a caller with no grant for the requested model is refused with MODEL_DENIED. Before you save the team's binding, add a binding that grants the models to Everyone (or to every team that needs them), with no route.

Grant the models through the route​

  1. Go to Settings → Access Bindings and open the team's binding, or create one.
  2. In Applies to, add the team. You can also add groups, users, agents, or agent labels.
  3. Under Advanced, keep the decision mode Allow. Only an allow-mode grant can name a route.
  4. In Models, add the models to grant, such as claude-*. Each grant appears as a row with a Via route list.
  5. In Via route, pick claude-bedrock. The list offers only routes whose model patterns cover the grant's model. Leave it empty to use the most specific route, shown as Most specific route (…). A saved route that no longer serves the grant's models shows (no longer served) after its name; pick another route, because saving it is refused with 400.
  6. Check Other model limits for these callers. It shows, read-only, the org ceiling, the team's model scope, the users' personal access token scopes, and agents' virtual-key allowed models. A model those limits exclude stays blocked whatever the grant says. Use its Edit links to change a limit where it lives.
  7. Save. The save is refused with 409 route_grant_conflict if another binding grants the same subject the same model pattern at the same level through a different route; the error names that binding. Remove one of the two routes and save again.

The grant applies on every replica as soon as it's saved.

Verify​

  1. In Settings → Providers, select Test routing.
  2. Enter the model, such as claude-sonnet-4-6, pick the team in Team, and optionally enter a team member's email in User.
  3. Check that the result shows route: claude-bedrock and Granted by binding with your binding's name, followed by the route and provider the request would use without that grant.
  4. Clear Team and User and check that other callers still reach the Anthropic route.

On the Routes tab, the route's Granted by column lists the binding. In the audit log, the team's requests show the route as routeName.

Precedence​

When several grants cover one caller and model, a grant through the caller's workload wins over one through its Workload Blueprint, which wins over a team, group, user, agent, or agent-label grant, which wins over an Everyone grant. A workload's Blueprint can therefore name a different route than its owning team's binding. See Access Bindings steer routing.

See also​

Last updated on