An AI bill is the usage statement a company receives for large language model and other AI services: models price in tokens, billing settles in credits or cash, and every line of spend should trace back to a project. This guide is for the engineers, finance partners, and managers accountable for that number for the first time.
The answer up front: an AI bill has exactly three layers — tokens are the pricing unit, credits are the settlement unit, and per-request records are the audit unit. When a bill feels unreadable, one layer is missing: only a monthly total (no third layer), inconsistent units across vendors (no second layer), or no idea whether the money went to input or output (no first layer). The rest of this guide takes the layers one at a time, then maps them to roles and to the three most common anomalies.
Layer one: the token is the unit of pricing
Think of a token as a fragment of a word. Three pricing facts at this layer determine the shape of your bill.
Input and output are priced separately — output costs several times more
For the same request, longer answers cost more. Constraining output length (for example, fixing a response format) is the most direct cost lever you have.
Longer context costs more — every pasted paragraph is metered
Every document and every turn of chat history you put in the prompt counts as input tokens. Unusually heavy input almost always means the context is carrying content it doesn't need.
Cache hits bill at a different rate — repeated prefixes cost a fraction
System prompts and document prefixes that repeat can be far cheaper on a cache hit than as fresh input. Vendor rate pages list all three facts as tables — see OpenAI's pricing page for one example — and the same sentence can differ in cost by an order of magnitude across models; compare pricing modes in the model catalog.
So rather than staring at price sheets, track average cost per thousand requests: one number that reflects model choice, prompt length, and caching strategy together. For multi-step agents, pair it with cost per completed task — see what is the agent tax.
Layer two: credits turn many rate cards into one unit
Run several model vendors at once and finance receives invoices written in several languages: different currencies, rate tables, and metering rules. This is what a credit system is for: top up once, let each model draw down at its own rate, and every model's consumption lands in the same unit.
Why you need a single settlement unit
Credits are not a pricing trick — they are a translation layer that turns each vendor's billing logic into something finance can reconcile, so budgets, month-end closes, and trend lines share one baseline. Mechanics are in the credits docs.
Low-balance alerts keep workloads from stopping mid-run
With balance alerts and auto top-up, "ran out of credits halfway" becomes a notification instead of an incident.
Layer three: per-request attribution is the smallest auditable unit
A bill you can actually read has "one request" as its smallest unit — not "one month."
What a per-request record looks like
A monthly total says how much; it cannot say who or why. A per-request record writes down the project, key, model, and token counts of every call:
{
"request_id": "req_01HZXK3T9",
"project": "support-bot",
"model": "claude-sonnet-5",
"input_tokens": 1284,
"output_tokens": 412,
"cost_credits": 0.0087
}
The key determines attribution quality
If several applications share one key, the record above can tell you the model and the cost, but never the team. Project keys and per-request attribution are really one feature: the key stamps each request with an owner, and the log makes the stamp auditable later. This is why the enterprise AI governance checklist puts "one project, one key" at number 1. Fields and reports are covered in the spend docs.
By role: what engineering, finance, and management each read
Engineering reads layer one: token structure
Input-to-output ratio, cache hit rate, model mix — three numbers that decide whether unit cost can drop further.
Finance reads layer two: credits and top-up cadence
One unit, one bill, a predictable top-up cycle; anomalies get escalated to layer three.
Management reads layer three, rolled up: trends by project
Month-over-month spend summed by project is the only defensible basis for renewing next year's AI budget.
By scenario: three common billing anomalies
Spend jumps suddenly — sort by project, then drill into models
Nine times out of ten the jump concentrates in a single project — the same pattern as why AI bills explode after go-live; per-request records narrow it to one model, and often one deployment window, in minutes.
Input tokens balloon — inspect the context assembly logic
The usual culprit is "paste the whole document into every turn"; the usual fix is summarization or retrieval.
A balance runs dry mid-run — set alert thresholds and auto top-up
Make "credits remaining" a number on a dashboard you glance at daily, not the first line of an incident report.
The more modern approach: make attribution the default with ATP Token
You can build each of the three layers yourself; the more modern approach is a platform where they are simply the defaults. Project keys set ownership, every request writes its own record, and all models settle in credits — engineering keeps its existing call patterns (compatible with the OpenAI, Anthropic, and Gemini formats; integration is a base_url swap), and finance reads one bill a month.
Further reading
- Enterprise AI cost management: the complete guide to tokens, credits, keys, and caps
- Why AI bills explode after go-live: 5 control gaps and how to close them
- What is the agent tax? Why multi-step AI agents inflate token bills
A bill should be a dashboard you glance at daily, not a month-end surprise. Once the three layers line up, "how much is AI costing us" stops being a puzzle and becomes a query.