AI agent cost control: stop the next call

AI agent cost control means refusing the next expensive operation before it starts. A dashboard can tell you what an agent spent, and an alert can tell you that a threshold was crossed, but neither one is a wall. Put a per-run budget in front of model calls, paid tools, retries, and delegated work. The runtime should reserve money, execute only after the reservation succeeds, and commit the actual result afterward.

That distinction matters most when nobody is watching. A coding agent scheduled overnight can hit a rate limit, retry with a larger context, spawn another worker, and keep going until morning. The individual calls can look reasonable. The run is still outside its intended cost. We need a boundary that belongs to the execution, rather than a monthly provider setting or a message written in the prompt.

Figure 01 / budget boundaryAnimated trace

What does AI agent cost control mean?

AI agent cost control is request-path enforcement for an autonomous workflow. Before a model call, MCP tool, search request, code execution, or sub-agent launch, the host calculates an estimate and asks a budget ledger for permission. The ledger either reserves enough capacity or rejects the operation. The operation doesn't run when the reservation fails.

This is narrower than general AI cost monitoring. Monitoring attributes spend after it happens. Cost control makes a decision while the operation still can be stopped. Both belong in production, but they answer different questions. Monitoring asks where money went. Enforcement asks whether the next action is allowed.

A useful budget identity has several parts: the run ID, the owning team, the workflow name, the provider route, the time window, and the expiry time. Every call carries that identity. Without it, a provider-level ceiling may protect an organization while doing nothing for one runaway run. The account can remain under its monthly cap while a single execution consumes the allocation meant for other work.

Cost also includes more than model tokens. A tool can call a paid search API. A code step can create compute usage. A retry can resubmit the full context. A delegated worker can repeat the original task. If the budget only counts the final model response, the ledger is incomplete. Follow the operation path that creates the bill, not only the component that is easiest to count.

Why do alerts and rate limits fail?

Alerts are useful signals, but they aren't stops. Airia’s explanation distinguishes a threshold notification from a hard stop: the notification tells someone that consumption reached a level, while the hard stop prevents further usage after the ceiling. A human can investigate an alert during business hours. An unattended run can't wait for that investigation.

Rate limits solve a different problem. They control how quickly requests arrive, not the total amount an agent can spend. Ten requests per minute can still become hundreds of dollars across several hours if the workflow continues. A rate limit belongs in the safety system, but it can't stand in for a budget.

Provider settings also have a scope problem. A project, account, workspace, or API key limit may cover many workloads. That setting rarely expresses the amount one run can spend before it should stop. Separate keys improve attribution, yet attribution alone doesn't prevent the next call.

Application counters have a concurrency problem. Two workers can read the same remaining balance, both decide that their estimates fit, and both start. The total then exceeds the balance even though each local check looked correct. A counter stored in process memory also disappears during a crash or restart. A durable, atomic reservation is needed when several workers share one budget.

Prompt instructions are weaker still. Telling an agent to spend less is a behavioral preference, not an execution boundary. The model can misunderstand the instruction, lose it in a long context, or choose a retry that the host code performs without asking the model again. Put the decision in the host that owns the side effect.

Figure 02 / limit layersAnimated trace

How does reserve, execute, commit work?

The reserve, execute, commit pattern turns a forecast into a runtime decision. The sequence is simple, but each step needs a clear owner and an idempotency key.

1. Reserve before work. Estimate the next operation, then atomically hold that amount against the run and its parent budgets.
2. Execute after approval. Make the model call or tool request only when the reservation returns success.
3. Commit the result. Record actual usage, keep the used amount, and return any unused part of the reservation.
4. Release skipped work. Release a reservation when execution never began, while charging the best-known amount when work started before a crash.

The estimate doesn't need to be perfect on day one. It does need to be conservative enough to protect the boundary, and it needs measurement afterward so the estimate can improve. Treating an expired reservation as proof that nothing happened is unsafe. A process can die after the provider accepted a request, so reconciliation must account for uncertain outcomes and use an idempotent record.

Fan-out needs the same parent identity. If an orchestrator starts five workers, each worker should reserve against the shared workflow budget. A child may also have a narrower local ceiling. What matters is that the parent balance can't silently multiply when workers start in parallel.

When a reservation fails, return a structured stop reason. The agent can then choose a defined degradation path, such as reducing optional context, selecting a cheaper route, deferring a nonessential tool, or ending with a partial result. The host mustn't turn a budget rejection into an automatic retry, because that would bypass the boundary.

type BudgetDecision =
  | { allowed: true; reservationId: string; amount: number }
  | { allowed: false; reason: 'BUDGET_EXCEEDED' | 'BUDGET_EXPIRED' }


async function callWithBudget(input: Request, ctx: RunContext) {
  const estimate = estimateCost(input)
  const decision = await ledger.reserve({
    runId: ctx.runId, parentId: ctx.workflowId, amountUsd: estimate, idempotencyKey: ctx.attemptId,
  })


  if (!decision.allowed) return { status: 'stopped', reason: decision.reason }


  try {
    const result = await provider.call(input)
    await ledger.commit(decision.reservationId, actualCost(result))
    return { status: 'complete', result }
  } catch (error) {
    await ledger.commit(decision.reservationId, bestKnownCost(error))
    throw error
  }
}

This example leaves provider details out on purpose. The important property is the order. The host gets a decision before the provider call, and the ledger receives a settlement even when the operation fails. A production implementation also needs reservation expiry, duplicate protection, audit records, and a policy for estimates that exceed the reserved amount.

Which limits should each run have?

Use more than one limit because each one catches a different failure shape. A per-run dollar ceiling controls the financial blast radius of one execution. A token ceiling controls the amount of model context and output. A step ceiling bounds the number of iterations. A wall-clock timeout limits how long a stuck run can remain active. A tool policy limits which paid or side-effecting operations are even eligible.

The per-run dollar ceiling should be the first hard boundary for an unattended job. It follows the actual execution and can include model, tool, and delegated-worker costs. Choose a value from observed runs rather than a guess. Start with a narrow workload, record the cost distribution, and leave room for ordinary variation without allowing an unbounded tail.

Token limits still matter because dollars can hide context growth. A cheaper model can process a very large prompt and make a run slow, hard to inspect, and more likely to repeat work. Set input and output limits by step. Keep retrieved data and tool payloads scoped to the task. Our article on MCP token optimization covers why full tool schemas can become a recurring part of the bill.

Step and retry limits are behavioral brakes. They should distinguish a normal retry from repeated failure of the same class. Three retries for three independent transient failures is different from three retries of an unchanged request that always returns the same error. Record the reason, not only the count, so the next review can change the workflow rather than merely raise the ceiling.

Team and global budgets provide the outer layers. Airia describes a hierarchy from an organization ceiling to team or project allocations and then individual caps. That structure helps prevent one group from consuming a shared pool, but it shouldn't replace the per-run decision. The outer limits answer who owns the allocation. The inner limit answers whether this operation can proceed now.

Keep credentials and permissions separate from budget policy. An API key can be valid while the run is over budget. A sandbox can be isolated while the workflow is spending too much. The safest boundary combines identity, permission, budget, and expiry in one request context. Our piece on headless Claude Code covers the related permission and scheduling concerns for unattended coding work.

How should you roll out enforcement?

Start with one expensive or high-risk operation, not the entire agent fleet. Choose the model call that dominates cost, the paid tool that creates the largest bill, or the side effect that's hardest to undo. Give it a run identity and log a decision without blocking anything. This shadow phase shows how often the new policy would deny work.

Compare estimates with actual provider receipts. If estimates are always far below actuals, the boundary isn't protective. If they are far above actuals, ordinary runs will stop early. Keep separate measurements for model input, model output, tool fees, and infrastructure. A single blended number hides which estimate needs work.

After shadow data looks credible, enforce the one operation. Test four cases deliberately: an ordinary successful call, a rejected reservation, a provider error after acceptance, and two concurrent calls competing for the last balance. The test isn't complete when the ledger says no. It's complete when the provider call doesn't happen and the run records a useful stop reason.

Then widen the boundary in stages. Add retries, tool calls, worker fan-out, and finally the entire workflow. Keep the first fallback simple. A cheaper model, a smaller context, or a deferred optional step is easier to reason about than a complex recovery graph that can spend more while trying to save money.

Scheduled runs need a visible operator path. Store the schedule ID, run ID, budget policy, start time, finish time, and stop reason. Send a result that says whether the job completed, stopped for budget, timed out, or failed elsewhere. Without that record, a morning review can't tell whether an empty result means no work existed or the budget protected the system.

Orca runs agents in isolated cloud sandboxes, so the execution boundary can include a fresh workspace, scoped credentials, and metered run identity. That doesn't make budget enforcement automatic. It gives us a place to enforce it before tools and model calls leave the run. The same boundary can work in a local worker, a CI job, or a hosted scheduler.

What should you measure afterward?

Measure the control itself, not only the total bill. The first useful metric is reserved versus committed cost. A widening gap means estimates need work or the workflow has changed. Next, track rejection rate by workflow and reason. A high rejection rate can mean the budget is too small, or it can reveal a retry loop that was previously invisible.

Track time to exhaustion. A run that uses its entire budget in seconds has a different problem from one that reaches the ceiling after a long productive session. Record spend by model, tool, team, workflow, run, and attempt. Attribution lets you change the path causing the cost instead of applying a larger limit to every path.

Track degradation outcomes. Did the run finish with a cheaper model? Did it skip an optional search? Did it produce a partial patch that needed review? A hard stop is safer than an open-ended loop, but a planned fallback can preserve useful work. Review those outcomes with completion quality, not cost alone.

Finally, connect cost to a unit of work. For a coding agent, that might be a reviewed change, a passing test suite, or a completed issue. The unit must be defined by the team and measured honestly. A lower token bill isn't an improvement if it creates more review work or leaves every run incomplete. Our discussion of agent applications and infrastructure makes the same separation between the task experience and the system that executes it.

Dashboards remain useful. Alerts remain useful. They become much more useful when a hard boundary has already prevented the next unwanted call.

Frequently asked questions