Your old prompts are costing you money: anti-patterns and effort calibration
In brief
On September 8, 2026 Anthropic published its own cost-reduction guidance for the Claude Platform, and the surprising part is how much of it is about deleting text. Prompts written for 2024-era models contain instructions that now make frontier models slower, more expensive, and sometimes worse. Anthropic's case studies show 52–73% cost reductions with accuracy held flat or improved.
Contents
Most cost advice for the Claude API is about infrastructure: cache the stable parts, batch the async work, route easy requests to a smaller model. That advice is correct and it is covered in Cutting Claude API costs without cutting quality.
The guidance Anthropic published on September 8, 2026 goes somewhere different. A large share of the savings in its case studies came from removing instructions from prompts — text written for older models that current models no longer need and are actively slowed down by. Reported reductions ran 52–73%, with accuracy maintained or improved on the benchmarks tested.
Three levers: caching, anti-patterns, and effort calibration.
Lever 1 — cache hit rate, not cache usage
Prompt caching is the largest single lever on a repeated-context workload, and most teams have it switched on. Fewer have checked whether it is hitting.
The mechanic to hold onto: the cache matches on an exact prefix. Everything before your breakpoint must be byte-identical between calls. The usual cache killers are things nobody thinks of as part of the prompt:
- A timestamp, request ID, or session ID interpolated near the top of the system prompt.
- Tool definitions that get re-serialized in a different key order.
- A user's name or locale injected before the stable instructions rather than after.
- Any dynamic section placed above a static one.
The fix is ordering, not cleverness: everything stable first, everything variable last, breakpoint between them. Then read the cache_read_input_tokens and cache_creation_input_tokens fields in the usage block of your responses. If creation tokens are close to read tokens across a run, you are paying the write premium repeatedly and getting nothing back — something above your breakpoint is changing.
On Claude Fable 5.1 and Mythos 5.1 this lever got sharper: cache reads are priced at 0.025× base input, versus 0.1× on other models. A cached prefix is four times cheaper to re-read on those models than it used to be, which moves the break-even point for caching down to much shorter prefixes.
Lever 2 — delete the rituals
This is the part that will feel wrong.
Prompts accumulate. A model in 2024 skipped steps, so someone added "think carefully step by step before answering." It hallucinated a field, so someone added "IMPORTANT: you MUST verify each value." It rambled, so someone added a scratchpad section. Each addition fixed something real at the time. None of them were removed when the model changed.
Anthropic's guidance names three families of these as anti-patterns on current frontier models:
Verification rituals. Instructions telling the model to double-check, re-read, or confirm its work before answering. Current models with adaptive thinking already do this internally. The instruction adds tokens, adds latency, and in some cases produces a performative verification paragraph that is theater rather than checking.
Emphasis boosters. ALL CAPS, "IMPORTANT:", "you MUST", "NEVER under any circumstances", the same rule repeated three times in different words. These were load-bearing when instruction-following was weaker. Now they mostly add tokens — and when a prompt has fifteen things marked IMPORTANT, none of them are.
Manual scratchpads. <thinking> blocks and "first write your reasoning, then your answer" scaffolding you built by hand. Models with built-in extended thinking have a real reasoning channel now. A hand-rolled scratchpad duplicates it, in your output tokens, at output prices.
Anthropic ships a Claude Code command for finding these:
/claude-api prompt-audit
Two companions: /claude-api hillclimb iterates on the cost/performance tradeoff, and /claude-api cost-optimize runs a broader audit.
Do not delete on faith. Every one of those instructions was added because something broke. Measure first: take the prompt you have, take the prompt with one family of anti-patterns removed, and run both against a real eval set. If you do not have one, build it first — otherwise you are trading a known cost for an unknown accuracy change, and you will not find out which way it went until a customer does.
Lever 3 — effort calibration
Current Claude models expose an effort setting that controls how much reasoning the model spends before answering. The default is not free, and it is not automatically right for your task.
The comparison most teams never run is the diagonal one:
Does a stronger model at lower effort beat a weaker model at higher effort, at the same price?
Often it does. A stronger model reaching the right answer quickly can cost less than a weaker one grinding through more tokens to get there — and the stronger model's cheap path is usually more reliable than the weaker model's expensive one. You will not discover this by tuning one model's effort up and down, because that only explores one axis.
Practical approach:
- Segment your traffic by task type. Classification, extraction, summarization, and multi-step reasoning have genuinely different effort needs, and an app-wide setting is wrong for most of them.
- For each segment, find the lowest effort that still passes your evals. Do not start from the default and tune down by feel — sweep it.
- Then test the diagonal: the next model up, at an effort level that matches the price you are paying now.
- Re-run this after every model release. The right answer changes; cache-read pricing on Fable 5.1 and Mythos 5.1 already moved it once.
For per-message control mid-conversation, effort can be changed with a role: "system" message carrying output_config.effort, behind the mid-conversation-output-config-2026-07-01 beta header — available on Claude Fable 5.1, Mythos 5.1, and Opus 5, on the Claude API and now on Google Cloud as well. That lets one session run cheap routine turns and spend real effort only on the hard one.
Where to start
If you have one afternoon:
- Instrument first. Pull
cache_read_input_tokens,cache_creation_input_tokens, input, output, and model for every call, grouped by task type. Without this you are guessing, and the guesses are usually wrong about which endpoint is expensive. - Fix cache ordering. Cheapest change with the largest effect on a repeated-context workload, and it carries no accuracy risk.
- Run
/claude-api prompt-auditon your largest system prompt. Read what it flags. Delete nothing yet. - Build or dust off an eval set for that endpoint, then delete one family of anti-patterns and compare.
- Sweep effort on your highest-volume task type, then test one model up at lower effort.
The ordering is deliberate. Steps 1 and 2 are safe. Steps 3 through 5 change model behavior, and without step 1 you cannot tell whether they helped.