An agent's bill is not the bill for "a call." It is the bill for a sequence of calls, each with its own context, and the total is usually driven by the shape of the sequence, not by any single flashy request. This is an anatomy of that bill: four line items, and a lever for each.
The breakdown uses the failure patterns described in a community thread where agent bills landed several multiples of the equivalent one-shot chat usage. The numbers are illustrative; the structure is what transfers.
Line item 1: the planner
The planner runs at the top of every loop iteration: in, "here is the state; what is the next step"; out, a decision. Its context is the smallest thing in the run, but it repeats — a twenty-step run makes twenty planner calls. In a single-threaded agent it is usually a modest share of total spend, and it is also the first candidate for tiering: a mid-tier model makes routing decisions that a frontier model is overqualified for.
Line item 2: the workers
The workers execute the plan: file edits, test runs, generated responses, API calls. Each worker call carries the full context at that point in the run — system, tool definitions, history, tool results — and this is where input/output mix dominates, because workers are the output-heavy steps (code, prose, diffs). On an output-weighted mix at frontier-class rates, the workers can hold 40-60% of a typical agent bill. The levers that apply are all of them: context budget, tier, and the question of which steps actually deserve the frontier class.
Line item 3: the context, billed every step
The context itself is a line item, not free metadata: it is input tokens, re-sent on every single step. By step 30 of a run, the step-30 request contains steps 1 through 29 — the run pays quadratically for a history that is mostly settled.
Two levers matter. Compress the history: summarization checkpoints, dropping stale tool results. And put the stable prefix (system + tools) on prompt caching, so the re-sent part reads at a fraction of full input price. Both halves matter equally, because a cache that silently stops engaging — format drift, a forked session, truncating a request mid-stream — quietly re-prices the whole line at full rate for the rest of the run.
Line item 4: rework
Rework is the line nobody budgets for: retried steps, redone plans, verification passes that fail and trigger rework passes. A run that fails at step 18 and restarts from step 1 pays for the first seventeen steps twice — with a larger context the second time. In rough shape, rework holds 15-30% of real agent workload bills. Its levers are not model selection; they are stop conditions: per-step budgets that fail clean, verification on a smaller model, retries that honor ceilings, and harnesses that do not blindly restart from scratch.
The levers, in order of impact
- Tier the model per step class. Plan on the top model, execute on the mid tier, verify on a small one. The same routing-strategy logic as for a single query — policy by step class, not policy by habit. Enforcing the tier at the endpoint, per task class, beats leaving it to whichever model an agent picks at 3 a.m.
- Budget the context and cache what is stable. Checkpoints plus a cached stable prefix turn the quadratic prefix cost into a linear one. Capacity is not the interesting part; the cost-side variable is cache hit rate, and cache hit rate is an ops metric, not a model attribute.
- Pay batch rates where latency allows. Verification sweeps, bulk classifications, non-interactive rework — all candidate for a 24-hour batch API at roughly half price. The metric to compute: what fraction of your step volume could tolerate that SLA?
- Bound rework with per-task budgets. The stop condition is the only lever that constrains the line item no model can fix.
The metric to keep is $ per task, not $ per request and not $ per month: the request count is what the agent decides, the month is what the calendar decides, and only the task is what you decide. When $/task drifts while the task shape does not, one of the four line items is growing — and a log grouped by step and model will tell you which one.
Live per-token rates by model class are in the model catalog; the mechanics of keeping the whole sequence at those rates — tier per step, prefix cached, stop conditions in place — are in the docs.