The AI bill nobody budgeted for: how to keep AI costs predictable

When an AI bill grows faster than your customer count, or a year's AI budget is gone in a few months, start with how the bill is built. AI providers bill by the token, a small chunk of text, so the bill follows how many people use a feature, how long their conversations run and which AI model answers them. Three controls make that bill predictable. Sending routine tasks to a cheaper model and caching the text that repeats lower the cost of each task. Spend limits put a ceiling on the month. Once you know what one completed task costs, the forecast is arithmetic: expected tasks times cost per task. The hard spend limit is your worst case.

Uber learned this in public this year. Below are what Uber reported, why AI bills move the way they do, each control with one illustrative example, and six questions for your team.

What happened to Uber's AI budget?

Uber spent its 2026 AI budget early, then held its AI spending steady with the same controls this article covers. The story came out in three steps:

• April. Uber's chief technology officer, Praveen Neppalli Naga, told The Information that heavy use of AI coding tools, particularly Anthropic's Claude Code, had used up the company's full-year AI budget a few months into 2026. "I'm back to the drawing board," he said, "because the budget I thought I would need is blown away."
• June. An Uber spokesperson told Bloomberg that the company was limiting all employees to $1,500 in monthly token spending per AI coding tool, such as Cursor or Claude Code. Spending on one tool doesn't count against the budget for another. TechCrunch, reporting the caps, recalled that Uber had blown through its entire annual AI budget in a matter of four months. It added that employees can follow their usage on an internal dashboard and that, in some cases, the caps can be exceeded with permission.
• August. In Uber's second-quarter 2026 prepared remarks, the chief financial officer said the company was "setting better defaults for different use cases, moving certain tasks to lower-cost or open-weight models, and letting employees more clearly understand and manage their spend." Open-weight models are models whose makers publish them for anyone to run on their own servers. Fortune reported that Naga credited improved prompt caching, which reuses repeated text at a lower price (explained below). He also credited a changed default model, the one a tool uses unless someone picks another, along with testing new models for efficiency and letting engineers see their AI usage and costs per hour. In his words, Uber had "treated efficiency as an engineering problem rather than a budget problem."

Two lessons carry over to any business. First, Uber's fixes were engineering changes (better defaults, cheaper models for some tasks, caching and visibility) plus a cap per person and per tool. Second, the reported result is a stable bill, not a smaller one. Uber says cost per token fell "even as adoption has continued to increase, allowing us to keep overall AI spend broadly stable." In other words, savings per token were matched by growing use. None of these reports gives Uber's budget or its spend, so the effect of each fix is unknown. Predictable is a realistic goal. Smaller is not guaranteed.

Uber's case is about tools its engineers used. An AI feature inside your own product, such as a support assistant or a document summarizer, also bills by the token, so the same controls apply.

Why is an AI bill so hard to predict?

An AI bill is hard to predict because you pay for every token the model reads and writes, and that amount moves with how people use the feature. Your software sends each request through the provider's API, the connection that lets software call the model. Each request has input tokens, the text the model reads, and output tokens, the text it writes. Output costs more. Anthropic's current models, from lowest to highest cost and capability, are Claude Haiku 5.5, Sonnet 5.5, Opus 5.5 and Fable 5.1. Anthropic's price list charges $2 per million input tokens and $10 per million output tokens for Claude Sonnet 5.5, so each token of an answer costs five times as much as a token of the question. A model that reasons before it answers adds that reasoning to the output: Anthropic counts reasoning tokens among the billed output tokens.

The monthly bill is roughly the number of requests, times the tokens in each request, times the price, and all three move. The quiet multiplier is conversation length. Each new message in a chat, called a turn, sends the conversation so far back to the model, and you pay for it again. Anthropic's cost guide puts it plainly: a 40-turn task sends its first turn 40 times, "so task cost grows with roughly the square of turn count." AI agents, which call the model again and again to finish one job, multiply the bill the same way.

An illustrative example. Picture a support assistant on a company's website. Each request carries 6,000 tokens of fixed instructions and help-center text, a 200-token customer question and a 300-token answer. These numbers are made up for the example. The prices are Anthropic's list prices on 13 October 2026; other providers set their own. The sums leave out reasoning tokens and failed answers that need a retry. If your feature uses a model that reasons, include them in the measured cost.

• 30,000 single questions a month on Claude Sonnet 5.5 cost about $462.
• If the same 30,000 customers each have a five-message chat instead, every message resends the chat so far. One chat then sends 36,000 input tokens in total and gets 1,500 output tokens back. The month now costs about $2,610, 5.6 times as much, with no new customers.

In this example, one completed task is one customer's chat. An AI support chatbot that checks who the customer is and looks up their account calls the model more than once for each message.

Nothing broke. The way people used the feature changed, and the bill followed. The next sections bring the example back down, one control at a time, with the number of customers fixed. In real life, cheaper tasks often invite more use, as Uber found.

Which tasks can a cheaper model handle?

A cheaper model can handle routine, high-volume tasks whose answers can be checked, such as summaries, sorting and simple support questions, once testing shows it gets them right. If your feature mixes such tasks with harder ones, choosing which model answers each kind is called model routing. The simplest version is a fixed rule your developer writes. In a support assistant, for example, questions from the order-tracking page could go to the small model, and refund disputes to the large one.

Anthropic launched Claude Haiku 5.5 on 7 October 2026 and calls it the cheapest, fastest and most capable small model it has released. For prompts up to 100,000 tokens (a prompt is all the text sent in one request), it costs $0.10 per million input tokens and $0.50 per million output tokens, a twentieth of Claude Sonnet 5.5's price. Anthropic says Haiku 5.5 is designed for high-volume, cost-sensitive tasks such as summaries, database queries, classification and live customer support. It also says that Sonnet 5.5 and Opus 5.5 remain better choices for complex agentic coding, where the model works through long programming tasks on its own.

A cheaper model is only cheaper if it does the job. Anthropic's cost guide reports a test on GPQA Diamond, which draws on hard multiple-choice science questions written by experts. Haiku 5.5 answered those questions at about a twentieth of the cost per question of Anthropic's larger Opus 5.5 model, with 85% right against 91%. The guide concludes that Haiku 5.5 suits high-volume work where speed matters and the answers can be checked. It tells customers to compare models on cost per completed task and to test them on the hardest tenth of the work, such as the longest or most complex requests, because "a failed task still bills its tokens, then the retry, then whatever the failure costs downstream." These are Anthropic's own measurements of its own models, so test on your own work before you rely on them.

Three details change the comparison:

• Haiku 5.5 has a new tokenizer, the part that splits text into tokens, and Anthropic says it uses slightly more tokens per task. Compare real tasks, not price lists.
• A Haiku 5.5 request whose prompt is over 100,000 tokens pays the higher prices for all of its tokens: $0.50 per million input tokens and $2.50 per million output tokens. A long chat can cross that line, because each message resends the whole chat.
• Work that no one waits for, such as nightly reports or bulk tagging, can go through Anthropic's Batch API, a slower way to send requests, at 50% off, with results within 24 hours.

Back to the example. Suppose testing shows that Haiku 5.5 handles 80% of the chats well, and the harder 20% stay on Sonnet 5.5. The five-message month falls from about $2,610 to about $626. The sum ignores Haiku 5.5's slightly higher token count and any retries, so treat it as a rough figure.

How much does caching save on the repeated part?

Caching cuts the price of the text that repeats from one request to the next, to a tenth of the normal input price or less on Anthropic's models. That text is the instructions, reference text and earlier messages. In the example's five-message chats, it is about 94% of the input. With prompt caching, the provider keeps the start of a request for a short time. When the next request starts with exactly the same text, the model reads that part from the cache at a much lower price.

On Anthropic's prices, saving text to the cache costs 1.25 times the normal input price, and a cache hit costs 10% of the standard input price (5% on Sonnet 5.5 and Opus 5.5), so caching pays off after one read. The cache lasts five minutes by default, and each use restarts the clock, so a feature with steady traffic keeps its instructions cached. A one-hour cache is also available, at twice the input price to save.

In the example, the 6,000 tokens of instructions and every earlier message of a chat repeat with each new message. Assume that customers reply within five minutes and that steady traffic keeps the instructions in the cache from one customer to the next. Each message's new text is saved to the cache at 1.25 times the input price, and everything before it is read back. With caching, the five-message chats on Sonnet 5.5 alone fall from about $2,610 to about $716 a month. With caching and routing together, 80% on Haiku 5.5 and 20% on Sonnet 5.5, the month comes to about $176.

Caching can also raise the bill. If something that changes on every request, such as the current time, sits before the text that repeats, no request ever matches the one before it. Each request pays the higher price to save, and nothing is ever read back. Anthropic measured a case where a short status line that changed with each request, placed at the front of the instructions, made one run of a bug-triage test job cost $4.24 instead of $0.59. That is about seven times as much, and "more than running with caching off." We explain the same trap in OpenAI's prompt caching, and how to check for it, in a separate article. The warning sign shows in every response's usage figures: many tokens saved to the cache and almost none read back.

How do you cap AI spending without breaking the feature?

Spend limits protect the budget, but a limit that stops requests also stops the feature for every customer. Set warnings first and the hard stop above them. Anthropic and OpenAI offer both:

• Anthropic. In the Claude Console, Anthropic's web dashboard for API accounts, under Settings > Billing, you can set a monthly spend limit for your organization. When usage reaches a limit you set, requests fail with an error that says when access resumes, unless you raise or remove the limit sooner. Under Settings > Workspaces, you can also give each workspace its own spend limit and alerts for when spending reaches set thresholds. A workspace groups API keys, the keys your software uses to call the model, with their limits, so one feature can have its own. Anthropic's documentation says only organization admins can create workspaces. Organization-wide limits always apply, even if the workspace limits add up to more.
• OpenAI. Spend alerts send a notification and leave traffic running. A hard spend limit, set for the organization or for one project, makes requests fail with an error (code 429). You need permission to manage those organization or project settings. OpenAI warns that enforcement is not instantaneous, so recorded spend can slightly exceed the limit.

A practical setup has three layers:

1. Alerts at levels that leave time to react, for example at half and at 80% of the month's expected spend.
2. A hard limit for each feature, in its own Anthropic workspace or OpenAI project, set above the highest month you expect. It is a circuit breaker for a bug, a loop or abuse, not a budget. Its amount, plus any small overshoot, is your worst month. In the example, a month expected at about $176 might get alerts at about $90 and $140 and a hard limit of $400. Because each feature has its own limit, one runaway feature can't use up the money another feature needs.
3. Limits per user or per customer inside your product, such as a number of chats a day. This is Uber's approach in product form: one heavy user or one script can't spend the month's budget, and everyone else keeps working. Decide in advance what a user sees when they reach their limit, such as a short message with a way to reach a person.

Uber paired its caps with visibility: employees could see their own spend. For a feature, the equivalent is a weekly view of spend by feature and by customer, built from the token counts that every response reports.

What should you ask your team before the next invoice?

Ask questions whose answers are numbers. With these six answered, you can forecast the bill and you know its ceiling:

1. What does one completed task cost? A good answer is a figure measured on real samples, with its date, not an estimate from a price list.
2. Which model answers each kind of task, and was a cheaper one tested on the hardest tenth of the work? A good answer names the test and how many tasks each model got right.
3. What share of input tokens is read from the cache? For a feature that resends long instructions, most of it should be: about 94% in the example. For AI agents, Anthropic reports a median of 84% read from the cache and says to look for a problem below about 80%.
4. Which work could wait for a batch at half price? A good answer names the jobs no one waits for.
5. Where are the alerts, the hard limit and the per-customer limit set, and what does a user see when one is reached? A good answer shows all three, and the message is already written.
6. Who looks at spend by feature each week, and where? A good answer names a person and a report.

For the developer who answers them, Anthropic's guide describes a method. Take a few real tasks from production logs, weighted like real traffic. Give each a check of whether it was done right, and record cost per task beside the score. Before switching, run the new setup in the background on part of the real traffic, without showing its answers. Before changing models, try the effort setting, which trades answer quality against speed and cost within one model. Anthropic says it is often a better lever than switching models. To confirm the cache works, read cache_read_input_tokens and cache_creation_input_tokens in each response's usage.

Prices change, and the guide itself warns that its numbers "will drift as models and prices change." Run the checks again when a provider changes its prices or launches a model, as Anthropic did on 7 October. OpenAI and other providers set their own prices for models and caching, so the sums change, but the method does not.

What if the bill comes from coding tools, not a feature?

Uber's overspend came from AI coding tools, and they bill by the token too. Anthropic's Claude Code documentation says costs per developer vary widely with the model, the size of the code and how people use the tool. Across enterprise deployments, it reports that the average cost is around $13 per developer per active day, a day on which they use the tool, and $150 to $250 per developer per month, with 90% of users below $30 per active day. It recommends starting with a small pilot group to set a baseline before a wider rollout.

On Claude's Team and Enterprise plans, each seat includes a usage allowance, whose size depends on the seat tier, and admins can allow usage past it and set spend limits for the organization, a group or a single member. If your spend per developer is well above the average, find out which people and tasks drive it before you set a cap. The same three layers apply: alerts, a limit per person or group, and a weekly view of spend per person. Uber's cap of $1,500 per tool is far above that average, so in our reading it works as a ceiling for the heaviest users, not as a budget for a typical one.

If an AI feature's bill is growing faster than its use, or you want to know its running cost before you launch it, tell us what you have. You will hear from a person within one business day.