Your AI automation bill has grown faster than your output. Where did the tokens go?
Almost always into three places nobody budgeted for: context that grew, retries that repeated, and tool overhead that was never counted. The model price on the pricing page is the smallest part of the story, and it is the only part most teams ever look at.
This matters more as automations get more agentic. A single prompt has a cost you can estimate on the back of an envelope. A workflow that reads, decides, acts, checks itself, and revises has a cost distribution, and the tail of that distribution is where the surprise lives.
Here is where the money actually goes, using figures published by Anthropic and OpenAI in their own documentation in September 2026, and how to build a budget before you build the automation rather than after the invoice.
What actually costs money in an automated workflow?
Four things, only one of which appears in the headline price. Input tokens, output tokens, tool overhead, and time. Most budgets model the first two and ignore the rest, which is exactly why the estimate and the invoice disagree.
Tool overhead is the least understood. Anthropic's pricing documentation states that when you provide tools, the API automatically includes a special system prompt, and it publishes the token count per model. On Claude Opus 5 that is 286 tokens for a tool choice of auto or none, and 406 tokens for any or tool. That is charged on every single call, before your prompt, before your data.
Time is the fourth axis and it is genuinely new. Anthropic's documentation prices code execution by execution time with a minimum of 5 minutes, gives each organization 1,550 free hours per month, and bills additional usage at $0.05 per hour per container. If your automation runs a container, you are buying seconds as well as tokens.
Why does the same prompt cost more than it used to?
Possibly because the text is being counted differently. Anthropic's pricing page notes that Claude 4.7 and later models use a newer tokenizer that produces approximately 30 percent more tokens for the same text, and that the exact increase depends on the content and workload shape.
Read that carefully, because it is the kind of change that produces a mystery. You changed nothing. Your prompt is identical. Your per-million rate may even have dropped. And your bill went up, because the same paragraph is now more tokens than it was.
This is why I insist on measuring a workflow in tokens per run rather than in dollars per run when I set a baseline. Dollars move for several reasons at once and tell you nothing about which one. Tokens per run isolates your own behavior from the vendor's. If you have never converted a workflow into a token count, start with my explainer on what a token is and how it becomes a bill.
How much does caching actually save, and when does it pay off?
A lot, but not immediately, because writing to a cache costs more than a normal input token. Anthropic publishes the multipliers relative to base input price: a 5-minute cache write is 1.25 times base input, a 1-hour cache write is 2 times base input, and a cache read is 0.1 times base input, dropping to 0.025 times on Claude Fable 5.1 and Claude Mythos 5.1.
The break-even is stated in the same documentation. Anthropic says caching pays off after one cache read for the 5-minute duration, and after two cache reads for the 1-hour duration. That single sentence should determine your cache strategy, and it is more useful than any amount of intuition about how much context to send.
The practical consequence: caching is a large win for a pipeline that runs many similar jobs in a short window, and a loss for a workflow that fires once an hour with a fresh context each time. Look at your run pattern before you turn it on, not after. I went through the content-pipeline version of this in prompt caching and what it does to content costs.
What are the hidden line items nobody budgets for?
Server-side tools, mostly. Anthropic prices web search on the Claude API at $10 per 1,000 searches, plus the standard token cost of whatever those searches return. An agent that searches three times per run is buying searches and then paying again to read the results.
Web fetch is the sharper trap because it looks free. Anthropic states there is no additional charge for web fetch beyond standard token costs, and then publishes the numbers that explain why that is not the same as cheap: an average web page of about 10 kB is roughly 2,500 tokens, a large documentation page of about 100 kB is roughly 25,000 tokens, and a research paper PDF of about 500 kB is roughly 125,000 tokens.
A workflow that fetches four documentation pages has just put 100,000 tokens into its own context, and every subsequent turn in that conversation carries them. This is the single most common cause of a bill that looks nothing like the estimate, and it is why capping fetched content matters more than shortening your prompt.
There is also a geography line item. Anthropic's documentation states that for Claude 4.6 and later models, pinning inference to the United States applies a 1.1 times multiplier across all token pricing categories, including cache reads and writes. If a compliance requirement set that flag, it is on every invoice and nobody remembers why.
When should work go through a batch API instead?
Whenever the answer is not needed in the next few minutes, which describes far more marketing automation than teams admit. Anthropic's Batch API is documented as asynchronous processing of large volumes of requests with a 50 percent discount on both input and output tokens. OpenAI publishes a Batch tier at half its Standard rates, and a Flex tier that matches those Batch rates for most models.
Half price is not a marginal optimization. Enrichment jobs, nightly classification, bulk summarization, content generation you will review tomorrow anyway: none of these need a synchronous response, and running them synchronously is a decision most people never consciously made.
The mirror image is worth knowing too. OpenAI's pricing page lists a Fast mode at twice Standard rates, and notes that priority processing was renamed Fast mode on 30 July 2026. Speed is a purchasable premium in both directions, so decide deliberately which of your jobs deserve it. Almost none of mine do.
How do you build a token budget before you build the automation?
Run it ten times by hand and measure, then multiply. That is the whole method, and it beats every estimate produced from reading a pricing page. You are looking for the mean and the worst case, because the worst case is what a monthly bill is made of.
Write down four numbers per run: input tokens, output tokens, number of tool calls, and number of retries. Then model the month at your expected volume, and then model it again at three times that volume. If the second number is uncomfortable, you have learned something important before you built anything.
Add the fixed overheads explicitly rather than assuming they round away. Tool system prompts on every call. Search charges per search. Container time if you execute code. These are small individually and they are charged on every single run, which is precisely how small numbers become the bill. Choosing a cheaper model for the right jobs is the other half of this, which I set out in which model to use for which marketing job.
What should you monitor once it is running?
Tokens per run, not spend per month. Spend per month tells you that something happened. Tokens per run tells you what, and it moves before the invoice does, which is the only kind of alert worth having.
Set a threshold on it. If a run that normally takes 8,000 tokens takes 40,000, something changed: a fetched document got longer, a loop is not terminating, a retry is silently repeating an expensive step. All three are cheap to fix on the day and expensive to discover at the end of the month.
Watch retries separately from runs. A retry is a full re-billing of everything that came before it in that turn, so an automation with a flaky upstream API can double its own cost without any change to its logic. For the automations I run in production, including the Airtable and WhaleSync setup for Ajust and the HubSpot automation for Kismet Health, the monitoring question I care about most is not whether it worked but how many attempts it took.
What should you do next?
Pick your most expensive automation and answer three questions today. How many tokens does one run consume, including tool overhead. What proportion of those tokens are repeated context that could be cached, and does your run pattern clear Anthropic's stated break-even of one cache read at five minutes or two at an hour. And does the job actually need a synchronous answer, or could it run at half price through a batch endpoint.
Then set one alert on tokens per run and forget the monthly dashboard. All of these figures come from vendor documentation that changes, so check the current pricing pages before you commit a budget rather than trusting an article, including this one.
I audit and rebuild automations like this for founders and marketing teams on fixed fees, with most projects landing between 1,000 and 10,000 dollars. If your AI spend has stopped making sense relative to what it produces, reach out and let's chat.
Get found, cited and the back office automated
Let's make your site the source AI engines quote and wire up the systems behind it.
Read more blogs
Let's get your website found and cited by AI
Tell me what you're working on, whether AI search is skipping your product, your back office is buried in manual work, or you need a build that does both.