Choose the right cost control for each workload
Enterprise Tier
Three cost controls divide the work, and they are not interchangeable: budgets cap what a team or a person spends over a period, rate limits enforce traffic ceilings inline at the gateway, and Usage Analytics is where the spend behind both becomes visible. Picking the wrong one leaves the weekend benchmark, the over-eager agent framework, and the leaked credential all unprotected.
Budgets are created at Usage → Budgets in the Admin Console; they track cumulative spend against a daily, weekly, or monthly limit and raise an alert as it is approached. Rate limits are the only control that rejects requests today. The API-key-per-purpose convention established in Onboard developers and issue keys is what makes all three precise rather than blurry. For how the three fit together as stages, see Cost and quota management.
Persona: Platform operator working in the Admin Console, often in partnership with the developer teams that own specific API keys and the finance owners who set spend ceilings.
Estimated time: 10 minutes to read; the linked guides carry their own estimates.
Match the situation to the control
| Situation | Control that fits |
|---|---|
| A production application's spend should not exceed a known monthly ceiling | A budget, with monitoring on a cadence |
| A research or evaluation team should not run away with the bill | A budget to track spend and alert plus aggressive rate limits on dedicated keys for the inline hard stop |
| Each team's spend should be attributable for chargeback | Per-team keys with chargeback statements per cycle |
| Spend must be booked against an app or project that does not map to a user or team | Caller-set attribution tags |
| Overall spend across all consumers needs to stay under a contractual ceiling | Sum of per-key limits, plus alerting on the aggregate |
| A leaked credential needs to be bounded in damage even before it is revoked | A rate limit at the consumer's known traffic level, then containment |
For Bring Your Own Key (BYOK) consumers (developers who present their own provider credentials, as described in Use your own provider credentials), spend is attributed to the BYOK provider account directly, not to Agent Router's own usage records. The budgeting concerns there are a matter for the team that owns the BYOK account; the controls on this page cover centrally managed traffic.
Hard ceilings or soft monitoring
There are two ways to use these mechanisms, and the right choice depends on the consumer. The distinction is not a setting on a single control: an inline hard stop comes from a rate limit, while a budget is always soft monitoring, because measuring spend is the whole of what a budget does. Making a spend ceiling hold takes a budget policy attached to the budget, which refuses the caller once it is exhausted. Budget policies are planned for the 2026 Q3 release.
| Strategy | What it does | Control that provides it | When to use it |
|---|---|---|---|
| Hard ceilings | Limits enforced inline; requests beyond the ceiling are rejected | Rate limits | Experimental or CI keys where a runaway should be cut off automatically; any path where unbounded throughput is unacceptable |
| Soft monitoring | Spend tracked against a ceiling, with Usage Analytics watched actively and alerts wired to someone who acts | Budgets and Usage Analytics | Production workloads where a false-positive block would be worse than occasional overspend; accountability and forecasting against an agreed number |
Most deployments end up using a mix. Production keys for critical applications rely on budgets for soft monitoring, because a sudden block cascade is the wrong failure mode for them. Research, evaluation, and CI keys add rate limits for a hard ceiling, because a runaway there is more annoying than a rejection.
Rate limit or budget
The two ceilings are easy to conflate, but they answer different questions and operate on different axes.
| Budget | Rate limit | |
|---|---|---|
| Controls | Total spend over a period, tracked with alerts | Request or token throughput over a short window, flow control |
| Unit | Money, per budget period (daily, weekly, or monthly) | Tokens, requests, or parallel calls, per short window |
| Where it acts | In the management plane, against aggregated request logs, so it lags the spend by minutes and fails open | Inline at the gateway, on the request itself |
| Scope | A team, each teammate, or one person | An API key, user, group, or model |
| Question answered | "How much has this person or team spent this period, and how near is the ceiling?" | "How fast may this credential consume right now?" |
| Enforcement | Never by itself; the budget measures and alerts, and a budget policy attached to it refuses the caller | Inline at the gateway; requests over the ceiling are rejected |
| Failure it surfaces | A cumulative overrun, flagged as spend approaches the ceiling | A burst or runaway happening in real time |
A rate limit set generously can still allow a month-long drift that quietly exhausts a budget; a budget can be intact while a single misconfigured key bursts hard enough to need a rate limit. The two are configured to complement each other: the rate limit blocks the fast runaway at the key, and the budget flags the slow accumulation at the user or team so someone can act on it. Most workloads warrant both.
The cost-control guides
Catch spend drift before the invoice does
The regular usage review that surfaces slow cost creep while it is still cheap.
Set a budget and track spend against it
Turn a number agreed with finance into a budget that tracks spend and alerts as the ceiling nears.
See budget exhaustion coming in time to act
Read budget burn, headroom, and the members driving it, in time to intervene.
Raise a spend ceiling without interrupting delivery
Raise the ceiling for a team that legitimately outgrew it, and keep the change auditable.
Split the AI bill across the teams that caused it
Chargeback and showback statements finance can load into its own systems.
Know what every app and project actually costs
Caller-set tags add the app and project axis the user and team dimensions cannot express.
Stop runaway workloads before they burn the budget
Token, request, and concurrency limits that wall off retry storms and fan-out bursts.
Get alerted to cost spikes as they happen
Telemetry export into the observability stack, with alert rules instead of dashboard-watching.
Contain a leaked key before it drains the budget
The incident response: bound the damage, revoke the credential, pause the workload.
Control request log data
The logging modes behind the usage data every control on this page depends on.