WEBVTT

1
00:00:01.300 --> 00:00:08.483
This is Anthropic, Read Aloud. Today: Reducing cost and improving performance with Claude Platform.

2
00:00:09.783 --> 00:00:13.330
Reducing cost and improving performance with Claude Platform.

3
00:00:13.780 --> 00:00:20.903
Tuning prompt caching, instructions, and effort can reduce Claude's cost without sacrificing application performance.

4
00:00:21.353 --> 00:00:25.257
From Claude Blog, published September 8, 2026.

5
00:00:26.257 --> 00:00:49.169
Performance and cost are often viewed as a trade-off: to spend less, you accept worse results. In practice, we've found that many applications using Claude Platform can cut costs without giving up performance with three fixes: maximize the prompt cache hit rate, remove anti-patterns from your prompts when upgrading to frontier Claude models, and calibrate effort to the task.

6
00:00:49.289 --> 00:01:01.534
We've put this guidance into the claude-api skill. In this article, we show how Claude Code with the claude-api skill can often find ways to reduce cost while maintaining or improving performance.

7
00:01:02.334 --> 00:01:03.218
Prompt cache.

8
00:01:03.668 --> 00:01:23.413
Before Claude generates a response, it first processes your prompt into an internal working state. This step, called prefill, is the expensive part of handling input. Prompt caching saves that state (the key to value, or KV, cache): when a request starts with the same prefix, Claude reads it back instead of recomputing it.

9
00:01:23.533 --> 00:01:26.894
Cache reads are billed at a fraction of the full input price.

10
00:01:27.344 --> 00:01:45.038
There are a few practical considerations to ensure effective use of the prompt cache. First, the prompt cache is pinned to a specific model. Second, prompt cache reads must be byte-exact across the prompt prefix. Finally, the prompt cache has a limited time-to-live (TTL).

11
00:01:45.488 --> 00:01:48.731
With these points in mind, there are a few practical tips:

12
00:01:49.181 --> 00:02:07.143
Be careful changing effort setting mid-conversation. These settings render into the prompt ahead of your content, so they are part of the cached prefix. Only with select Claude models, including Opus 5 and Fable 5.1, can you update effort mid-conversation without breaking the cache.

13
00:02:07.593 --> 00:02:16.381
Keep volatile values out of the prefix. A dynamic timestamp or I D in the system prompt can change across model calls, and break the cache.

14
00:02:16.831 --> 00:02:30.676
Avoid tool definitions that reorder themselves. When using the Claude Messages A P I, the prompt is assembled in a fixed order with tool definitions rendered at the top. Any change to the tool definition will break the cache.

15
00:02:31.126 --> 00:02:42.035
Be careful when forking conversations. Subagents and branches only share the parent’s cache when the fork’s prefix is byte-identical, on the same model, and using the same effort.

16
00:02:42.835 --> 00:02:43.795
How to fix it.

17
00:02:44.245 --> 00:02:47.593
We’ve accumulated a few lessons for prompt cache management:

18
00:02:48.043 --> 00:03:02.976
Monitor your prompt cache hit rate carefully. Claude Console and the cache diagnostics A P I provide prompt cache diagnostics, including reasons for prompt cache misses (Figure 1) and exactly where two requests diverged.

19
00:03:03.426 --> 00:03:15.328
Figure 1: Figure 1. Claude Console can diagnose unexpected prompt cache misses by comparing consecutive requests and identifying exactly where the prompt prefix diverged.

20
00:03:15.778 --> 00:03:30.711
Monitor your prompt cache hit rate carefully. Claude Console and the cache diagnostics A P I provide prompt cache diagnostics, including reasons for prompt cache misses (Figure 1) and exactly where two requests diverged.

21
00:03:31.161 --> 00:03:46.094
Monitor your prompt cache hit rate carefully. Claude Console and the cache diagnostics A P I provide prompt cache diagnostics, including reasons for prompt cache misses (Figure 1) and exactly where two requests diverged.

22
00:03:46.544 --> 00:04:01.599
Defer rarely used tools. Declare all your tools up front but mark the rarely used ones defer loading: they stay out of the cached prefix and are appended into the conversation only when Claude looks them up with tool search, so the cache is preserved.

23
00:04:02.049 --> 00:04:13.560
Apply system prompt updates as messages. Claude Platform lets you add a system instruction as a message mid-conversation instead of editing the system prompt, which preserves the cache.

24
00:04:14.010 --> 00:04:25.198
Lay out the request out so the stable part stays stable. Add static context (tool definitions and the system prompt) first and the growing conversation behind them (Figure 2).

25
00:04:25.648 --> 00:04:33.115
Figure 2: Figure 2. Organize prompts to ensure dynamic content is appended to the end of a stable prefix.

26
00:04:33.565 --> 00:04:48.825
Make changes to model or effort when the prompt cache will already be broken. Certain operations, like compaction, already rewrite much of the cache (the conversation). That is a good moment to switch model or effort, since you are paying for a miss anyway.

27
00:04:49.275 --> 00:04:58.874
Move the cache breakpoint as the conversation grows. With Claude Platform, you can set automatic caching to apply the cache breakpoint to the last cacheable block.

28
00:04:59.324 --> 00:05:18.417
Pre-warm the cache. To reduce latency, send a request with max tokens: 0 and an explicit cache breakpoint. This processes the prompt and writes it to the cache without generating anything. If you run it at session start (for example, while a user is typing), the first real request hits a warm cache.

29
00:05:18.867 --> 00:05:39.881
Don’t exceed the prompt cache TTL. The 5-minute cache TTL counts from the start of the request. If an agent blocks on tool calls or subagent requests that run longer than 5 minutes, the parent's cache expires before the result comes back. In cases like this, consider setting a 1-hour TTL on the prefix instead.

30
00:05:40.681 --> 00:05:41.593
Instructions.

31
00:05:42.043 --> 00:05:58.082
Prompts can accumulate instructions that patch model weaknesses. These instructions can drift relative to the capabilities of the latest Claude models. Here are common prompting “anti-patterns” that hobble frontier Claude models and can inadvertently increase costs:

32
00:05:58.532 --> 00:06:09.962
Verification rituals. Instructions like " double-check your work ” or " verify twice before responding ” are often taken literally by frontier models and can waste tokens.

33
00:06:10.412 --> 00:06:20.879
Thoroughness and emphasis boosters. " Be maximally thorough," " CRITICAL: YOU MUST ALWAYS... " can lead to verbosity and extra tool calls when working with frontier models.

34
00:06:21.329 --> 00:06:38.927
Mandatory procedures and scratchpad scaffolds. Fixed step processes (for example, " think step by step in a scratchpad ") or reasoning templates are rituals that frontier models don't need. This scaffolding can stack on top of native reasoning and use unnecessary tokens.

35
00:06:39.377 --> 00:06:49.790
Stale examples. Few-shot examples tuned to an older model's failure modes can teach a frontier model to imitate long reasoning chains on requests that don't need them.

36
00:06:50.240 --> 00:07:07.341
Contradictory rules. Frontier models are better at instruction following. Contradictory instructions ("always refund within policy" versus "never issue refunds without escalation") can be followed more literally by frontier models, resulting in degraded performance.

37
00:07:07.791 --> 00:07:19.288
Dated configuration. Settings written for an older Claude generation (for example, manual thinking budgets) can be rejected by Claude Platform when upgrading to frontier models.

38
00:07:20.088 --> 00:07:21.048
How to fix it.

39
00:07:21.498 --> 00:07:44.599
We've updated the claude-api skill with a new command that watches out for these anti-patterns. In Claude Code, run /claude-api prompt-audit against your prompts, skills, or tool descriptions. The audit covers anything in your working directory, including application code that calls the Claude A P I and Claude Code's own configuration (for example, CLAUDE.md or skills).

40
00:07:45.049 --> 00:08:08.025
For example, we tested a model migration from Opus 4.8 to Opus 5 on a customer support benchmark. We started from a clean prompt and 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), giving six legacy prompts.

41
00:08:08.475 --> 00:08:22.426
We ran each on Opus 4.8, on Opus 5 with only the model I D changed, and on Opus 5 after running /claude-api prompt-audit once per prompt (Figure 3 shows the average across the six).

42
00:08:22.876 --> 00:08:30.897
Figure 3: Figure 3. The effect of prompting anti-patterns during model migration from Opus 4.8 to Opus 5.

43
00:08:31.347 --> 00:08:38.491
Figure 3, The effect of prompting anti-patterns during model migration from Opus 4.8 to Opus 5.

44
00:08:38.941 --> 00:08:53.851
With Opus 5, verification rituals (" verify twice ") use unnecessary tokens by duplicating order lookup on every refund. Emphasis boosters (" be maximally thorough ") became dozens of unneeded knowledge-base searches.

45
00:08:54.301 --> 00:09:18.054
Running /claude-api prompt-audit removed the anti-patterns, decreasing costs by 14.6 percent and increasing accuracy by 5.3 percent on average. Cost dropped because extra tool calls and duplicated reasoning were eliminated. Accuracy rose for three reasons. The retired thinking setting made the A P I reject every routing request outright.

46
00:09:18.174 --> 00:09:35.054
The contradictory refund rules led Opus 5 to withhold four refunds it owed while it asked the customer to confirm. And the manual scratchpad collided with Opus 5's built-in thinking: on three tickets it wrote the tool call inside its reasoning and never executed it.

47
00:09:35.854 --> 00:09:36.494
Effort.

48
00:09:36.944 --> 00:09:48.711
Effort tells Claude “how hard to work.” At low effort Claude generally reaches conclusions faster. At high effort, Claude deliberates, verifies, and explores alternatives before answering.

49
00:09:49.161 --> 00:10:21.346
Cost-versus-performance across effort levels on a single model can vary. For example, Claude Fable 5 scores 11.5 percent at low effort for 5.35 dollarsper task on FrontierCode Diamond (the hardest 50 tasks). At max effort, Fable 5 gets 30.9 percent for 19.00 dollarsper task; changing effort raises the score about 2.7 x (+19 points) for about 3.5 x the cost (Figure 4).

50
00:10:21.796 --> 00:10:45.028
On Claude Fable 5.1, Humanity's Last Exam (without tools) shows a steep curve with a diminishing last step. It scores about 53 percent at low effort for about 0.30 dollarsper question and about 61 percent at max effort for about 2.23 dollars; the last step up to max adds about half a point for 46 percent more cost.

51
00:10:45.148 --> 00:10:50.507
The gain falls inside the benchmark's run-to-run noise, so you pay more for no measurable gain.

52
00:10:50.957 --> 00:10:58.087
Figure 4: Figure 4. Fable 5 performance versus cost across effort levels on FrontierCode Diamond.

53
00:10:58.537 --> 00:11:01.086
Effort can be miscalibrated in either direction:

54
00:11:01.536 --> 00:11:17.012
Assuming higher is always better. High effort can cause over- thinking. Claude spends more time deliberating than the task warrants, which adds cost and latency and can degrade answer quality. Deliberation only helps while there's still evidence to find.

55
00:11:17.462 --> 00:11:36.561
Biasing to low effort. Set too low, Claude stops before it has enough evidence. It makes fewer tool calls, so it may answer from the first search result instead of the third. It thinks less on hard steps and skips the check it would normally run on its own. The answer looks finished, but it's built on partial information.

56
00:11:37.361 --> 00:11:38.321
How to fix it.

57
00:11:38.771 --> 00:11:41.101
There are some useful ways to calibrate effort:

58
00:11:41.551 --> 00:12:00.730
Test stronger models at lower effort. A stronger model at low effort can be cheaper than a weaker model working hard (high effort). For example, on CursorBench 3.2, Claude Fable 5.1 at low effort matches the performance of Fable 5 at high effort at a third of the cost (Figure 5).

59
00:12:00.850 --> 00:12:22.588
Two things make the newer model cheaper: at low effort it does less work per task, and Fable 5.1's prompt-cache reads are priced at 0.25 dollarsper million tokens versus 1.00 dollarsfor Fable 5. Even at Fable 5's prices, Fable 5.1 at low effort would cost about 40 percent less.

60
00:12:23.038 --> 00:12:30.676
Figure 5: Figure 5. Fable 5 versus Fable 5.1 across effort levels on CursorBench 3.2.

61
00:12:31.126 --> 00:12:53.193
Understand your task shape. Measuring application performance across a sweep of effort levels is a useful way to understand the cost-performance tradeoff for your particular task. On a non-saturated evaluation, a flat cost-performance curve across effort levels suggests that the task is not bound by thinking compute; increasing effort is not beneficial.

62
00:12:53.643 --> 00:13:12.605
This calibration often involves running an evaluation across models and effort levels. In Claude Code, /claude-api hillclimb performs this search for you: it splits your evaluation into train and test sets, proposes configuration changes, and reads failing train examples to fix what it finds.

63
00:13:13.055 --> 00:13:37.175
We ran it on a customer support benchmark, starting from Opus 4.8 at its default (high) effort. The hillclimber first tried Opus 5 at low effort, applying prompt-audit to remove mandatory tool-call rituals, scratchpad steps, and contradictory rules. That cleared the Opus 4.8 baseline at 98.9 percent train accuracy and cut cost to 2.6 cents per ticket.

64
00:13:37.625 --> 00:13:45.018
Figure 6: Figure 6. Hillclimbing improves cost and performance by updating model choice, effort, and prompt.

65
00:13:45.468 --> 00:14:04.381
It then stepped down to Sonnet 5 at low effort, which was cheaper still at 1 cent per ticket, but accuracy fell to 88.9 percent. Reading the failing train tickets, Claude added routing rules and a refund-cap cross-reference to the prompt, bringing Sonnet 5 back to 98.9 percent at the same cost.

66
00:14:04.831 --> 00:14:16.998
On the 14 held-out tickets the search never saw, the final configuration scored 90.5 percent against the original setup's 78.6 percent, at about one fifth the cost.

67
00:14:17.798 --> 00:14:19.421
Automating cost reduction.

68
00:14:19.871 --> 00:14:43.630
Prompt caching, instructions, and effort are common levers for reducing cost. Our documentation covers even more. To run a holistic cost audit of application code that uses the Claude A P I, we've added /claude-api cost-optimize: it profiles where your spend goes, applies cost reductions, and, if you provide an evaluation, shows how savings trade off with performance.

69
00:14:44.080 --> 00:15:02.527
cost-optimize starts by finding where your tokens go: from your organization's usage and cost reports if you have a Claude Admin A P I key, from the usage object on each A P I response if your application logs it, or, failing both, by reading your request-building code and estimating.

70
00:15:02.977 --> 00:15:20.910
It then ranks the available savings, starting with prompt caching, trimming what each request carries (including a prompt-audit), bounding output, and batching unattended work. If you supply an evaluation, it goes further and computes cost and performance across effort levels and model choices.

71
00:15:21.360 --> 00:15:26.947
We ran this on four public benchmarks, starting with Sonnet 5 as a baseline (Figure 7):

72
00:15:27.397 --> 00:15:50.053
LegalBench (about 58 percent lower cost): cost-optimize proposed caching a shared prefix across tasks, setting low effort, and processing tasks via the Batch A P I. Thinking tokens fell from 102779 to 8284, but pass rate stayed within noise and cost dropped by about 58 percent.

73
00:15:50.503 --> 00:16:03.884
tau2-bench retail (about 73 percent lower cost): By implementing prompt caching with explicit breakpoint placement, cost-optimize reduced spend by 73 percent while keeping pass rate flat.

74
00:16:04.334 --> 00:16:18.720
OfficeQA Pro (about 52 percent lower cost): cost-optimize added batch processing and document caching, which brought cost down from 136.20 dollarsto 64.87 dollars.

75
00:16:19.170 --> 00:16:43.433
S W E-bench Verified (about 55 percent lower cost): cost-optimize found that the default config already caches correctly. Savings came from setting effort to medium and constraining the agent’s output to just a few concise sentences. Median steps per task went from 29 to 17 and prompt tokens fell from 75.2 million to 33.7 million.

76
00:16:43.883 --> 00:16:51.314
Figure 7: Figure 7. Cost and performance change across benchmarks with /claude-api cost-optimize.

77
00:16:52.114 --> 00:16:53.126
Getting started.

78
00:16:53.576 --> 00:17:13.843
Start with /claude-api prompt-audit when you've migrated to a frontier Claude model and want to check your existing prompts against it. It scans the prompts, skills, and tool descriptions in your working directory. This can be application code that calls the Claude A P I or Claude Code's configuration (CLAUDE.md, skills).

79
00:17:13.963 --> 00:17:17.692
It removes common anti-patterns that hobble frontier models.

80
00:17:18.142 --> 00:17:41.737
Reach for /claude-api cost-optimize when your application uses the Claude A P I and you want a cost audit. It profiles token spend and then tests different levers: it applies prompt-audit, but also checks for ways to lower cost via prompt caching, batching unattended work, or bounding output. If you provide an evaluation, it measures the effort and model selection trade-offs.

81
00:17:42.187 --> 00:18:05.377
Finally, use /claude-api hillclimb for an iterative search over cost and performance. Given an evaluation, Claude splits it into train and test sets, then proposes updates to your application that aim to reduce cost while maintaining baseline performance. Claude reads the failing train cases to guide the search, and the final configuration is scored on the held-out test set.

82
00:18:05.827 --> 00:18:06.695
To learn more:

83
00:18:07.145 --> 00:18:08.642
See our documentation, here.

84
00:18:08.882 --> 00:18:10.094
See our cookbook, here.

85
00:18:11.094 --> 00:18:28.707
That was Reducing cost and improving performance with Claude Platform, from Claude Blog, published September 8, 2026. Read the original at claude dot com. This unofficial audio edition was generated automatically for the podcast Anthropic, Read Aloud.