Usually because one automation started running more often, or someone pointed a script at a bigger model, and nothing in the workflow surfaced the change. AI spend is invisible by default. It arrives as one line on a monthly invoice, long after the decision that caused it.
This is a new problem for small web teams. Hosting, domains, and software licences are predictable and roughly fixed. Model usage is metered per token, which means the cost of a workflow depends on how much text goes in and out, and that can change without anyone editing anything.
The good news is that the pricing is public, the arithmetic is simple, and two documented features will cut most bills substantially. Most overspending we see is not waste in the clever sense. It is teams paying full price for things the providers already discount.
You pay per token, separately for input and output, and output costs several times more than input. A token is a chunk of text. Anthropic''s documentation offers a rough guide that "1 token is approximately 4 characters or 0.75 words in English", so a thousand words of text is roughly 1,300 tokens.
Prices are quoted per million tokens, which makes small jobs look free and large ones sneak up on you. As published in Anthropic''s pricing documentation in August 2026, Claude Opus 5 is $5 per million input tokens and $25 per million output tokens, Claude Sonnet 5 is $2 and $10, and Claude Haiku 4.5 is $1 and $5.
OpenAI''s published pricing follows the same shape, with GPT-4o at $2.50 per million input tokens and $10 per million output, and GPT-4o-mini at $0.15 and $0.60. The pattern to notice across both providers is the spread. The gap between the cheapest and most capable model is large, and it is the single biggest lever on your bill.
The asymmetry between input and output matters too. Output is typically five times the input price, which means an instruction to "be concise" is not just a style preference. It is a direct cost control.
Prompt caching stores the unchanging front part of your prompt so you are not billed full price for sending it again. Anthropic''s pricing documentation puts a cache read at 0.1x the base input price, and states plainly that "a cache hit costs 10% of the standard input price." That is a 90% saving on the repeated portion.
There is a small cost to setting it up. A five minute cache write costs 1.25x the base input price and a one hour cache write costs 2x. Anthropic''s documentation works out the break-even for you: caching pays off "after one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)." Two reads and you are ahead.
OpenAI documents a comparable discount, noting that "the cached input price is typically 10% of the standard input rate." So this is not a vendor quirk. It is how the category prices repeated context, and any workflow that sends the same long instructions repeatedly should be using it.
The catch is that caching is a prefix match, so anything that changes near the start of your prompt breaks it. A timestamp, a request ID, or a randomly ordered list of items at the top of a system prompt will silently prevent every cache hit. Put the stable content first and the changing content last. That ordering decision is worth real money.
Whenever you do not need the answer immediately. Anthropic''s documentation describes the Batch API as allowing "asynchronous processing of large volumes of requests with a 50% discount on both input and output tokens." OpenAI offers a 50% reduction as well. Half price, for accepting that results arrive later rather than instantly.
For web teams this fits more work than people expect. Generating meta descriptions across a few hundred pages, drafting alt text for an image library, classifying old blog posts, or running a bulk content audit are all jobs where nobody is sitting and waiting. Those should never run at interactive prices.
The two discounts stack, which is where the real savings are. Anthropic''s documentation confirms that "Batch API and prompt caching discounts can be combined." A bulk job with a large shared instruction block, run through batch with caching on, costs a fraction of the same job fired one request at a time.
Our rule is to ask one question of every new automation: does a human need this answer in the next few seconds? If not, it goes to batch. That single question has more impact on the bill than any amount of prompt tuning.
This is the most common overspend we see. Teams pick the most capable model during prototyping, when getting it working matters more than what it costs, and then never revisit the choice once the workflow is running a thousand times a day.
Anthropic''s own guidance is to match the model to the task, suggesting Haiku for simple tasks, Sonnet for most production workloads, and Opus for the most complex reasoning. That maps neatly onto web work. Classifying, extracting, formatting, and summarising are simple tasks. Writing something a client will publish under their name is not.
The arithmetic is stark. At the published August 2026 rates, moving a high-volume classification job from Opus 5 to Haiku 4.5 takes the input price from $5 to $1 per million tokens and the output from $25 to $5. That is a five-fold reduction for work where the cheaper model is genuinely sufficient.
The honest caveat is that cheaper is only cheaper if the output is good enough. A model that needs three attempts to get something right is not saving you anything, and a bad result that reaches a client costs far more than the tokens ever did. Test on real examples before you downgrade anything, and keep the capable model where quality actually matters. We wrote about where that line sits in our notes on reviewing AI written code.
Less than most people fear, once the discounts are on. Anthropic''s documentation gives a worked example for processing 10,000 support tickets at roughly 3,700 tokens per conversation using Claude Haiku 4.5, and puts the total at about $37.00 per 10,000 tickets.
That figure is worth sitting with, because it reframes the whole conversation. Ten thousand handled conversations for the price of a couple of software subscriptions is not an expensive line item. The expensive version of that same workload is the one that runs on the most capable model, interactively, with no caching.
Anthropic''s docs give another useful example for interactive work: a one hour Managed Agents coding session on Claude Opus 5 consuming 50,000 input and 15,000 output tokens comes to $0.705, dropping to $0.525 when 40,000 of those input tokens are cache reads. Note the shape of that saving. Caching alone took roughly a quarter off.
Run this arithmetic before you build, not after. Take your expected volume, estimate tokens per request at roughly 0.75 words per token, and multiply. It takes five minutes and it tells you immediately whether you are designing a $40 a month workflow or a $4,000 one.
Tool use and retrieved content, mostly. Every tool definition you send is input tokens on every request, and every document, web page, or file the model reads becomes input tokens too. These do not appear in your prompt, so they do not feel like something you are paying for.
Anthropic publishes figures that make this concrete. Web search on the Claude API is "$10 per 1,000 searches" on top of token costs, while web fetch has no additional charge beyond the tokens for what it reads. Those tokens add up fast: Anthropic estimates an average 10 kB web page at around 2,500 tokens and a research paper PDF at around 125,000 tokens.
A single unbounded fetch can therefore cost more than hundreds of ordinary requests. If your automation reads external documents, cap how much it takes in rather than letting it swallow whatever it finds.
The other quiet cost is retries. A workflow that fails and retries three times costs three times as much, and failed attempts are billed. If your error handling retries automatically without a ceiling, a broken integration becomes an expensive one. Log spend per run, not just per month.
We start every automation by writing down the expected volume and doing the token arithmetic before any code exists. That estimate becomes the thing we check the first invoice against. Without a prediction there is nothing to notice a surprise against, which is how bills triple quietly.
We default to the cheaper model and move up only where output quality demonstrably requires it, rather than defaulting to the best model and never revisiting. That order matters. Starting expensive and optimising later is a project nobody schedules, so it does not happen.
We also keep prompts stable at the front, which is as much a caching decision as a writing one. Structuring instructions so the unchanging parts come first costs nothing at authoring time and pays every single request afterwards. Our thinking on structuring prompts for web work is in our piece on prompt engineering for web tasks, and the publishing pipeline this blog runs on is described in our notes on AI blog publishing automation.
Three things. Find out which model each of your automations is actually calling, because it is often not the one you think. Check whether prompt caching is enabled on anything that sends the same instructions repeatedly. Then move every job that nobody waits for onto batch processing.
Those three checks are where nearly all of the savings live, and none of them requires rewriting a prompt or reconsidering your strategy. They are configuration, and providers document them precisely because they want you to use them.
After that, set a monthly number you expect to see and actually look at the invoice against it. Cost control is mostly the habit of noticing, and a metered bill nobody reads is the whole problem in one sentence.
If you want help sizing an automation before you build it, or working out why an existing one costs what it does, we are happy to walk through the arithmetic with you. Reach out through phoenix.studio and tell us what you are running.
Tell us where you want to go. We'll tell you how we'd get you there.