Just now (15th), Anthropic posted a blog.
The core message is: Everyone, stop burning tokens for nothing, we can't stand it anymore!

To this end, the official blog listed six money-saving tips in detail. Here they are:
1. /clear after a task is done. Clear the current conversation after fixing a bug. Don't drag the files read and command outputs from the previous task into the next one, uselessly occupying context.
2. Set the model and reasoning effort level from the start. If you switch mid-session, all accumulated prompt caches become invalid, and the entire conversation history needs to be recalculated at full price.
3. Use @ to reference files, don't type 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 just type the filename, Claude might search around first and then open several files to test. All these operations go into the conversation history and get carried along in every subsequent turn.
4. Add quiet flags to commands with verbose output. Write a configuration like --reporter=dot in CLAUDE.md, so test output prints only a few lines of summary, not hundreds of lines of detail. Shorter output uses less context.
5. Do /compact before a break. Compress the conversation while it's still cached; the cost is only one-tenth of the normal price. If you wait until you come back and the cache has expired, you have to pay full price to reread everything before compressing.
6. Offload large-output tasks to subagents. A subagent runs in its own independent context window. It only passes back the conclusion when done; the files read and command outputs generated during the process don't enter your main conversation.

The Life and Times of a Token
Working with Claude Code, the API is pay-as-you-go, and the subscription monthly fees range from $20 to $200 across three tiers.
According to official estimates, developers consume an average of $13 worth of tokens per day, spending between $150 and $250 per month.
And this is just the average. Fixing the same bug with different phrasing can cost several times more.
Moreover, each turn of conversation re-sends all the content from all previous turns. The longer the session, the more expensive each turn becomes.
To understand where this money goes, we need to start with the pricing logic of tokens.

Each time you input a command in Claude Code, two things happen behind the scenes.
The first is prefill, where the model reads your entire request at once, including the system prompt, CLAUDE.md, your message, and everything accumulated in the previous conversation. These are input tokens.
The second is decoding, where the model writes out its response word by word, including its reasoning, tool calls, and the text you finally see. These are output tokens.
The key difference lies here.
Prefill is parallel, processing all input tokens through the GPU at once. Decoding is serial, requiring the model to run once for each token it generates. A 200-token reply means 200 independent computations.
So, it's not hard to understand why output tokens are 5 times more expensive than input tokens.

On this basis, the final bill depends on two things.
First is the model, which determines the price per token.
Opus 5: $5 per million input tokens, $25 output.
Sonnet 5: $2 input, $10 output.
Haiku 4.5: $1 input, $5 output.
Second is the reasoning effort level, which determines the number of tokens.
Most output tokens in a session are reasoning tokens, and the effort level controls this amount. Higher reasoning effort means the model thinks longer, producing more reasoning tokens. The difference between 'max' and 'low' can be severalfold.
Use Sonnet for simple daily tasks, only bring out Opus for the hard nuts. Using a sledgehammer to crack a nut is the most wasteful spending.

Prompt Caching: The Biggest Money-Saver
There's another huge variable in token pricing: caching.
Each request in Claude Code starts with the same prefix: the system prompt, tool definitions, CLAUDE.md, and conversation history.
If the prefix of this request is byte-for-byte identical to the last one, the server doesn't recompute it; it directly loads the previous computation result.
Reading from the cache costs only 0.1 times the normal input price, saving 90% directly.
Writing to the cache is more expensive, up to 2 times. But writing only happens once; every subsequent turn enjoys the 0.1x read cost.
For example.
Assume your conversation history is 50,000 tokens. Without caching, you'd pay full price just to re-read these 50k tokens every turn. But as long as the cache hits, the same 50k tokens only cost one-tenth.
A session running 20-30 turns, the discounts accumulated from cache hits are astronomical.
This is your biggest leverage for getting the most bang for your buck.

But caching has a fatal weakness. It must match continuously from the first byte of the request; if anything changes in the middle, everything from that point onward is invalidated.
Specifically, there are six scenarios:
1. /model switch: Caches are independent per model. Switching from Sonnet to Opus means the entire conversation history is prefilled at Opus prices, with no discount.
2. /effort switch: Reasoning effort level is also part of the cache key. Switching means the entire history must be recalculated.
3. Toggling Fast mode: Same effect as the first two; cache is invalidated.
4. /compact compression: The conversation is rewritten into a summary; the original content no longer matches, so the old cache is invalidated.
5. Time expiration: Cache stays alive for 1 hour for subscribers, 5 minutes by default for API users. After timeout, the next turn is a full recomputation.
6. Resuming old sessions: If it's been too long, the cache is long gone, almost guaranteeing a full-price recomputation.
The bad news is, hitting any one of these means the entire conversation history goes from 0.1x back to full price.
The good news is, once you know what invalidates the cache, you know how to preserve it.
For example, lock in the model and reasoning effort at the start of the session and don't switch. Don't run /compact while the cache is hot; do it when you're about to take a break.
There's also a hidden trap here.
The opusplan mode switches models every time you enter or exit the plan. Enter once, cache invalidated. Exit, invalidated again. Jumping back and forth means a full-price prefill for each jump.
Your Session Is Secretly Getting Fatter
Caching helps reduce the cost of re-sending history to one-tenth.
But there's one thing it can't 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. From that turn onward, everything is carried along.
The 40th turn of conversation is re-sending all the accumulated content from turns 1 through 39.
This growth is near-quadratic, O(n²).

Claude Code has a safety net mechanism.
If command output exceeds 30,000 characters, it doesn't get stuffed into the conversation. Instead, it's written to a temporary file, and only a summary sentence is placed in the conversation. But outputs under 30,000 are left untouched.
For example, a test framework finishes running, printing 400 lines of pass records, each line dozens of characters. The total is less than 30k, not hitting the threshold.
So these 400 lines remain intact in the conversation history, being re-sent with every subsequent turn.
The Anthropic blog offers several practical methods for slimming down.
1. Use @ to reference files.
Don't manually type paths and let Claude find them itself. @ referencing attaches the file directly to the message, saving a read operation.
If you just mention the filename, Claude might grep around first, opening several files to see which one is correct. All these probes then enter the conversation history, adding unnecessary cost.

2. Add quiet flags to noisy commands.
Write a line like "run tests with npx vitest run --reporter=dot" in CLAUDE.md. From then on, each test run will output only a few lines of dots, not hundreds of lines of detail. A one-minute configuration saves hundreds of lines of context for every future session.
3. Isolate large-output tasks with subagents.
A subagent runs in its own independent context window, passing back only the answer when done. Files read and command outputs generated during the process are all discarded. Suitable for tasks like "go check the logs for anomalies" or "help me go through this large file." You only want the conclusion, not the process.

And the most important one.
4. /clear between tasks.
/clear after fixing a bug before starting the next thing. The files, command outputs, and intermediate explorations from the previous bug are all irrelevant to the next task. But if not cleared, they occupy space and consume tokens in every subsequent turn.
If you don't want to clear completely, /compact can compress the conversation into a summary. Ten to twenty thousand tokens can be compressed to one to three thousand.

Additionally, the blog mentions a lesser-known but free operation: /rewind.
If the last few turns go off track, /rewind directly cuts them off, leaving the previous cache completely untouched.
Managing Tokens Is Also a Developer Skill
Breaking down all these operations, you'll notice a pattern. Coders are developing a new set of skills.
Unrelated to frameworks or languages, it's knowing which model to choose, how to manage context, how to preserve cache, and what reasoning effort level is appropriate.
These abilities didn't exist a year ago. But now they determine whether you spend $3 or $30 on the same task.
Anthropic itself is the best example.
They write 80% of their code with AI, their code merge volume increased 8x in a year, and benchmark test speeds accelerated 52x. Using AI at this intensity, if no one managed tokens, the inference costs alone could blow the budget.
From this perspective, rather than saying this blog is about money-saving tips, it's more about a new instinct developers need in the AI era —
Knowing what each of your operations consumes, and knowing how to get more work done with the same budget.
Those who understand this aren't just saving a few dollars on tokens.
References:
https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions
This article is from WeChat public account "Xinzhiyuan", author: Moxi






