How to Maximize the Value of Claude Code Sessions

Claude Code Token Pricing Logic

Both API and subscription usage of Claude Code are billed by token usage. Users actually purchase inference time: the GPU time required to run the model over each token. A token's time cost depends on three factors: which model is used, whether the token is input or output, and whether the request hits the prompt cache.

The model factor is straightforward: larger models consume more GPU resources. Anthropic recommends using the strongest model (Opus 5/Fable 5) for difficult or ambiguous problems, and smaller or default models (Sonnet 5/Haiku 4.5) for routine tasks.

Input and output tokens are priced differently because a request has two GPU phases. The first phase, prefill , reads the entire prompt—including system prompt, CLAUDE.md, and all prior conversation—treating them as input tokens. The second phase, decode , generates output tokens one by one. Since decoding runs the model repeatedly for each token, output tokens cost roughly five times more than input tokens. This distinction was previously detailed in the author’s token‑technology article.

Output tokens also include “thinking tokens” whose amount is controlled by the /effort setting. The chosen model and effort level become part of the cache key, so changing them in an ongoing session forces a full prefill.

The third factor is prompt caching (KV cache). If the beginning of a request matches a previously seen request exactly, the server reuses the cached state for the matching prefix. Reading from the cache costs only 0.1× the normal input price; writing to the cache can be up to 2× more expensive but occurs only once per request.

Typical Task Flow Example

When the user asks to fix a failing test in utils.test.ts, Claude Code proceeds through the following steps:

Send the system prompt, CLAUDE.md, and the user request as the first request. No cache exists, so the whole prompt is prefixed at full price and written to the cache.

The model, not having seen the test file, issues a Read tool call (output tokens). The file content is appended to the conversation, and the entire conversation is resent. The first request’s content is now read from the cache at 0.1× price; only the new Read call and file content are charged at full input price.

The model reads the target file, issues another Read, and the new content is again appended and resent. The first two rounds use the cache; the second file is charged at full price.

The model returns an Edit result, which is applied and appended. New content is charged at full price; cached parts remain cheap.

The model runs npm test, appends the test output, and resends. Only the new test output incurs full input cost.

When the test passes, the model provides a short summary. No further tool calls mean no additional request is sent, and the session ends.

In this five‑request workflow, each round sends the entire conversation, but only the newly added parts are charged at the full input price; the historical context is read from the cache at 0.1×.

Operations That Break the Cache

The cache requires an exact match from the first token of a request. Any change to the fixed prefix (tool definitions, system prompt, or the start of the conversation) forces a full prefill for the remainder of the session. The following actions break the cache: /model: Switching models (including entering or exiting plan mode) creates a new cache, causing the whole conversation to be prefixed at full price. /effort: Changing the effort level also changes the cache key, triggering a full prefill. Fast mode: Enabling fast mode adds to the cache key; the subsequent prefill is billed at the fast‑mode rate. It should be enabled at the start of a session. /compact: Replacing the conversation with a shorter version invalidates the previous cache because the new content no longer matches the old prefix. Writing a compacted version incurs a one‑time write cost, then cheap reads.

Time expiration: Cached entries expire after one hour (subscription) or five minutes (API key) unless extended (e.g., ENABLE_PROMPT_CACHING_1H=1). After expiration, the next round must prefill the entire conversation again.

Additionally, using /rewind to backtrack avoids extra cache writes, whereas /compact rewrites the whole conversation and adds token cost.

Three Variables Determining Session Cost

Every token that enters the context persists for the remaining rounds of the session. The cost model therefore depends on:

How many tokens are added to the context.

How many rounds those tokens remain in the context.

How many parallel contexts (e.g., subagents) are active.

Initial context includes tool definitions, system prompt, and CLAUDE.md. Running /context at the start of a new session reveals the size of this baseline load. Unused tools (e.g., an idle MCP server) can consume tens of thousands of tokens and should be cleared when not needed.

Reducing Token Waste

Most token waste comes from:

Long sessions that repeatedly resend the entire history.

Loading unnecessary files, verbose command output, or leftover task context.

Over‑provisioning model or effort settings, which multiply all costs.

Breaking the prompt cache by switching models, effort, fast mode, or by session timeout.

Practical tips include:

Specify files directly with @filename so Claude Code attaches them to the first request, avoiding extra Read calls.

For frequently used commands, embed them in CLAUDE.md with quiet flags (e.g., npx vitest run <file> --reporter=dot or pytest -q --tb=line) to eliminate repeated reads.

Prefer short sessions over long ones; split work into separate sessions to avoid the quadratic cost of re‑reading history.

When a task deviates, use /rewind instead of /compact to trim the tail without extra cache writes.

Leverage Subagent contexts that have their own window and tools but discard their history after returning a result, keeping the main session lean.

The Four Most Token‑Intensive Areas

According to the original blog’s priority diagram, the biggest token drains are:

Long sessions where each round resends the full history.

Overloaded context with unused files, large command outputs, leftover task data, or idle MCP servers.

Using oversized models or high effort levels, which multiply all token costs across the session.

Breaking the prompt cache by switching models/effort, enabling fast mode mid‑session, or letting the cache expire.

Reading the full Anthropic blog provides additional nuances, but the key takeaways are captured above.