In the billing logic of the Claude API, multi-turn conversations are an easily underestimated cost black hole. Each new API request requires resending the entire conversation history. As the number of conversation turns increases, the input tokens grow linearly, and the billing spirals out of control. According to actual test data, in multi-turn agent scenarios, tool results (file content, command output) account for about 85% of token consumption, while the user's actual questions and AI responses combined account for less than 10%. This "context-heavy, response-light" conversation structure makes context management the core battleground for controlling Claude API token costs.

　　This article will break down four core strategies, from Prompt Caching to context compression, to help you systematically control the multi-turn conversation token costs of the Claude API.

　　I. Prompt Caching: Reusing Stable Prefixes at 10% of the Price

　　Prompt Caching is the first line of defense in controlling multi-turn conversation costs. The logic is as follows: In multi-turn conversations, large, stable blocks of content, such as the System Prompt, tool definitions, and project descriptions, are repeatedly sent. With caching enabled, the hit price for this content is only 10% of the base input price, a discount of up to 90%.

　　Practical Operation: Add a `cache_control` breakpoint.

　　When calling the Claude API, simply add the `cache_control` flag to the stable content block to enable caching.

　　Correct syntax (System Prompt must be in array format):

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=2048,
    system=[
        {"type": "text", "text": "You are a professional code review assistant..."},
        {"type": "text", "text": LONG_SYSTEM_PROMPT},
        {"type": "text", "text": "# Project Specifications\n- use TypeScript\n- Follow ESLint rules...", "cache_control": {"type": "ephemeral"}}
    ],
    messages=[{"role": "user", "content": user_query}]
)

　　Three common pitfalls:

　　1. Inserting changing content into the cache prefix: e.g., Current time: 2026-08-27T14:32:15Z. This changes with every request, causing the cache to become completely invalid. The date should be truncated to the day or placed after the cache breakpoint.

　　2. Writing user ID and session ID into the System Prompt: Each user has a different cache miss, which actually increases the cost.

　　3. Not triggering caching if the content is not long enough: Different models have minimum token thresholds—Opus 4.7 requires 4096 tokens, and Sonnet 4.6 requires 2048 tokens.

　　The economics of caching

　　A 5-minute cache write costs 1.25 times the base price, but it breaks even after one reuse; a 1-hour cache write costs twice the base price and is only cost-effective after at least two reuses.

　　Verifying Cache Effectiveness

　　Check the usage field in the API response:

　　`cache_creation_input_tokens > 0`: Indicates the current request wrote to the cache (first request).

　　`cache_read_input_tokens > 0`: Indicates the current cache hit (a key indicator for saving money).

　　Both are 0: The cache is not effective; check if `cache_control` is placed correctly.

　　II. Context Compaction: Slimming Down Long Conversations

　　The longer the multi-turn conversation, the more tokens historical messages consume. Compaction is an API-level solution provided by Anthropic. When the context is close to the window limit, it automatically summarizes earlier messages into a shorter digest, replacing the original complete conversation history.

　　Official Compact API Enabling Method

response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-opus-5",
    max_tokens=4096,
    messages=messages,
    context_management={"edits": [{"type": "compact_20260112"}]}
)

　　Once the API receives the compressed block, all previous content blocks are ignored, and the conversation continues from the compressed summary.

　　Important Insight: Compaction itself requires an additional sampling step, factored into rate limits and billing. However, it significantly reduces the Input Tokens for subsequent rounds of requests, making it a one-time investment with long-term cost savings.

　　Manual Cleanup: Truncating at the Conversation Level

　　If you don't want to use API compression, you can manually clean up at the conversation level:

　　`/clear`: Clears the current session and starts a new one (suitable for scenarios where the task is already completed).

　　`/rewind`: Rewinds to a point in the conversation history, discarding subsequent invalid exploration paths and preventing "intermediate processes from failed attempts" from continuously polluting the context.

　　This is especially important in multi-round Agent scenarios: After each failed exploration, instead of continuing to correct errors, it's better to rewind to the point before the attempt and reissue instructions, retaining valuable file reads and discarding failed attempts.

　　III. Model-Level Routing: Let the "right people" do the "right work."

　　Claude's pricing varies significantly across different models:

　　Using Opus for miscellaneous tasks is 5 times more expensive than using Haiku. A more reasonable approach is to choose the model based on task complexity:

　　Haiku: Data annotation, batch classification, format conversion, summary generation (cost-sensitive tasks)

　　Sonnet: Routine coding, documentation, API integration (80% of the work)

　　Opus: Complex inference, architecture design, deep debugging (only 10% of heavy tasks)

　　Route 80-90% of traffic to Haiku; this is the most cost-effective single decision.

　　IV. Batch API: Half-price for non-real-time tasks

　　For batch tasks that don't require immediate results, Claude's Message Batches API offers a fixed 50% discount, covering both input and output tokens, without changing the model or quality.

　　Suitable scenarios for Batch API: overnight data annotation, evaluation pipelines, batch summary generation, classification/extraction of existing data

　　Most batch processing is completed within one hour, with a maximum backup of 24 hours. This is a free way to save money—the only cost is that you're willing to wait.

　　V. FAQs

　　Q1: Where are tokens spent the most in multi-turn conversations?

　　A1: Tool results (file content, command output, search results). In multi-turn Agent scenarios, tool results account for about 85% of total Input Tokens, while user questions and AI responses combined account for less than 10%. Many tool results become outdated after a few rounds (e.g., reading old versions of files, executing failed attempts), but are still repeatedly sent, continuously wasting costs.

　　Q2: What is the minimum number of tokens required for a "stable prefix" in Prompt Caching?

　　A2: The threshold varies depending on the model. Opus 4.7 / Haiku 4.5 requires 4096 tokens, and Sonnet 4.6 requires 2048 tokens. If the content is not long enough, caching will not take effect, and `cache_read_input_tokens` will show as 0.

　　Q3: What is the difference between `Compaction` and `/clear`?

　　A3: `Compaction` is compression that preserves the summary; the model still knows what was discussed before, just compressed in length. `/clear` clears the entire history, starting a new session from scratch. The former is suitable for the later stages of long conversations, while the latter is suitable for task switching or completely restarting.

　　Q4: How do I estimate the number of Input Tokens for a request?

　　A4: Use Claude's official `count_tokens` endpoint. Do not use tiktoken (OpenAI's tokenizer), as it underestimates Claude's input by about 15-20%, leading to completely inaccurate estimates based on it.

　　In summary, controlling the token cost of multi-turn conversations in the Claude API is essentially a collaboration between "context simplification" and "cost awareness." The core actions are only four: reuse stable content at 10% cost using Prompt Caching, compress long conversation histories using Compaction, select models based on task complexity, and halve the cost of non-real-time tasks using the Batch API. Remember: the real value in multi-turn conversations isn't the answer itself, but the historical records and file content you cram into the context—manage them well, and the cost will naturally decrease.