AI Programming · XiaoHu Explains

Anthropic Official Guide: How to Save Tokens When Talking to Claude Code

Why can a small fix turn into a long session? This guide shows where your usage goes and when to choose clear, compact, rewind, or a Subagent.

One-minute overview
  • Files, logs, and tool results stay in the session and travel with later requests. The earlier irrelevant content enters, the more turns it survives—and the more usage and distraction it creates.
  • Start with long sessions that span multiple tasks, then inspect irrelevant context, an oversized model or Effort setting, and finally prompt-cache invalidation.

Why did my usage quota drop so much after changing only a few lines?

You ask Claude Code to fix a failing test. The final change might be only three lines; but before finding those three lines, it has searched the repository, opened a batch of candidate files, ran hundreds of lines of test logs, and tried a few turns in the wrong direction.

None of that work disappears when Claude finds the answer. Each time you continue, the model must process the system prompt, project rules, files, command results, and conversation history accumulated so far.

This cost model differs from traditional development tools. Editors are often free or sold as monthly or annual subscriptions; fixing one more bug usually does not change the software bill. A coding agent runs model inference for every task. Regardless of how many lines ultimately change, the tokens it reads and generates consume compute on GPUs, TPUs, and similar hardware. The same task can therefore use very different amounts depending on how you approach it.

This creates three direct pain points:

  1. Usage drops quickly, but you cannot see where it went. Subscription users usually see only a changing usage allowance, making it hard to trace the cost to a particular file, log segment, or search.
  2. The longer the session, the harder old information is to shed. Caching can make repeated reads cheaper, but old content still occupies context and may pull Claude's attention back toward directions that no longer matter.
  3. The commands are familiar, but their timing is easy to get wrong. Use /clear for a new task; consider /compact only when the same task enters a new phase; use /rewind when the last few turns went off track. A Subagent can isolate noise, but it also creates another billable context.

Anthropic published this guide to answer those session-management questions. By the end, you should be able to tell whether usage is driven mainly by a long session, irrelevant context, an oversized model or Effort setting, or an invalidated prompt cache. You should also know when to provide files directly, trim logs, cut off history, or hand noisy work to a Subagent.

The original article uses the same failing test to draw two paths. Pointing directly to the test file, Claude reads the test and implementation, modifies and verifies, completing in five requests; just saying "tests fail," it needs to search the repo, open candidate files, read logs, and finally reach the same fix, using eighteen requests.

The same fix task, direct reading of the target file used 5 requests, while searching the repository first used 18 requests. Numbers come from the original article's illustration, describing only this specific scenario.

The 5 and 18 requests describe only the illustrated scenario; they do not imply a fixed cost multiplier. The more important point is that the same code change can accumulate very different amounts of context along the way. The goal is to spend tokens on necessary code, reasoning, and verification while cutting off irrelevant searches, noisy output, and leftovers from other tasks as early as possible.

The five-request path also explains how the bill forms. The first round submits the system prompt, CLAUDE.md, and the task; Claude requests to read the test file, the file result is appended to the session and sent again; then it reads the implementation file, submits the change, runs the test, and finally generates a short summary. Each round includes the previous complete session, but with normal appending, the old continuous prefix can use cache read, and only new tool calls, new files, or new test results need Prefill at normal input price.

A typical call may therefore contain tens of thousands of input tokens while generating only a few hundred output tokens. That does not mean every input token is recalculated at the normal rate: each turn combines cached reads of history, newly added content at the normal input rate, and the current output. This is why avoiding one pointless search or one mid-session model switch can matter more than shaving a few dozen words off the final reply.

Here are the six actions to take first. The rest of the guide explains why they work.

First, do these six things

If you don't want to study token mechanics yet, you can adjust your usage according to the six points below.

  1. Choose model and effort at the start. Use an adequate model for mechanical changes, and raise capability and work depth for fuzzy failures and architectural judgments. Try to avoid frequent switching in the middle of a long session.
  2. Hand over known scope directly to Claude. Provide target files, failing tests, expected results, and verification commands; where the interface supports it, use @filename references from the first time.
  3. Control command output. Run only relevant tests, use quiet reporters, error filtering, or tail; don't leave hundreds of lines of success logs in the next dozens of turns.
  4. Use /rewind when the last few turns went off track. It trims the wrong branch from the end of the session, and the preceding cache prefix may still be preserved.
  5. Use /clear before starting a new task. If you need to recover the old task later, first /rename, then clear the current context.
  6. Use Subagents only when the process is very noisy and the main session only needs conclusions. Scanning long logs, full test outputs, and Git history suits isolation; handing off small issues may be more expensive.