Claude Code Cost-Saving Guide: Token Billing Logic & Practical Tips for Cutting Costs

In traditional development, the cost of editor operations is virtually zero. But in the era of AI coding agents like Claude Code, every coding task quietly consumes an unknown number of tokens behind the scenes. For the same task, the token consumption between an experienced engineer and a novice can differ by several times or even tenfold — this isn't magic, but a direct reflection of how well one understands the underlying billing logic.

This article is based on an in-depth interpretation of the Claude Code official blog by AI agent expert Lao Wang on Bilibili, systematically outlining a methodology for reducing token costs in the agent era. The core takeaway can be summed up in one sentence: Blind searching executes numerous inefficient commands and reads dozens of irrelevant files, while precise context management can pinpoint targets directly — the difference in your bill can be an order of magnitude.

Model Selection & Output Control: The First Line of Defense for Your Bill

The single biggest factor determining your final bill is model selection. Taking the Claude series as an example: SOTA-level models (like Claude Opus) excel at complex architectural reasoning and handling ambiguous requirements, but come at a higher price; mid-tier models (like Claude Sonnet) are ideal for everyday tasks and workflow execution, offering the best cost-effectiveness. Dynamically matching different models to task difficulty is the first line of defense against runaway bills.

An even more critical insight is the price asymmetry between input and output. At the hardware level, a single request is divided into two phases: the first phase, Prefill (input), can be read in parallel with extremely high GPU throughput; the second phase, Decode (output), requires sequential token-by-token inference, occupying significantly more GPU time. Specifically, the Prefill phase can be processed in parallel because all input tokens can simultaneously compute the Self-Attention matrix when fed into the Transformer, fully utilizing the GPU's thousands of CUDA cores to achieve extremely high matrix multiplication throughput. The Decode phase, however, is constrained by the Autoregressive generation mechanism — each new token depends on the output of the previous token, forming a strict sequential dependency chain. The GPU spends most of its time waiting, and hardware utilization plummets to a fraction of the Prefill phase. Additionally, the Decode phase must maintain a KV Cache to store the intermediate states of already-generated tokens, continuously consuming memory bandwidth. It is precisely this hardware-level efficiency gap that directly results in output tokens costing roughly 5x the price of input tokens. Therefore, the key to cutting costs isn't saving on input — it's controlling output.

The core method for controlling output is regulating thinking depth. Claude's thinking mode (Extended Thinking) is essentially a Chain-of-Thought reasoning mechanism: when enabled, the model outputs an internal reasoning process before generating the final answer, and this reasoning text is also billed as output tokens. For complex architectural design or multi-step logical reasoning, deep thinking significantly improves answer quality; but for mechanical tasks like format conversion or simple renaming, the thinking process often just repeats the task description, generating a large volume of meaningless output tokens. Use the Effort command in daily conversations to adjust the thinking level (high / medium / low), and for simple tasks, consider turning off thinking mode entirely to eliminate unnecessary Decode premiums. The sensible approach is to set different reasoning intensities based on task type.

According to community testing, in complex conversations with uncleaned context, a single task investigation can consume up to 500,000 tokens — a 4-6x cost spike compared to clean, short sessions. Unconscious context dragging is the most hidden "assassin" in your bill.

Prompt Caching Mechanism Explained: Cache Hits and Cache Busting

Prompt Caching is the core of the entire cost-saving logic. The fundamental idea behind this technology borrows from caching principles in computer architecture: when a request's prompt prefix exactly matches that of a previous request, the server can directly reuse the previously computed KV Cache (the Key and Value tensors from each Transformer layer's attention mechanism), skipping the redundant Prefill computation. A cache hit read costs only 0.1x the base input price — essentially a 90% discount. Although the initial cache write costs 2x the normal input price (due to additional tagging and storage operations), the investment pays for itself from the second conversation turn onward — the more turns in a session, the lower the average per-turn token cost.

Consider a five-turn bug fix as an example: the first request writes system instructions and configurations into the cache; in the second turn, when reading test files, all prior history is read at the 90%-off rate; then comes code location, editing, and verification. Throughout the entire lifecycle, the vast majority of tokens are settled at 0.1x the normal price.

The "Train Assembly" Principle of Caching

Prompt caching can be understood as a train assembled in a fixed order: the front cars are Tool Definitions, followed by System Prompt, then configuration files, and finally conversation history. The cache uses a strict Prefix Matching strategy — only continuous matching starting from the very first token is valid. If even a single character in the frontmost car changes, every car in the entire train must be remounted, resulting in a full re-billing — this is "cache busting."

The concept of Cache Busting originates from web caching and CDN domains. In the LLM API context, it specifically refers to situations where a change in the request prefix causes the existing cache to be completely invalidated, requiring full recomputation. In Claude Code's actual request structure, a complete request is assembled from multiple hierarchical layers: the outermost layer is tool definitions, followed by the system prompt, then CLAUDE.md and other configuration content, and finally the multi-turn conversation history. Any minor change in an upstream layer — such as enabling or disabling a tool that alters the tool definition list — will invalidate all downstream content's cache. Therefore, content positioned in the request prefix should be kept as stable as possible.

The two most dangerous operations during an ongoing session are: switching models mid-conversation and enabling Fast Mode mid-conversation. Each model maintains an independent cache space. Switching models mid-conversation is devastating because different models have entirely different tool definition formats and system prompts, which effectively rewrites the prefix entirely, causing dozens of turns of history to be fully recomputed at the new model's pricing. Enabling Fast Mode similarly breaks the cache key and triggers a full-price recalculation.

Use Rewind Instead of Compact to Protect Cache

When exploration goes down the wrong path, never blindly use the Compact command — it rewrites history and completely destroys the prefix cache. The correct approach is to use the Rewind command, which only truncates invalid trailing turns, perfectly preserving all previous cache at zero additional recomputation cost.

Cache Warming & Practical Slimming Techniques

Cache is like freshly boiled water — leave it alone and it goes cold. This involves the server's resource management strategy: LLM KV Cache is stored in GPU memory (VRAM), the most expensive and scarce resource. Service providers must balance cache reuse rates against VRAM consumption, which is the rationale behind the TTL (Time To Live) mechanism. Subscription plans can keep the cache "warm" for one hour, because user behavior under subscription models is more predictable with relatively regular request intervals; API call mode, however, defaults to going cold after just five minutes, accommodating bursty, low-frequency call patterns. When the cache expires, the next request must perform a complete Prefill calculation and rewrite the cache, incurring 2x write costs. It's recommended to extend the warm-up duration via environment variables; if you haven't used it for a long time, performing a session compression summary offers the best cost-effectiveness.

Use @ Syntax and Silent Output to Reduce Token Consumption

At the tool invocation level, the same requirement can have vastly different costs: saying "tests are failing" causes the model to blindly search files, generating tens of thousands of wasted tokens; saying "fix this file" requires an additional read call; but using the @ file syntax attaches file content directly to the request with the message, completely eliminating tool invocation rounds.

Terminal command output is another hidden killer. Output exceeding 30,000 characters is automatically dumped to a file, but hundreds of lines of passing test logs will permanently pollute every subsequent conversation turn. This involves the "compound interest effect" of context bloat — in multi-turn conversations, the Nth turn's request must send all N-1 previous turns' messages as input to the model. Assuming each turn adds K tokens, the input volume at turn N is approximately N×K, and the cumulative input token total across the entire session is approximately N²×K/2 — a quadratic function of the number of turns N. A 40-turn session doesn't cost 2x a 20-turn session — it costs 4x. Preset silent parameters in configuration files and use dot-style reports instead of verbose logs — a single line of code can solve the context pollution problem.

Additionally, many people don't realize that as soon as a session opens, it's already carrying the "background noise" of dozens of files — system prompts, global rules, unused tools — all billed in full every single turn. Three things to do at the start: use CLAUDE.md to break long rules into Skills that are called on demand, turn off idle tools, and eliminate the fixed shared costs billed every turn from the very source.

Short Session Lifecycle & Subagent Isolation Strategy

Editing costs in long sessions grow geometrically. The 40th turn of a conversation essentially re-reads the entire content of the previous 39 turns. Combined with the quadratic growth model of context bloat, it's easy to understand why a single long session's cumulative cost is 4x or more that of multiple short sessions. You must execute clear when switching tasks to start a fresh, clean session.

For high-noise "dirty work," delegate it to a Subagent. A Subagent is a task delegation mechanism in Claude Code, with its design inspired by the process isolation model in operating systems. The main session can dispatch specific tasks to a Subagent, which runs in a completely independent context space — with its own conversation history, tool permissions, and token budget. This isolation brings two key advantages: First, the large volume of intermediate information generated during the Subagent's processing (such as compilation error logs, test outputs, file search results) does not flow back into the main session's context, preventing context bloat in the main session. Second, the Subagent returns only a structured summary upon completion, allowing the main session to continue based on that summary — achieving "funnel-style filtering" of information. From a cost perspective, while the total token count may be the same, keeping the main session lean means that the Prefill cost of every subsequent conversation turn is significantly reduced, and the cumulative savings over time are substantial.

Summary: Four Priorities for Token Cost Reduction

Overall, token cost reduction can be distilled into four priorities:

1. Model Selection & Thinking Budget — Match models to task difficulty, turn off thinking mode for simple tasks, and avoid meaningless Decode premiums.
2. Prevent Cache Busting & Maintain Prefix Stability — Don't switch models mid-session, don't casually enable Fast Mode, use Rewind instead of Compact, and understand the strictness of prefix matching.
3. File Slimming & Silent Output — Leverage @ syntax, silent logging, rule splitting, and disabling idle tools to curb quadratic context growth at the source.
4. Short Session Lifecycle & Subagent Isolation — Use clear frequently, delegate dirty work to subagents, and apply process isolation thinking to protect the main session's leanness.

Cost competition in the agent era is fundamentally a competition of understanding the underlying billing logic. Only by understanding that the Prefill/Decode price gap stems from GPU parallel vs. sequential hardware constraints, that the cache "train assembly" principle is based on strict prefix matching, and that context bloat follows a quadratic-growth compound interest effect, can you ensure that every single token generates real value.