Programmers worldwide are essentially giving Anthropic free money! The official side finally can no longer stand by and watch this situation.

Just now, Anthropic released a blog post.

The core message is: Folks, stop burning tokens for no good reason, we can't bear to watch it anymore!

To this end, the official has detailed six practical cost-saving tips, shared as follows:

1. Run /clear as soon as you finish the task. Clear the current conversation right after fixing a bug, don't drag files and command outputs from the previous task into the next one to waste context space unnecessarily.

2. Set the model and effort level right at the start. If you switch them halfway, all previously accumulated prompt cache will be invalidated, and the entire conversation history will be recalculated at full price.

3. Reference files with @ instead of typing paths manually. Attach files directly to the message with @, so Claude doesn't need to spend an extra tool call to read them. If you only type the file name, Claude might search around first and open several files to test, all these operations will be added to the conversation history and carried in every subsequent turn.

4. Add a quiet flag to commands that generate large outputs. Add a configuration line like --reporter=dot in CLAUDE.md, so that test outputs only print a few lines of summary instead of hundreds of lines of details. The shorter the output, the less context it occupies.

5. Run /compact before you take a break. Compress the conversation while it's still in the cache, the cost is only one tenth of the normal rate. If you wait until the cache expires to compress, you have to re-read everything at full price before compression.

6. Assign heavy output tasks to sub-agents. The sub-agent runs in an independent context window, and only sends back the final conclusion after finishing the task. The files it reads and the command outputs generated during the process will not enter your main conversation.

The full lifecycle of a single token

When you work with Claude Code, the API is billed on a usage basis, and the subscription monthly fee has three tiers ranging from 20 USD to 200 USD.

According to official estimates, developers consume an average of 13 USD worth of tokens per day, with monthly spending between 150 USD and 250 USD.

This is only the average level. For the same bug fix, different query methods can lead to costs differing by several times.

Moreover, every conversation turn resends all the content from all previous turns, the longer the session, the more expensive each turn will be.

To understand where all this money goes, we need to start with the token pricing logic.

Every time you enter a command in Claude Code, two things happen behind the scenes.

The first step is called prefill, which means the model reads your entire request in one go, including the system prompt, CLAUDE.md, your message, and everything accumulated in previous conversations. All of these are input tokens.

The second step is called decode, which is the process where the model generates content word by word, including its reasoning, tool calls, and the text you finally see. All of these are output tokens.

Here lies the key difference.

Prefill is parallel, processing all input tokens through the GPU in a single pass. Decode is serial, running the model once for every single token generated. A 200-token response requires 200 independent computation runs.

That's why it's easy to understand why output tokens cost 5 times more than input tokens.

On this basis, the final bill depends on two factors.

The first is the model, which determines the unit price of each token.

For Opus 5, input costs 5 USD per million tokens, output costs 25 USD.

For Sonnet 5, input costs 2 USD, output costs 10 USD.

For Haiku 4.5, input costs 1 USD, output costs 5 USD.

The second is the effort level, which determines the total number of tokens.

Most of the output tokens in a session are reasoning tokens, which is exactly what the effort level controls. The higher the effort level, the longer the model thinks, the more reasoning tokens it outputs. The difference between max and low levels can be several times.

Use Sonnet for most common tasks, and only switch to Opus for the most challenging problems. Spending premium prices on trivial tasks is the most unnecessary waste.

Prompt caching is the most powerful cost-saving tool

There is another huge variable in token pricing, which is caching.

Every request in Claude Code starts with the same prefix, which is the system prompt, tool definitions, CLAUDE.md and conversation history.

If the prefix of this request is exactly the same byte by byte as the previous one, the server will not recalculate it, and directly load the computation results from last time.

Cache reading only costs 0.1 times the normal input price, which directly cuts 90% of the cost.

Writing to cache is slightly more expensive, up to 2 times the normal rate. But writing only happens once, and every subsequent turn enjoys the 0.1x reading rate.

Here is an example.

Suppose your conversation history has 50,000 tokens. Without caching, you have to pay the full price just to re-read these 50,000 tokens in every turn. But as long as the cache is hit, the same 50,000 tokens only cost one tenth of the price.

For a session running 20 to 30 turns, the accumulated discount from cache hits is a staggering amount.

This is the biggest leverage you can use to cut costs.

But caching has a fatal weakness. It must match continuously starting from the very first byte of the request. If any part in the middle changes, everything after that point will be completely invalidated.

Specifically, there are six scenarios that invalidate the cache:

1. Switching models with /model: Each model has independent cache. If you switch from Sonnet to Opus, the entire conversation history will be refilled at Opus's price, with no discount.

2. Switching effort level with /effort: The effort level is also part of the cache key, switching it will trigger full recalculation of the entire conversation history.

3. Toggling Fast mode: The effect is the same as the two scenarios above, the cache is directly invalidated.

4. Compressing the conversation with /compact: The conversation is rewritten into a summary, which no longer matches the original content, and the old cache is completely invalidated.

5. Cache expiration: Subscriber users' cache is kept alive for 1 hour, API users' cache lasts 5 minutes by default. After timeout, the next turn will trigger full recalculation.

6. Restoring old sessions: The cache has long been lost after a long gap, almost 100% of the time you need to recalculate everything at full price.

The bad news is that hitting any one of these scenarios means the entire conversation history price bounces back from 0.1x to full price.

The good news is that once you know what causes cache invalidation, you know how to preserve it.

For example, lock the model and effort level at the very beginning of the session, and never switch them throughout the process. Don't run /compact while the cache is still warm, run it only when you are about to take a break.

There is also a hidden pitfall here.

The opusplan mode switches models every time you enter and exit the plan. Every time you enter, the cache is invalidated once. Every time you exit, it gets invalidated again. If you jump back and forth, every transition costs a full-price prefill.

Your session is getting bigger secretly

Caching helps you reduce the cost of resending history to one tenth of the original.

But there is one thing it cannot help with: your history itself is expanding turn by turn.

Every time Claude reads a file, the file content is appended to the conversation. Every time Claude runs a command, the output is also appended. Starting from that append turn, all subsequent turns will carry that extra content.

The 40th conversation turn resends all the accumulated content from turn 1 to turn 39.

This kind of growth follows a near-quadratic O(n²) pattern.

Claude Code has a fallback mechanism.

If a command output exceeds 30,000 characters, it will not be added to the conversation directly, but written to a temporary file, with only a single line of summary left in the conversation. But outputs under 30,000 characters are not managed by this rule.

For example, after a test framework finishes running, it prints 400 lines of pass records, each with dozens of characters, the total is less than 30,000, so it doesn't hit this threshold.

As a result, these 400 lines stay in the conversation history as they are, and get resent in every subsequent turn.

To solve this problem, Anthropic's blog post shared several very practical slimming methods.

1. Reference files with @.

Don't manually type paths to let Claude find files by itself. @ referencing attaches the file directly to the message, saving a redundant read operation.

If you only mention the file name, Claude might first run grep searches, open several files to check which one is correct. All these trial operations will be added to the conversation history, unnecessarily increasing costs.

2. Add quiet flag to noisy commands.

Add the line "run tests with npx vitest run <file> --reporter=dot" in CLAUDE.md, so that every test run only outputs a few lines of dot results instead of hundreds of lines of details. One minute of configuration saves hundreds of lines of context for every future session.

3. Isolate heavy output tasks with subagents.

The subagent runs in its own independent context window, only sends back the answer after finishing the task, all files read and command outputs generated during the process are discarded. It is perfect for tasks like "go check the logs for anomalies" or "help me go through this large file". You only need the conclusion, not the process.

There is also the most important tip.

4. Switch tasks with /clear.

Run /clear right after fixing a bug, before starting the next task. The files, command outputs and intermediate explorations from the previous bug have nothing to do with the next task, but if you don't clear them, they will occupy space and consume tokens in every subsequent turn.

If you don't want to clear everything completely, /compact can compress the conversation into a summary. 10,000 to 20,000 tokens can be compressed to 1,000 to 3,000 tokens.