LLM Spend Management: A Practical Guide
Most engineering teams can tell you their cloud bill to the pound. Ask the same team what their LLM APIs cost last week, broken down by feature, and you usually get a shrug followed by a screenshot of a provider dashboard that answers a different question.
That gap has a name now: LLM spend management, the discipline of tracking, attributing, and controlling what your organisation spends on large language model APIs. It is a branch of AI spend management, narrowed to the cost that dominates most AI budgets today: token-based API usage across providers like OpenAI, Anthropic, and Google.
This guide covers what the discipline actually involves, why cloud cost tooling does not transfer, and the five practices that make it work.
Why LLM spend needs its own discipline
Cloud cost management matured around a predictable model: you provision capacity, capacity has a price, and spend moves slowly enough that a monthly billing export tells you what you need to know.
LLM spend breaks every one of those assumptions:
- Cost is per-request, not per-resource. There is nothing to "right-size". Every API call has its own cost, driven by input tokens, output tokens, cached tokens, and reasoning tokens, each priced differently per model.
- Prices change constantly. New models ship monthly. Providers reprice. The same feature can cost 10x more or less depending on which model a developer picked.
- A one-line code change can double your bill overnight. A longer system prompt, a retry loop, a switch from a mini model to a frontier model: none of these show up in code review as a cost decision, and all of them are.
- The invoice arrives too late. By the time finance sees the monthly number, the spend has happened. There is no undo.
Treating LLM costs like cloud costs means finding out about problems weeks after they start. The discipline that works is closer to real-time observability than to billing analysis.
The five practices of LLM spend management
1. Capture cost at the request level
Everything else depends on this. If you only have provider invoices, you have one number per month per provider. You need the cost of every request: which model, how many prompt tokens, completion tokens, cached tokens, and reasoning tokens, priced at that model's rates.
The practical way to get this is a gateway in the request path. Your applications keep using the official SDKs; they just point at a proxy base URL that records usage as traffic flows through. No SDK wrappers to maintain, no billing exports to parse, and cache token semantics (which differ by provider) are normalised for you.
2. Attribute every request to an owner
An unattributed cost is an unmanageable cost. Every request should carry dimensions: which team, which feature, which environment, and, if you sell AI-powered features, which customer.
This is where LLM spend management earns its keep commercially. Per-customer attribution turns "our AI bill went up" into "customer X's usage of feature Y costs £Z per month", which is the number you need for pricing decisions and unit economics.
Enforce it: reject untagged requests at the gateway rather than politely asking teams to remember headers. Coverage that depends on discipline decays; coverage that is enforced holds.
3. Set budgets that act, not report
A budget that only appears in a report is a suggestion. Useful budgets have teeth: burn alerts at configurable thresholds so a team knows at 60% and 85%, not at 130%, and monthly limits per team or cost centre that map to how finance already plans.
The goal is that no one is ever surprised by the invoice, because the surprise happened three weeks earlier as an alert, when there was still time to do something about it.
4. Govern which models can run
Model sprawl is a cost problem wearing an engineering hat. Without guardrails, every developer chooses their own model, and expensive frontier models end up serving jobs a small model handles identically.
Governance at the gateway means allow-lists per API key: this key may call these models from these providers, and nothing else. Unapproved models are blocked at call time rather than discovered on the invoice. This also contains shadow AI usage, because a key that can only call approved models cannot quietly become an experiment in something else.
5. Report in finance's language
Engineering thinks in tokens; finance thinks in cost centres, budgets, and variance. LLM spend management bridges the two with chargeback and showback exports: cost by department, by product line, by customer, in formats that drop into existing financial reporting.
If your reporting still needs an engineer to interpret it, the loop is not closed. The test is whether finance can answer "what drove the increase" without asking engineering.
What this looks like in practice
A team adopting these practices typically goes live in stages, and the early stages are quick:
- Day one: route traffic through a gateway with a base URL change. Request-level capture starts immediately.
- Week one: tag requests by team and feature, and see the first real attribution breakdown. This is usually where the surprises surface: a feature nobody thinks about consuming a third of the bill, or a retry loop quietly multiplying costs.
- Month one: budgets and alerts per team, model allow-lists per key, and a monthly export finance can use without translation.
None of this requires rearchitecting your applications. The heavy lifting, provider-correct pricing, cache token normalisation, and low-latency capture, belongs to the platform, not your codebase.
The checklist
You have working LLM spend management when you can say yes to all six:
- Every LLM API call is captured with token counts and cost
- Every request is attributed to a team, feature, environment, or customer
- Budgets exist per team, with alerts that fire before month-end
- Model and provider allow-lists are enforced at call time
- Finance gets chargeback exports in their own format
- A cost spike is noticed in hours, not on the invoice
If you are missing several of these, start with capture and attribution: they are the foundation the rest builds on, and a purpose-built AI spend management platform gives you both in an afternoon rather than a quarter of internal tooling work.