Enterprise capability

Per-Project Routing Overrides

Different rules for different teams, in the same org

Most teams need one routing config for production, another for internal tools, and a third for experimentation. Per-Project Routing Overrides let you set defaults at the organization level and selectively override them on individual projects. Pin your billing-system project to a single US region for SOC 2 scope. Let your research project fall back to whatever provider is cheapest right now. Override fallback ordering, region locks, cost ceilings, and model allow-lists — all from a structured config that's auditable, diffable, and version-controlled.

Why teams turn it on

Project-scoped config

Every project inherits the org default and can override any rule — region, provider priority, fallback chain, cost limits.

Region pinning

Lock a project to specific AWS / GCP / Azure regions for residency, latency, or compliance scope.

Per-project cost ceilings

Cap monthly spend per project. Auto-pause or auto-downgrade when a project's budget is hit — production is never starved by a runaway experiment.

Diffable + audited

Every override change is captured by [[audit-logs]] with a structured before/after diff. Roll back to any prior config in one click.

How it works

From decision to deployed in three short steps

  1. 01

    Set org-wide defaults

    Configure global routing rules — preferred providers, fallback order, region preferences, model allow-list.

  2. 02

    Override on the project

    In any project's Routing tab, override any subset of the org defaults. Inherited values stay live; overridden values take precedence.

  3. 03

    Inspect the effective config

    The Effective Config view shows the merged result for any project — what's inherited, what's overridden, and why.

json

Project routing override

{
  "projectId": "proj_billing_prod",
  "routing": {
    "regions": ["us-east-1"],
    "providers": ["aws-bedrock", "anthropic"],
    "fallback": "fail-fast",
    "monthlyBudgetUsd": 50000,
    "onBudgetExceeded": "pause"
  }
}

Real-world use cases

Why customers actually adopt this

01

SOC 2 scope reduction

Keep your audit-scope project pinned to us-east-1 with a single approved provider. Everything outside that scope is free to roam.

02

Multi-team isolation

Research, engineering, and customer-facing apps share an org but route independently — and bill independently.

03

Cost-aware experimentation

Cap experimental projects at $200/mo so a runaway agent loop can't burn the production budget overnight.

Frequently asked

Can a project completely diverge from the org default?
Yes. Every field is independently overridable. You can also lock specific fields at the org level to prevent project-level overrides for compliance reasons.
How do region pins interact with provider failover?
Region pins are honored during failover. If you pin a project to us-east-1, the fallback chain only considers providers/regions that match — never silently routes traffic to a different geography.

See per-project routing overrides on your real workloads

Bring a sample workload to a 30-minute call. We'll wire it up live and show you the actual experience your team will get.