Reduce API costs with
three Claude Code commands

The commands are part of claude-api, a set of instructions and scripts for Claude Code in Anthropic's open anthropics/skills repository. Lance Martin, an Anthropic engineer working on Claude Platform and this skill, described their use and benchmark results in a September 8, 2026 blog post. Our earlier article, Cost per task, not per token (August 21, 2026), covers the underlying caching, prompting and effort mechanisms.

The commands differ in whether they need an evaluation, or an eval: a set of tasks for comparing accuracy and cost across configurations.

Anthropic presents these as different starting points: check prompts after a model upgrade, audit costs for an API application, or use an eval to search for a better configuration. Prompt auditing and the initial cost audit can begin before an eval is available.

Anthropic tested prompt-audit on a customer support benchmark during a migration from Opus 4.8 to Opus 5. Starting with a clean prompt, the team planted one anti-pattern at a time: a retired thinking setting, a pair of contradictory refund rules, a manual scratchpad, verify twice, be maximally thorough and a mandatory six-step procedure. This produced six legacy prompts.

Each prompt was evaluated in three configurations: Opus 4.8, Opus 5 with only the model ID changed, and Opus 5 after /claude-api prompt-audit had been run once on that prompt. Figure 3 averages the six prompts. In the text, the audit decreased cost by 14.6% and increased accuracy by 5.3% on average. The figure shows Opus 4.8 legacy at 2.52¢ and 89.4%, Opus 5 unaudited at 3.43¢ and 91.7%, and Opus 5 audited at 2.93¢ and 97.0%. It annotates the audit step as +5.3 pts and −0.49¢.

The blog attributes the cost drop to the removal of extra tool calls and duplicated reasoning. On Opus 5, verify twice duplicated the order lookup on every refund. The instruction be maximally thorough triggered dozens of unneeded knowledge-base searches.

Three specific failures explain the accuracy improvement in the blog's account:

• A retired thinking setting caused the API to reject every routing request.
• Conflicting refund rules led Opus 5 to withhold four refunds it owed while asking the customer to confirm.
• A manual scratchpad interfered with Opus 5's built-in thinking. On three tickets, the model wrote a tool call inside its reasoning but never executed it.

The 14.6% cost reduction and 5.3% accuracy increase were measured using an evaluation. Without one, the anti-patterns can still be removed, but their effect on task performance cannot be measured. The same applies to the effort tradeoff.

On FrontierCode, Cognition's coding benchmark, Fable 5 completed the Diamond subset of the 50 hardest tasks with a score of 11.5% at low, costing $5.35 per task. At max, it reached 30.9% at $19.00 per task. Raising effort therefore produced about 2.7x the score (+19 points) for about 3.5x the cost. Figure 4 annotates the difference as +19.4 pts; it does not label the intermediate levels with point values.

The final effort increase delivered less on Humanity's Last Exam, the 2,500-question expert-level benchmark from the Center for AI Safety and Scale AI. In Anthropic's test without tools, Fable 5.1 scored about 53% at low for about $0.30 per question and about 61% at max for about $2.23. The last step to max added about half a point for 46% more cost. The blog places that gain within normal run-to-run variation and concludes that the extra spending bought no measurable improvement.

A newer model can also change the tradeoff. On CursorBench 3.2, Cursor's agentic coding benchmark built from real Cursor sessions, Fable 5.1 at low matches Fable 5 at high at a third of the cost. The blog attributes the difference to less work per task at low effort and cheaper prompt-cache reads: $0.25 per million tokens for Fable 5.1, compared with $1.00 for Fable 5. Even at Fable 5's prices, Fable 5.1 at low effort would cost about 40% less. Figure 5 shows the curves' relative positions without numeric point labels.

Effort can be set too high or too low, the blog cautions. At high effort, Claude may deliberate longer than a task warrants, adding cost and latency and potentially reducing answer quality. At low effort, it may stop before gathering enough evidence. As the source puts it, "it may answer from the first search result instead of the third." It may also skip checks it would otherwise perform, leaving an apparently complete answer based on partial information.

To calibrate effort, Anthropic suggests testing stronger models at lower settings and measuring performance across effort levels. If an eval is not already saturated and the performance-cost curve stays flat, the task may not be limited by thinking compute. Increasing effort would then offer no benefit. hillclimb automates this search across models and effort levels.

On the 14 held-out tickets, the final configuration reached 90.5% decision accuracy, compared with 78.6% for the original, at about one fifth the cost. These are test-set results, separate from the training-set comparison of 98.9% against the 74.4% baseline. Switching to Sonnet 5 initially reduced training accuracy. Reading the failed tickets and adding prompt rules restored it without increasing cost. The search changed the model, effort and prompt, then tested the resulting configuration on tickets it had not seen.

The command ranks prompt caching first, followed by trimming what each request carries, including running prompt-audit. It then bounds output and moves unattended work to the Batch API. Only when an evaluation is available does cost-optimize calculate cost and performance across effort levels and model choices.

Anthropic ran the command on four public benchmarks, each beginning with Sonnet 5.

On LegalBench, a legal-classification benchmark, it proposed caching a shared prefix, using low effort, and sending tasks through the Batch API. Thinking tokens fell from 102,779 to 8,284, the pass rate remained within noise, and cost was ~58% lower.

On tau2-bench retail, the retail scenario of a customer-service agent benchmark, explicit prompt-cache breakpoint placement reduced cost by 73% while keeping the pass rate flat.

On OfficeQA Pro, a document question-answering benchmark, batch processing and document caching reduced cost from $136.20 to $64.87, a reduction of ~52%.

On SWE-bench Verified, an agentic coding benchmark, the default configuration already cached correctly. Savings came from setting effort to medium and restricting the agent's output to a few concise sentences. Median steps per task fell from 29 to 17, while prompt tokens fell from 75.2M to 33.7M, producing ~55% lower cost.

All four score-change confidence intervals span zero. The source of the savings differs: caching accounts for the reduction on tau2-bench retail, while SWE-bench Verified already cached correctly and benefited from lower effort and shorter output. cost-optimize starts with the application's spending and chooses the relevant changes.

For stable prefixes, the blog recommends deferring rarely used tools with defer_loading: keep their declarations, but leave them out of the cached prefix until Claude finds them through tool search. System instructions can be updated by appending a message rather than editing the original system prompt. Static content, including tools and system instructions, comes before the growing conversation.

For model or effort changes, the blog recommends making them when the cache will already be rewritten, such as during conversation compaction. As a conversation grows, the cache breakpoint moves with it; automatic caching can place the breakpoint on the last cacheable block.

Pre-warming handles the initial cache write in advance. A request with max_tokens: 0 and an explicit cache breakpoint processes and stores the prompt without generating output. Sent at session start, for example while a user is typing, it lets the first real request read a warm cache.

Time spent waiting for tools counts toward the cache lifetime. The 5-minute TTL starts when the request begins. If a tool or subagent takes longer than 5 minutes, the parent cache may expire before the result returns. The next turn must rewrite it at 1.25× the input price, or 2× for a 1-hour cache. For long waits, the blog suggests considering a 1-hour TTL on the prefix.