What agents actually cost, per ticket

A finance director asked an engineering manager a reasonable question last quarter: what does the AI spend buy us. The manager had one number, the monthly invoice from a model provider, and a strong intuition that it was worth it. He could not decompose the number. He could not say which teams drove it, which features drove it, or whether a given ticket had cost forty cents or forty dollars. What he could say was that the team was shipping more, which finance heard as a vibe rather than an answer, because that is what it was.

That conversation is now happening in a lot of companies, and it usually resolves badly in one of two directions. Either someone panics and imposes a blunt cap that quietly degrades the work, or nobody looks closely and the line item grows until it becomes an executive problem rather than an engineering one. Both outcomes come from the same root cause: the spend is being observed at the wrong unit.

The invoice is not a cost model. It is an aggregate over an enormous number of unrelated activities, some of which produce enormous value and some of which produce nothing at all. Treating it as a cost model is like reading your electricity bill and concluding that lighting is expensive.

The unit that matters is the ticket

Pick the unit deliberately, because everything downstream depends on it.

Cost per token is the vendor’s unit. It is useful for exactly one thing, which is comparing two models on identical work, and it becomes obsolete every time a price changes.

Cost per developer per month is the procurement unit. It fits a spreadsheet nicely and tells you almost nothing, because it averages over the developer who ran three exploratory agents in parallel all week and the developer who used a chat window twice.

Cost per ticket is the unit that maps onto how the business already thinks. A ticket is a unit of intended value. It has a requester, an estimate, a priority and, usually, a rough sense of what it is worth. If you can put a cost against it, you can have an actual conversation, and the conversation is not about tokens. It is about whether this class of work is worth automating at this price.

The catch is that nothing in your stack naturally produces cost per ticket. Providers bill by API key. Trackers know about tickets. Source control knows about branches and pull requests. The cost model lives in the join between those three, and the join is the work.

ProviderBills by key and model. Knows nothing about your work.

Source controlKnows branches, commits, pull requests, who and when.

TrackerKnows tickets, teams, epics, priority and intent.

Cost per ticketOnly exists once all three are joined.

Build the model from the bottom

There are five components to the real cost of an agent-assisted ticket, and most teams count one of them.

Generation. The model calls that produce code. This is the part everyone thinks of, and in most workflows it is not the largest cost. It is, however, the most visible one, which is why it attracts disproportionate attention.

Iteration. The attempts that did not work. An agent that produces a working change on the first pass is cheap. An agent that produces four near-misses and needs the developer to reframe the task twice has cost you four generations plus two rounds of human thinking. Iteration cost is invisible in the invoice because failed attempts bill exactly like successful ones.

Verification. Whatever you spend confirming the change is correct. Tests, static analysis, semantic checks on the acceptance criteria, and the compute those things consume. This line item barely existed three years ago and is now the fastest-growing one on many teams, for good reasons.

Human attention. Review, clarification, the meeting where two people argue about whether the agent understood the ticket. Attention is by far the most expensive input in the system and it is the one nobody puts on the ledger. A ten-dollar model bill attached to ninety minutes of senior review is not a ten-dollar ticket.

Rework. The cost of the change that shipped, broke something, and came back. Rework is the component that punishes teams who optimise only the first four. If you cut verification spend and rework doubles, you have made the ticket more expensive while making the invoice smaller, and you will feel good about it for about a month.

GenerationModel calls that produce the change. Visible, usually not dominant.

IterationThe attempts that failed. Bills identically to the ones that worked.

VerificationTests, checks, semantic evaluation of the criteria. Growing fastest.

Human attentionReview and clarification. The most expensive input, almost never counted.

ReworkThe bill that arrives late. Punishes anyone who optimises the first four alone.

A worked example, entirely hypothetical

I am going to put numbers on this, and I want to be very clear that they are invented for the purpose of showing the arithmetic. Model prices move constantly, in both directions, and any specific figure I gave you would be wrong within a quarter. The method survives the price change. The price does not.

So suppose the following, purely as an illustration. Suppose a generation pass on a medium ticket costs you one unit. Suppose the average ticket takes two and a half generation passes because the first attempt usually needs a nudge. Suppose a deterministic verification pass, running your tests, costs a fraction of a unit in compute, call it a fifth. Suppose a semantic verification pass, where a model reads the diff against the acceptance criteria, costs half a unit. And suppose a senior engineer’s review hour, fully loaded, is worth two hundred units.

Now do the arithmetic on a ticket that goes cleanly: two and a half units of generation, a fifth for tests, half for semantic checks, and fifteen minutes of review at fifty units. Total, roughly fifty-three units, of which the model spend is about three. Model spend is six percent of the cost of the ticket.

Now do the arithmetic on a ticket that goes badly. Five generation passes because the criteria were vague. Tests run four times. Semantic checks run three times. Review takes an hour because the reviewer cannot tell what the change is supposed to do, and then the ticket comes back a week later with a defect that takes another two hours to diagnose and fix. Total, somewhere north of six hundred units, of which the model spend is about seven.

The interesting result is not that the bad ticket costs twelve times the good one. It is that in both cases the model spend is a rounding error, and the difference between them is almost entirely determined by whether the ticket was well specified. The lever on cost per ticket is not the model. It is the clarity of the input.

Optimising the invoice

• Switch to a cheaper model
• Cap tokens per request
• Restrict who has access
• Shrink context aggressively
• Result: more iterations, more rework

Optimising the ticket

• Write criteria a machine can check
• Cut iteration by cutting ambiguity
• Verify before a human looks
• Cache anything deterministic
• Result: the invoice falls anyway

What you actually have to instrument

To get from an invoice to a per-ticket number you need three things recorded at the moment the call is made, because you cannot reconstruct them afterwards.

The first is a work identifier. Every model call made on behalf of a piece of work should carry the ticket key, the branch, or the pull request number. Attach it at the call site. If you try to attribute later, by timestamp correlation or by guessing from a developer’s activity, you will get something that looks like data and behaves like noise.

The second is a purpose label. Generation, verification, summarisation, triage, whatever categories reflect how you actually use models. Without this you cannot tell whether your spend growth is more work or more checking, and those two have opposite implications.

The third is the raw counts. Tokens in, tokens out, model identifier, timestamp. Store the counts and the model, not just the derived cost, because prices change and you will want to re-derive history against a new rate card without losing the underlying record. This is the single most common mistake I see: teams store dollars, the price changes, and their entire trend line becomes uninterpretable.

For the calls our own control layer makes on a customer’s behalf, GroundTruth ledgers exactly this, tokens in, tokens out, model and cost, keyed to the feature and the ticket, with a projected monthly run rate. That is not a boast so much as a statement that the schema is not complicated. It is four fields and a foreign key. The reason most teams do not have it is that nobody decided it was somebody’s job.

What the number is for

Once you have cost per ticket, resist the urge to use it as a scoreboard. Ranking developers by model spend is a fast way to teach everyone to hide their usage, and you will lose the data you just spent a quarter collecting.

Use it for three things instead.

Use it to find the pathological classes of work. There is almost always a category of ticket, usually one involving a gnarly legacy module or a domain nobody has documented, where cost per ticket is five or ten times the median. That is not a model problem. That is a signal about where your codebase or your knowledge base is weakest, and it is one of the more honest maps of technical debt you will ever get.

Use it to price decisions. When someone proposes running a heavier verification pass on every pull request, you want to be able to say what that costs per ticket and compare it to what a missed defect costs. Without the denominator that conversation is pure opinion.

Use it to catch runaway loops early. Agentic workflows fail in a distinctive way, which is that they do not stop. A retry loop with a bad exit condition can generate a startling amount of spend overnight and produce nothing. A per-ticket view catches this immediately, because you see one ticket with a cost two orders of magnitude off the median, whereas a monthly aggregate catches it on the invoice.

Where this breaks down

Several places, and I would rather say them than have you discover them.

The attribution is not clean, and it cannot be. A developer runs an agent to explore three approaches, keeps one, and never links the other two to anything. Someone asks a model a question in a chat window that shapes a design decision but produces no artefact. A background job summarises a hundred pull requests for a report that is loosely related to twelve tickets. A meaningful slice of your spend is genuinely unattributable, and if you force it into buckets you will produce precise nonsense. Report it as unattributed and watch that share over time. If it is growing, that is the finding.

Cost per ticket also assumes tickets are comparable, and they are not. A ticket is not a fixed quantum of work. Teams that decompose finely will show low cost per ticket and teams that write epics as tickets will show high cost per ticket, and neither is better. The metric is only usable within a team, against itself, over time. The moment it becomes a cross-team comparison it starts driving ticket-splitting behaviour rather than cost behaviour.

The biggest limit is the one I leaned on above: the dominant term in my hypothetical example was human attention, and human attention is the hardest thing to measure honestly. Review time is not the timestamp difference between opening and approving a pull request, because people context-switch. You can approximate it, and approximation is much better than nothing, but anyone who tells you they have precise human-cost attribution is describing a surveillance system, not a cost model, and it will be resented accordingly.

And there is a timing problem. Rework arrives weeks after the ticket closed, which means your cost per ticket is provisional for as long as your defect tail is long. A number that looks great on Friday can look considerably worse a month later. Treat recent periods as incomplete, the way finance treats revenue that has not settled.

The takeaway

The invoice is the wrong artefact to reason about. It aggregates generation, iteration, verification and background work into a single number, which means every conclusion drawn from it is a guess.

Build the model at the ticket, record the work identifier and the purpose at the call site, store raw counts rather than derived dollars, and accept that a share of the spend will remain unattributed. When you do this, the finding is usually the same, and usually surprising to whoever commissioned the exercise: the model spend is not the expensive part. Ambiguity is. The tickets that cost ten times the median cost that much because nobody could say precisely what done meant, and the agent paid for that confusion in retries while the reviewer paid for it in hours.

Which raises the immediate follow-on question. Once you can price a ticket, somebody will want the spend rolled up by feature, by team and by cost centre, and that turns out to be a harder problem than it sounds. The next piece is about attribution: how to get model spend onto the org chart without building a surveillance apparatus, and why the boundary you choose matters more than the precision you achieve.