Cost control

Six levers, in order of impact.

1. Allowed models

Workspace → Routing → Allowed models. The single most effective cap — a developer can't accidentally swap to gpt-4-turbo and 10× the bill.

2. Budgets

Two layers, both checked per request — stricter wins:

• Workspace → Budget — per-workspace daily/monthly cap.
• Tenant admin → Spend cap — global ceiling summed across every workspace in the tenant. Tenant admins only.

At 100% the gateway returns 402 budget_exhausted and your callers see a clean error instead of a vendor bill.

3. Cache

Workspace → Cache → enable. Identical requests (same model, messages, params) return instantly with x-airouter-cache: hit, billed at $0. Massively reduces cost on retry-heavy or idempotent flows.

4. Right-size the model

Use the smallest model that solves the task. odnoga shows cost-per-request in Overview and per-request in Requests — sort by cost and look for the obvious outliers.

5. Cap tokens

Always set max_tokens (or max_output_tokens). Without it, a run-away vendor can produce 100k tokens for one prompt.

{ "model": "gpt-4o-mini", "max_tokens": 512, "messages": [...] }

6. Batch the offline work

Anything that does not need an answer in seconds — backfills, re-classification, bulk embeddings — belongs on /v1/batches, not in a loop over /v1/chat/completions. Eligible jobs are handed to the vendor's own Batch API at a genuine 50% discount (OpenAI, Anthropic and Google are live); jobs that can't take the vendor route run on odnoga's queue at standard rates with the reason in fallback_reason — you are never billed a discount that wasn't obtained, and per item billed_tier in the results shows what each row was actually charged. Track jobs in Workspace → Batch jobs. The full contract (per-vendor endpoints, windows, caps) is in the MCP batches.guide tool.

Alert on burn rate

Workspace → Alerts → add a budget_80 subscription. Resend email lands at 80% so you don't first hear about it at 100%.