Anthropic published new guidance this week on reducing cost and improving performance with the Claude Platform, and the advice boils down to three things most teams can fix today: prompt caching, cleaning up legacy instructions, and calibrating how hard the model works on each task. The company demonstrated these techniques across multiple benchmarks, showing cost reductions of 14% to 58% without sacrificing accuracy, and in some cases improving it.
The guidance arrives as teams using Claude face a common frustration. Performance and cost are usually treated as a trade-off. Spend less and you get worse results. Anthropic's argument is that this framing is wrong for most applications. The real problem is that prompts accumulate cruft, effort levels are set once and never revisited, and caching is either ignored or implemented poorly.
Why prompt caching matters more than you think
Before Claude generates a response, it processes your input into an internal working state. This prefill step is the expensive part of handling input. Prompt caching saves that state as a key-value cache. When the next request starts with the same prefix, Claude reads the cached version instead of recomputing it. Cache reads are billed at a fraction of the full input price.
The practical details matter. The cache is pinned to a specific model. You cannot share a cache between Sonnet 4 and Opus 5. Cache reads must be byte-exact across the full span of the prompt. Any difference in the input, even whitespace, invalidates the cache hit. And the cache has a limited time-to-live, so you cannot just build a cache once and expect it to last forever.
Anthropic suggests a concrete trick for warming the cache. Set max_tokens to 0 and include an explicit cache breakpoint. This processes the prompt and writes it to the cache without generating anything. If you run this at session start, for example while a user is typing, the first real request hits a warm cache instead of paying for prefill twice.
Prompt anti-patterns that cost you money
Instructions accumulate over time. Teams add rules to patch weaknesses in older models, and those rules stick around even after the weaknesses are fixed. Anthropic identified several anti-patterns that specifically hurt frontier Claude models and increase costs unnecessarily.
The list includes retired thinking settings that the new model no longer needs, contradictory instructions that force the model into hedging behavior, manual scratchpads that collide with the model's built-in reasoning, and emphasis boosters like "be maximally thorough" that trigger dozens of unnecessary tool calls. Verification rituals like "verify twice" cause the model to duplicate work on every request.
Anthropic tested this by migrating a customer support benchmark from Opus 4.8 to Opus 5. They started with a clean prompt and planted one anti-pattern at a time, creating six legacy prompts. With Opus 5 and only the model ID changed, the anti-patterns caused real problems. The retired thinking setting made the API reject every routing request outright. Contradictory refund rules led the model to withhold four refunds it owed while asking the customer to confirm. The manual scratchpads collided with Opus 5's built-in thinking, causing the model to write tool calls inside its reasoning and never execute them.
Running /claude-api prompt-audit removed the anti-patterns. Costs dropped by 14.6% on average because extra tool calls and duplicated reasoning were eliminated. Accuracy increased by 5.3% because the model was no longer fighting contradictory instructions or wasting effort on unnecessary verification steps.
Effort calibration is the biggest lever
Effort tells Claude how hard to work on a given task. At low effort, the model reaches conclusions faster. At high effort, it deliberates, verifies, and explores alternatives before answering. The right setting depends entirely on the task, and most teams pick one level and apply it everywhere.
The numbers are stark. On FrontierCode Diamond, the hardest 50 tasks in a coding benchmark, Claude Fable 5 scores 11.5% at low effort for $5.35 per task. At max effort, it scores 30.9% for $19.00 per task. That is a 2.7x improvement in score for 3.5x the cost. The trade-off is real but the math works in your favor if accuracy matters.
But the reverse is also true. On Humanity's Last Exam without tools, Claude Fable 5.1 scores about 53% at low effort for $0.30 per question and about 61% at max effort for $2.23. The last step up to max adds about half a percentage point for 46% more cost. That gain falls within the benchmark's run-to-run noise, so you are paying more for no measurable improvement. Running every query at max effort is burning money on tasks where low effort would perform identically.
Automated optimization through hill climbing
Anthropic built tools to automate this calibration. The /claude-api hillclimb command splits an evaluation into train and test sets, proposes configuration changes, reads failing train examples to fix what it finds, and scores the final configuration on held-out test data.
The results on a customer support benchmark demonstrate the approach. Starting from Opus 4.8 at default high effort, the hillclimber first tried Opus 5 at low effort with prompt-audit applied. That configuration cleared the Opus 4.8 baseline at 98.9% train accuracy and cut cost to 2.6 cents per ticket. It then stepped down to Sonnet 5 at low effort, which dropped accuracy to 88.9% at 1 cent per ticket. Reading the failing train tickets, the tool added routing rules and a refund-cap cross-reference to the prompt, bringing Sonnet 5 back to 98.9% at the same cost.
On 14 held-out tickets the search never saw, the final configuration scored 90.5% against the original setup's 78.6%, at roughly one fifth the cost. The automated search found a combination of model, effort level, and prompt improvements that a human tuner would likely miss.
What this means for teams using Claude
The /claude-api cost-optimize command takes a broader view. It profiles where token spend goes, applies cost reductions including prompt caching, batching unattended work, and bounding output, and if you provide an evaluation, measures the trade-off across effort levels and model choices. On four public benchmarks starting from Sonnet 5, it reduced thinking tokens from 102,779 to 8,284 while keeping pass rate within noise. Cost dropped by approximately 58%.
For teams already on Claude, the immediate action is to run prompt-audit against your existing prompts after migrating to a frontier model. The anti-patterns that worked on older models are actively costing you money and accuracy on newer ones. Then look at effort settings. Most applications have a mix of simple and complex tasks, and applying max effort to everything is the most expensive mistake you can make.
The tools Anthropic released are available now in Claude Code. They work on application code that calls the Claude API, prompt files, skills, and tool descriptions. The guidance is clear: you do not need to accept worse performance to spend less, but you do need to audit what your prompts are actually doing and whether the effort you are paying for is earning its keep.