Cost-aware failover

1. Two deployments, one alias

Under the alias chat, register two deployments (Operate ▸ Catalog):

Deployment A — provider openai-premium, upstream model of your choice, priced high (set inputCostPerToken / outputCostPerToken).
Deployment B — provider local-or-cheap (a local Ollama, Groq, or a cheaper vendor), priced low or free.

The catalog now shows chat as load-balanced ×2.

2. Cap the premium backend per-deployment

Operate ▸ Budgets ▸ Manage → add a budget on the scope with:

model = chat
provider = openai-premium — restricting the budget to one provider is what makes it a per-deployment cap
a monthly cost limit, period MONTHLY

Command

curl -s -u admin:PASSWORD -X POST https://aam.example.com/admin/budgets \
  -H "Content-Type: application/json" \
  -d '{
    "scopeLevel": "ORG",
    "scopeId": "ORG-UUID",
    "model": "chat",
    "provider": "openai-premium",
    "costLimit": 1000,
    "currency": "USD",
    "period": "monthly"
  }'

Do not put a provider-less chat budget so low that it blocks the alias outright — that aggregate cap is checked before routing and would deny the request rather than fail it over. See aggregate vs per-deployment.

Verify

Drive traffic until the premium budget is exhausted (or set it tiny for the test), then watch new calls land on the cheap backend in Govern ▸ Audit & usage — the served provider is recorded per call. The budget card's live meter in Budgets ▸ Manage shows the premium cap filling up.

Why it works

A per-deployment budget is applied by the per-candidate filter during routing: an exhausted backend is dropped from the candidate list, so the request fails over instead of being denied. A 429 happens only when every candidate under the alias is over budget.

Routing & failover — the full candidate-selection sequence, including the health-based circuit breaker you get for free on the same alias.