TL;DR
Agent bills usually arrive as monthly totals by model or person, so nobody can see which tasks, retries or oversized models drove them. Tag usage with the task, read each retry for its cause before paying for another, match the model to the step while keeping tests and review, and judge the policy by cost per accepted change, not by total spend. Run it as a pilot with provider usage and review time recorded; the tools give you the data, not the verdict.
The bill arrives as one number
A coding agent's spending is usually reported like a utility bill: one monthly total, perhaps split by model or person. It cannot say which task cost the most, how much went on attempts that were thrown away, or whether a large model did work a small one could have done.
In March 2026 a developer asked on Hacker News how others keep coding agents from burning money. Their agents retried more than they should, and every tool they tried showed only aggregate usage: total tokens, total cost, maybe per model. They had built a thin logging layer so each request carried the agent, task, user and team. The post links to that layer, so it is interested-party evidence, but the question stands on its own.
In September 2026 a Cursor user asked on the Cursor forum whether they could see, per chat, which steps counted against their usage, and cap agent mode so one session could not use up the month. A Cursor staff reply said each agent turn is one usage row rolling up many model calls, with no per-chat grouping or per-session limit yet.
Both want spending tied to a unit of work someone can judge.
Tag the spend with the task before you cut it
Cutting cost before you can attribute it tends to cut the visible spending, not the wasteful kind. First make every model call carry the task it served:
- Claude Code can export OpenTelemetry events. Each API request event carries an estimated
cost_usd, the model, aprompt.idlinking every call made for one prompt, and the subsystem or subagent that made the call (query_source). Custom attributes such as a team or cost centre go inOTEL_RESOURCE_ATTRIBUTES(Claude Code monitoring). Figures are computed at list price unless an administrator configures the organisation's rates. - Codex has OpenTelemetry export settings, including an environment tag for the events it emits (Codex configuration reference).
- Cursor exposes per-request usage events with user, model, token counts and charged amount through its Admin API on Enterprise plans, according to a staff answer on the Cursor forum.
None of these knows your ticket numbers. A workable convention is one session per task, with the ticket ID in the session's attributes or recorded beside the session ID, and an outcome recorded when the task closes: accepted, reworked, reverted or abandoned. One caution: the attempt count in Claude Code's API telemetry counts transport retries of a single request. An agent patching the code a third time shows up as more turns and tool calls on the same task, visible only when calls are grouped by task.
Read a retry before paying for the next one
Some retries are the work: the agent reads a real failure, fixes it and gets further. Others repeat the same failure at full price. Grouped by task, the attempts usually show which.
What a run of retries is telling you
| What the attempts look like | Likely cause | Next move |
|---|---|---|
| The failing set shrinks, and checks that passed keep passing | A solvable defect | Let it continue up to a round limit set in advance |
| Broad file reading, a change of approach, rework after review | A thin or ambiguous brief | Stop and rewrite the task with files, expected behaviour and a stopping point |
| The same failure twice with no progress | Missing information, an environment fault or a flaky check | Stop; get the missing fact or fix the environment, then restart |
| It needs a decision, access or a judgement nobody has written down | A task unsuited to the agent | Hand it to a person or split out the part the agent can do |
A failing set that only changes is not progress: when each fix breaks a check that was passing, the agent may be oscillating. And know whether the round limit is enforced by the tool or only instructed; an instructed limit holds only if the agent follows it.
The brief matters more than it looks. A preprint published in August 2026 (Smékal, arXiv) ran 2,700 agentic coding runs with one model at three thinking-effort settings and found that reducing a full task specification to a bare user story raised token spend by 29.7%. It is one author, one model and a limited task set, so treat the size as indicative. GitHub's Copilot guidance makes the same point without a number: vague prompts lead to retries and scope drift, and a clear stopping condition reduces runs (GitHub, optimizing AI usage).
Match the model to the step, not to the person
The large model is often the default because someone picked it once. The main tools let you set a model per step:
- Claude Code's documentation recommends Sonnet for most coding and Opus for complex architectural decisions, and suggests
model: haikufor simple subagent tasks. Itsopusplansetting plans with Opus and executes with Sonnet, and administrators can restrict selectable models withavailableModelsor cap effort withmaxEffortLevel(Claude Code costs, model configuration). - Codex sets
model_reasoning_effort, a separateplan_mode_reasoning_effort, and a default model and effort for spawned subagents. - GitHub advises planning with a strong reasoning model and implementing with a cheaper one, using lighter models for routine, well-scoped changes, and not switching models mid-session, because a new model cannot reuse the previous one's cache.
Two rules keep this from lowering quality. Escalate on evidence: when the smaller model fails the same check twice, first rule out what a larger model cannot fix, such as a broken environment, missing access or an unclear requirement, and only then move the task up a tier with the failure attached. And never downgrade the verification. Running the tests, the linter and the build costs little in model terms; the review of a risky change is where a strong model or a person pays for itself. The article on stopping an agent stuck in a fix, break, fix loop gives stop rules that work as the escalation trigger.
Caps that stop a run without hiding the cause
Each limit stops something different. GitHub describes Copilot's AI credit session limits as soft limits that stop a single session cleanly and let the person decide whether to continue; budgets and spending limits govern the month. Claude Code's documentation lists workspace spend limits for API organisations and organisation, group or member spend limits for Team and Enterprise plans. In Cursor, per the staff answer above, leaving on-demand usage off makes the plan's pool the hard cap, and the monthly spend limit applies only to on-demand usage. The provider enforces these. A round limit in a brief or agent instructions differs: the agent is told to stop, and nothing else stops it.
A cap that trips should record which task tripped it and why; otherwise a team learns to open a new session and try again, hiding the spending rather than reducing it. For the context side of the same problem, the article on reducing coding agent context without hiding what the agent needs covers what to trim and what to keep.
Judge the policy by cost per accepted change
For a pilot, pick one team for a few weeks and record, per task, provider usage and reviewer time. Anthropic's documentation suggests a pilot group to establish a baseline before a wider rollout, and gives an average of around $13 per developer per active day across enterprise deployments, which is a vendor figure, not a target.
- Cost per accepted change: provider usage for all tasks divided by the changes that were merged and stayed merged, with reviewer minutes per accepted change reported beside it. Combine the two only through a loaded hourly rate stated with the figure.
- Share of spend on abandoned or reverted tasks: the clearest measure of retries that bought nothing.
- Escalations and their outcome: how often the smaller model was enough, and how often the escalation succeeded.
- Quality held steady: reverts, escaped defects and review findings, so that a falling cost is not paid for later.
If spend falls while accepted changes fall too, or review time rises, the policy is suppressing usage.
Paqad, the free, MIT-licensed framework this site publishes, works on the avoidable part of the effort rather than on the bill. Each skill and agent it ships declares a model tier, and its deterministic work (checks, rule scripts, validation, records) runs as scripts that spend no model tokens. Its feature-development workflow instructs the agent to stop the build, check and fix loop after a lane-scaled number of rounds, or sooner when rounds stop making progress, and to report once; that is an instruction, not a mechanically enforced cap. Paqad is not a usage meter or spending limit, and this proves no saving. Whether a declared tier reaches a particular model depends on your AI tool, as Paqad's skills page explains.
Frequently Asked Questions
How do we control AI coding costs when agents keep retrying or using large models for small tasks?
Treat it as a measurement problem first and a limits problem second. Once usage is grouped by task and outcome, the expensive pattern is usually visible within a week or two, and the fix is often a better brief or a different default model rather than a lower cap.
Can we attribute usage to tasks, stages and unsuccessful attempts rather than just monthly totals?
Yes, if you supply the task identity yourself. Prompt and subagent identifiers separate calls within a session, and one session per stage, such as planning and implementation, lets you split a task's cost by stage; unsuccessful attempts appear once outcomes are recorded against the same task.
Which retries reflect a solvable defect and which indicate a bad brief or an unsuitable task?
Look at what changes between attempts. Progress on the failing checks points to a defect; exploration and changes of direction point to the brief; identical failures point to something the agent cannot fix. Review a handful of the most expensive tasks by hand before writing rules from the pattern.
How should task scope, escalation and model choice change without removing essential verification?
Narrow the task first, then pick the smallest model that passes the same checks, and escalate with the failure attached once environment, access and requirement problems are ruled out. Write the escalation rule down so every engineer applies it the same way, and keep tests, builds and review of risky changes on the strong path.
What cost per accepted outcome would show that the policy is helping rather than just suppressing usage?
There is no universal figure; compare your own baseline before and after the change. Helping looks like a lower cost per accepted change with steady reverts, defects and review time; suppressing looks like lower spend alongside fewer accepted changes or more rework.