The reaction to rising AI bills has been to treat them as a spending problem. Finance gets a dashboard, engineering gets a monthly cap, and someone starts reselling unused credits. All of that is real. None of it touches what actually sets the number.
We run production agentic delivery pipelines and pay these bills ourselves. Token spend is not decided at the invoice. It is decided upstream, in how the pipeline is built, and by the time it reaches procurement the architecture has already priced it.
The procurement layer is filling up fast
The tooling to watch AI spend arrived quickly this year. Ramp shipped AI token spend controls that put every provider on one dashboard with real-time alerts. GitHub added a per-request reasoning-level dial so a team can trade tokens for depth on the tasks that need it. These are useful. They give you visibility and a ceiling.
What they do not do is change how many tokens a given piece of work costs. A dashboard tells you the bill is high. It does not tell you the bill is high because your agent re-reads a 17,000-line file on every change.
Where the spend is actually set
Four upstream decisions move token cost far more than any cap:
Model routing. Sending every task to a frontier reasoning model is the most common overspend we see. Most work does not need the top tier, and the price gap between tiers is large. Route by task, not by default.
Context discipline. An agent pays to read context on every turn. Dumping the whole repo into the window feels thorough and bills like it. What you feed the agent, and what you keep out, is a cost decision.
Caching. Repeated work that hits a cache is close to free. Repeated work that misses it is paid in full each time. Whether your pipeline caches is architecture, not procurement.
Code the agent has to read. This is the one nobody prices. Giles Edwards-Alexander ran the experiment: refactoring one bloated data-access layer cut the input tokens for the same change from about 159,000 to 27,000, an 83% reduction, because the agent could read a smaller subset of files. The code did not shrink. It got easier to navigate. Every future change to that module now costs a fraction of what it did, and that saving is permanent.
Why this is the 2015 cloud-cost mistake again
A decade ago, companies moved to the cloud, watched the bill climb, and reached for cost dashboards and reserved-instance brokers. The dashboards helped at the margin. The real savings came later, from teams that learned the bill was an output of architecture: instance sizing, data transfer, what got left running overnight. The tools bought visibility. Engineering bought the savings.
AI spend is repeating the pattern. Spend caps and credit markets are the reserved-instance brokers of this cycle. They are worth having, and they are not the lever. The lever is a pipeline that routes cheaply, feeds context sparingly, caches aggressively, and runs against code that is cheap for an agent to work in.
The uncomfortable part
Filing the AI bill under procurement has a hidden cost: it puts the fix in the wrong org. Finance can cap spend, but finance cannot refactor the data layer, tune the router, or decide what goes in the context window. Those are engineering decisions, and if the only response to a high bill is a tighter cap, the underlying cost never moves. It just gets rationed.
The dashboard is a good place to notice the problem. It is a bad place to fix it. That work is upstream, and it is where we start when the bill is the symptom.