Claude Token Optimization: The Four-Lever Framework

Claude token optimization is not about squeezing characters. It is about deciding, at every step of an agentic workflow, which information earns its place in the context window and which does not. Get that decision wrong and you pay twice: once in API cost, and again in degraded model attention. This post gives you a concrete four-lever framework, production patterns, and the measurement approach to verify that your changes actually work.

Why does token optimization matter more than ever?

Claude's context windows are large. Claude 3.5 Sonnet and Claude 3.7 Sonnet both support up to 200,000 tokens per request. That scale tempts engineers to treat the window as unlimited RAM and simply dump everything in. The problem is that attention is not uniform across a long context. Research on the "lost-in-the-middle" effect shows that retrieval accuracy degrades for content placed in the middle of very long prompts, even when the model technically "sees" the tokens.

There is also a cost dimension. At production scale, every unnecessary token in every request compounds. A 50,000-token system prompt sent with 1,000 requests per day is 50 million tokens of overhead daily, before a single user query is processed.

The CCAR-F exam (Domain 5: Context Management and Reliability, weighted at 15%) tests whether architects can diagnose and fix exactly these failure modes. Our Context Management and Reliability concept library maps 174 atomic concepts to the five exam domains, and context efficiency runs through a significant portion of them.

What are the four levers of claude token optimization?

The framework reduces to four verbs: write, select, compress, and isolate. Each targets a different source of token waste.

We will work through each lever in turn.

How do you write leaner system prompts?

The system prompt is the most expensive token real estate in any Claude deployment because it is sent with every request. Treat it like a database schema: document every field, justify its presence, and delete anything that does not change model behaviour.

Practical rules:

1. State the agent's role and constraints in one paragraph, not five.
2. Use structured sections (XML tags or clear headings) so Claude can locate relevant instructions without scanning the whole prompt.
3. Move stable reference material (API schemas, long policy documents) out of the system prompt and into tool-retrievable resources or MCP resource endpoints.
4. Audit for contradiction. Conflicting instructions force the model to resolve ambiguity at inference time, which wastes attention and produces inconsistent outputs. Our concept on system prompt and description conflicts covers the diagnostic pattern.

For teams using Claude Code, the CLAUDE.md file plays the same role as a system prompt for session-level context. Treat it as essential infrastructure: version-control it, review it on every sprint, and keep it under 2,000 tokens wherever possible.

How do you select only the tokens that matter?

Selection is the lever that operates at request-construction time. Three sub-problems dominate here.

Tool overload. When you register every available tool with every agent, the model must parse all tool descriptions on every turn. A 30-tool catalog with verbose descriptions can consume 4,000 to 8,000 tokens before the user message even appears. The fix is scoped tool distribution: give each agent only the tools it will plausibly call. The tool overload problem concept explains the selection heuristics in detail.

Few-shot example selection. Few-shot examples are high-leverage but expensive. A single detailed example can run 500 to 1,500 tokens. Statically including five examples in every prompt regardless of the query type is wasteful. The better pattern is dynamic selection: embed your example library, retrieve the two or three most semantically similar examples at request time, and inject only those.

History truncation strategy. Naive history accumulation is the most common source of context bloat in production agents. A session that runs 20 turns with tool calls can accumulate 40,000 to 80,000 tokens of history. The options are:

• Rolling window: keep the last N turns verbatim.
• Selective retention: keep turns that contain tool results or user corrections; summarise or drop the rest.
• Summary injection: periodically compact old turns into a structured summary block and start a fresh context with that summary prepended.

The summary injection for fresh sessions concept covers the implementation pattern for the third option, which is the most token-efficient for long-running sessions.

How do you compress what must stay in context?

Some content cannot be excluded, but it can be represented more efficiently.

Prompt caching for stable prefixes. Anthropic's prompt caching feature allows you to cache the KV state of a stable prefix (system prompt plus any static context) across requests. Cached tokens are billed at a lower rate than input tokens. For agents with a large, stable system prompt, this is the single highest-leverage cost reduction available without changing prompt content at all.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a senior code reviewer. [... 2000 tokens of stable instructions ...]",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": "Review this pull request: [diff here]"}
    ]
)

The cache_control block marks the prefix for caching. Subsequent requests that share the same prefix hit the cache and pay the reduced cached-token rate. Per Anthropic's documentation on prompt caching, the cache has a five-minute TTL by default, extendable to one hour.

Tool result trimming. Tool results are often verbose by default. A database query might return 200 rows when the agent needs 10. A web scrape might return full HTML when only the body text matters. Intercept tool results before they enter the context and trim them to the information the next reasoning step actually requires. The PostToolUse hooks for data normalisation pattern gives you a clean interception point for this.

Structured context passing between agents. In multi-agent systems, passing full conversation history between agents is a common mistake. Instead, pass a structured summary of the facts the downstream agent needs. This is the principle behind structured context passing: the coordinator extracts the relevant state and hands it off as a typed object, not a transcript.

How do you isolate contexts to prevent cross-contamination?

Isolation is the lever that matters most in parallel agentic workflows. When multiple subagents share a context or a session, their tool calls, intermediate results, and error states can bleed into each other's reasoning. The result is attribution loss, where the synthesising agent cannot tell which subagent produced which finding.

The two main isolation patterns are:

1. Subagent context isolation. Each subagent receives only the context slice relevant to its subtask. The coordinator holds the full state; subagents see only what they need. See subagent context isolation for the implementation details.

2. Session forking for divergent exploration. When you need to explore multiple solution paths from a common starting point, fork the session rather than branching within a single context. Each fork carries the shared prefix but accumulates its own history independently. The fork session for divergent exploration concept covers when this is preferable to spawning fresh sessions.

For Claude Code workflows running multiple agents in parallel, git worktrees provide filesystem-level isolation that complements context isolation: each agent operates on its own branch and working directory, so file-system state cannot contaminate another agent's context.

What does a production-ready token optimization stack look like?

Putting the four levers together, a production Claude agent architecture for token efficiency looks like this:

The key insight is that each lever operates at a different stage of the request lifecycle. You cannot substitute one for another: caching a bloated prompt is cheaper than not caching it, but it is still more expensive than caching a lean one.

How do you measure whether your optimizations are working?

Optimization without measurement is guesswork. The measurement framework has four levels:

The last row is critical. Token optimization that degrades task quality is not optimization; it is degradation. Always run quality checks alongside cost checks. A/B test your compression changes against a held-out set of representative sessions before rolling them out to production.

For CCAR-F candidates, Domain 4 (Prompt Engineering and Structured Output, 20%) and Domain 5 (Context Management and Reliability, 15%) together account for 35% of the exam. Scenario items in these domains frequently present a system that is producing inconsistent outputs or running over budget, and ask you to identify the root cause and the proportionate fix. The four-lever framework gives you a systematic diagnostic approach: identify which lever is misconfigured, apply the minimum change that addresses the root cause, and verify with measurement.

Our Prompt Engineering and Structured Output concept library covers the structured output side of Domain 4 in depth, and the Attention Dilution Problem concept explains the mechanism behind why long, unfocused contexts produce unreliable outputs.

Where should you start if you are optimizing an existing system?

Start with measurement, not with changes. Instrument your current system to capture input token counts per request and per session. Identify the three largest contributors to token volume. In most production systems, the ranking is:

1. History accumulation (often 60 to 70% of total input tokens in long sessions)
2. Tool catalog size (often 10 to 20%)
3. System prompt verbosity (often 10 to 15%)

Address them in that order. History compression gives the largest return per engineering hour. Tool scoping is the next highest leverage. System prompt trimming is important but rarely the dominant cost driver.

If your system uses Claude Code, audit your CLAUDE.md files using the three-level configuration hierarchy to understand which instructions are project-wide, directory-scoped, and personal, and eliminate any duplication across levels.

AI Skill Certs is an independent prep platform, not affiliated with Anthropic. Our concept library at /concepts maps 174 atomic concepts to the five CCAR-F domains and 30 task statements, with context management and token efficiency covered across Domains 4 and 5. If you want to test your understanding under exam conditions, our practice exams mirror the real 60-question, 120-minute format and score on the same 100-to-1000 scale with a 720 passing bar.