The uncomfortable part of cost work is that it does not stay done. A team runs a serious pass, takes twenty-something percent out of the bill, and two quarters later the run rate is back where it started or above it. Nobody was careless. The account simply resumed doing what accounts do.
This is not a discipline problem, and treating it as one — a monthly meeting, a dashboard someone is supposed to check — reliably fails. Attention is the scarcest thing in an engineering org and cost cannot win a standing fight for it.
What works is making the cost of a change visible at the moment someone makes it, in the tools they already use.
Per-unit metrics, not totals
A total spend figure cannot tell you whether a rise is good or bad. Revenue-generating growth and a regression look the same on that chart, which is why nobody trusts it and why alerts on it get muted.
Track cost per unit of work instead: per document processed, per conversation, per user, per whatever your product actually does. This number should be roughly flat as you grow. When it moves, something changed in the architecture, and that is a real signal worth interrupting someone for.
Pick the denominator that matches how the business thinks. If leadership counts customers, cost per customer per month is the number that will get acted on.
Put the number in the pull request
The highest-leverage single practice: a check that reports the token cost of a representative request, before and after, on every PR that touches a prompt or a model call.
Not a gate — a comment. "This change moves the onboarding summary from 1,800 to 4,100 output tokens." That is enough. Nobody merges a 2x regression when the 2x is written on the page in front of them, and nobody has to remember to care, because it arrives unbidden.
This is the same reason bundle-size bots work on frontend teams. Feedback at the moment of the decision beats a report read later, by a lot.
Budgets that reach a human who can act
Provider spend alerts are necessary and insufficient — they fire on totals, late, at whoever owns the account rather than whoever wrote the change.
Two things make them useful: alert on per-unit figures, and route by feature tag to the team that owns that surface. An alert that reaches the person who can fix it the same week is worth ten that reach a shared inbox.
Set a ceiling per environment too. The expensive incidents are rarely a slow drift — they are a retry loop, a runaway agent, or a test suite pointed at production. A hard cap turns a $40,000 weekend into a $2,000 one.
The three habits that hold
A cost line in the design doc. Any feature that calls a model estimates tokens per request and expected volume before it is built. The estimate will be wrong. The value is that someone thought about the order of magnitude while the design was still cheap to change.
Prompt changes reviewed as code. Prompts in version control, in the diff, reviewed like anything else. A prompt in a database field that anyone can edit is an unreviewed production change with a recurring bill attached.
A named owner. Not a committee and not everyone. One person who looks at the per-unit numbers monthly and has the standing to open a PR. Fifteen minutes of clear ownership beats two hours of diffuse concern.
What to expect
Even done well, run rate drifts upward — new features, more usage, better models that cost more. The goal is not a flat bill. It is that you know why it moved, every time, and that the movement was a decision rather than an accident.
The honest benchmark: a team with per-unit metrics, a PR cost check, and one owner will hold most of its savings and catch regressions in days rather than quarters. A team without them will repeat the whole exercise next year — which is good business for consultants, and a bad outcome for you. That is why this chapter is in the handbook rather than in a deck.