Your AI bill is a design defect

Three weeks into the quarter. Finance sends a message starting with "quick question about the AI line."

What happens next is nearly always the same three moves.

Count the licences, cut the ones that look idle. Vendor on a call, ask for a better rate. A note asking everybody to be mindful of usage.

All three miss the thing generating the number. Every time.

You can run every one of them, do the work, take the meetings, and watch the bill keep climbing, because the bill tracks decisions made inside your workflows. Most of them made by engineers who never saw a price attached to the choice.

Where the money actually goes

Two teams the same size can sit twenty times apart on spend. The gap has nothing to do with discipline or effort.

One team's agent loop re-reads half the repository on every step, because nobody set up a narrower retrieval path.

Another runs the expensive model for the whole loop, when the first four steps are mechanical and the cheap model handles them with no measurable difference in output.

A third has a retry policy quietly tripling the cost of any task that fails once, plus a failure rate high enough to matter, and nobody has connected those two facts because they live on different dashboards.

A fourth. No caching on a prompt prefix that goes out forty times an hour.

Design decisions, all of them. A spending decision is a completely different animal, and personal restraint doesn't come into it anywhere.

They're the kind of thing you'd catch in review if the cost were visible at the moment the choice got made. It isn't. So you catch it eight weeks later, in a spreadsheet with no author's name on it.

The billing model already moved

This got sharper this year. Plenty of budgets haven't caught up.

GitHub moved every Copilot plan to usage-based billing on 1 June 2026, with a monthly allowance of credits and the option to buy more.

The detail that matters is which side of the line each feature sits on. Completions and next-edit suggestions, included. Chat, agent mode, agentic review, all consuming credits based on tokens.

Read it as a sentence about your org. Vendors are the least of it.

The moment your engineers moved from autocomplete to agents, your cost model changed from per-seat to per-decision.

If your budget was built on a seat count, it was built for the tool you had in 2024.

The planning numbers show the same lag.

DX's survey of engineering leaders had most of them spending between $101 and $500 per developer per year on AI developer tools in 2025, with $1,000 per developer per year emerging as the 2026 target, and about half of leaders ring-fencing one to three percent of the engineering budget.

Per-head figures. For a cost that stopped behaving per-head.

When this becomes your problem

Not this quarter, for some readers, and this piece is worth less if it pretends every org stands in the same place.

If your binding constraint right now is that people aren't really using the tooling, cost isn't your problem, and instrumenting it will spend attention you need somewhere else.

The two trade places. Early on, while a practice is still being established, the expensive failure is the workflow nobody runs at all.

Plenty of orgs went through the whole first year of this without measuring cost per change. Correctly. The thing actually limiting them sat upstream of the bill.

The turn comes quickly, though, and it doesn't announce itself.

The quarter adoption stops being what you're fighting is the quarter the bill becomes a design question. And the workflows established while nobody was watching cost are exactly the ones you'll be unpicking.

Which argues for knowing what the number is before you need it. Acting on it from day one is a different claim, and a worse one.

The number to run instead

Cost per merged change. Broken out by class of change.

Boring metric. Does an enormous amount of work, because it's a ratio.

Total spend going up is evidence of nothing. If the tooling works, total spend should go up, the same way your cloud bill went up the year you started serving more customers.

What you need to know is what a unit of value costs, and whether that's moving in the right direction.

Broken out by class it gets more useful, and slightly embarrassing.

A dependency upgrade and a customer-facing feature should not cost the same to produce. When they do, you've found a workflow doing far more work than the task requires.

That's the report worth reading. The three workflows whose cost bears no relationship to the value of what they produce, and never mind the three teams spending the most.

Then put cost into the eval, beside correctness. Almost nobody does this part.

A workflow producing the right answer at ten times the expected cost has a defect, and you will never find it while your eval only asks whether the output was right.

Correctness alone is how a workflow passes every check you have while burning your quarter.

What to do about it, in order

Attribute first. Always.

You can't manage a number nobody owns, and unattributed spend defaults to being finance's problem, which is exactly the misdiagnosis this whole piece is about.

Get spend down to the team and the workflow. Roughly. By hand, for the first month.

Then cap at team level. Let the team keep what it saves.

Caps applied per person punish the engineers using the tooling best, which is a strange thing to do on purpose.

Applied per team, with the savings staying in the team's own budget, you've turned a finance control into an engineering incentive. And engineers are extremely good at optimising a number that belongs to them.

Design the escalation path before the first cap bites. That decides whether any of this survives.

Somebody will hit their cap in week three with a customer commitment on the line. If the answer is a two-day approval queue, your organisation has just learned that a cap is a reason to hide usage.

Make the answer same-day, and make it public.

And put cost on the same dashboard as latency and error rate, where it belongs.

Cloud cost has been an engineering metric for a decade, for exactly these reasons. This is that argument again, with a shorter feedback loop and a steeper curve.

The move that always gets made and shouldn't

Somebody will propose central approval for model access.

Sounds prudent. Popular with everybody who doesn't have to use it. And it produces a queue in front of the exact step you were trying to speed up.

The variant that works is a default. Cheap model unless the workflow's eval shows it needs the expensive one, with the burden of that evidence sitting on the team and never on a committee.

Same restraint, no queue. Evals as a side effect.

Skip the mindfulness note as well.

Asking people to be careful is a culture message aimed at a systems problem, and it lands hardest on the engineers with the least confidence in their standing.

Put the cost next to the choice. A per-run figure visible in the tool changes behaviour inside a week, and it requires nobody to feel guilty about their job.

Say it plainly in the finance meeting

Your AI spend is a design defect until proven otherwise, and the person who can fix it doesn't work in finance.

Bring cost per merged change to the meeting, by class, with the two workflows you're fixing this month named out loud. And be clear that total spend goes up if the work is going well.

Different conversation from the one starting with "quick question about the AI line." You only get to have it if you already own the number.