The context engineering playbook: which lever, in what order, and what each is worth

Four posts covered the mechanics one at a time: clear stale results, summarize the whole conversation, never load definitions you will not call, and convert any of it into money. This is the part where they become one system — which lever answers which symptom, what order to deploy them in so they do not fight each other, and the single request that has all of them switched on. Along the way, a fifth lever the series missed, and a correction to the cost function from the last post.

The five levers on one page

Two of those need explaining, because they did not appear anywhere in the first four posts.

The lever this series missed

clear_thinking_20251015 is the second strategy inside context editing, and it exists because of a change in how models retain reasoning.

The post on token-versus-dollar conversion noted that thinking is billed as output. The other half of the story is what happens to it afterwards, and it depends on the model generation:

On a keep-all model, every thinking block you paid for as output comes back as input on every subsequent turn, for the rest of the conversation. A high-effort agent doing a forty-step tool loop is carrying forty turns of reasoning in its window and paying rent on it.

The strategy lets you cap that:

{
    "type": "clear_thinking_20251015",
    "keep": {"type": "thinking_turns", "value": 2},
}

And the cache rule here is unusually clean, quoted from the docs:

“When thinking blocks are kept in context (not cleared), the prompt cache is preserved, enabling cache hits and reducing input token costs. When thinking blocks are cleared, the cache is invalidated at the point where clearing occurs.”

So this is a genuine either/or, not a free win. Keeping thinking is the cache-friendly default and costs you input tokens at the cached rate. Clearing it frees the window and costs you a cache write. Which one wins depends on how long your conversations run and how much of your bill is already cache reads — which you will only know if you measured the mix first.

Anthropic’s own ordering is not the obvious one

Here is a sentence from the context-editing docs that reframes the whole series:

“For most use cases, server-side compaction is the primary strategy for managing context in long-running conversations. The strategies on this page are useful for specific scenarios where you need more fine-grained control over what content is cleared.”

Compaction is the default recommendation. Clearing is the specialist tool. That is the reverse of how this topic usually gets written up, including in the order these posts were published — clearing came first because it is easier to explain, not because it is the first thing you should reach for.

It also makes sense once you consider operational cost rather than token cost. Compaction is server-side and needs no client bookkeeping: you set a trigger and the API handles summarization. Clearing needs you to reason about which tool results are safe to drop, how many to keep, and how often the clear will invalidate your cache. That is real engineering time attached to a lever that, as the previous post showed, usually converts poorly into dollars.

Deployment order: cache-safe first

The ordering principle is simple. Some levers leave your prompt cache alone and some do not. Deploy the harmless ones first, measure, and only then reach for the ones that reprice your tokens.

Stage 0 — instrument dollars. Before touching anything, log cost per request by token class, not token counts. Everything below is a hypothesis you cannot evaluate otherwise. The previous post has the function; the patch it needs is further down this page.

Stage 1 — tool search. GA, one boolean per tool definition, preserves the prefix, and gets more accurate as your catalog grows. If you aggregate MCP servers, this is the highest-value first move by a wide margin, and it is the only lever in the set with no cache penalty at all.

Stage 2 — decide a thinking policy. Not necessarily to clear. On a keep-all model with long tool loops, look at how much of your input is accumulated reasoning, then choose: keep everything and stay cache-friendly, or cap at two or three turns and eat the invalidation. Deciding explicitly beats inheriting a default that changed between model generations.

Stage 3 — compaction. The vendor’s primary recommendation, and the right answer when the conversation itself is the thing that grows. Put a cache_control breakpoint at the end of your system prompt first — the docs are specific that this keeps the system prompt cached separately, so when compaction fires “the system prompt cache remains valid and is read from cache” and only the summary is written as a new entry.

Stage 4 — tool-result clearing. Now, and only now, for the cases compaction handles too bluntly: a handful of enormous tool results you want gone while the rest of the conversation stays verbatim. Size clear_at_least from the breakeven rule rather than a round number: on a 5-minute cache, cleared tokens times requests-before-the-next-clear must exceed 11.5 times the tokens you keep.

Stage 5 — memory, underneath all of it. The memory tool is what makes stages 3 and 4 safe. Anthropic’s guidance for long-running agents is explicit:

“consider using both: compaction keeps the active context small without client-side bookkeeping, and memory preserves the information that must survive summarization.”

With context editing it goes further — the docs describe an automatic warning to Claude as the clearing threshold approaches, so it can write what matters to memory files before the clear takes it.

What stacks and what fights

The pattern: everything composes except where a lever mutates the cached prefix, and the cache is where your input economics live.

One request with everything on

Here is the composed configuration. Two beta headers, two GA tools, three entries in the edits array, and a cache breakpoint placed where it survives compaction:

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=8192,
    betas=["context-management-2025-06-27", "compact-2026-01-12"],
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        # keeps the system prompt cached separately, so a compaction
        # only rewrites the summary and not the whole prefix
        "cache_control": {"type": "ephemeral"},
    }],
    tools=[
        # GA, no beta header
        {"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
        {"type": "memory_20250818", "name": "memory"},
        # your own tools, invisible until Claude searches for them
        *[{**t, "defer_loading": True} for t in MY_TOOLS],
    ],
    context_management={
        "edits": [
            # documented rule: clear_thinking must be listed first
            {"type": "clear_thinking_20251015",
             "keep": {"type": "thinking_turns", "value": 2}},
            {"type": "clear_tool_uses_20250919",
             "trigger": {"type": "input_tokens", "value": 60000},
             "keep": {"type": "tool_uses", "value": 5},
             "clear_at_least": {"type": "input_tokens", "value": 20000},
             "exclude_tools": ["memory"]},
            {"type": "compact_20260112",
             "trigger": {"type": "input_tokens", "value": 150000}},
        ],
    },
    messages=messages,
)

Three notes on that block, in descending order of how much trouble they will save you.

The combined config is not a documented example. Anthropic publishes compaction on its own and the clearing strategies on their own; both live in context_management.edits, and the only stated ordering constraint is that clear_thinking_20251015 comes first. Everything else about running all three together is the schema’s implication, not a published recipe. Run it against the API before you build on it.

exclude_tools: ["memory"] is a judgment call, not a doc recommendation. The reasoning: memory results are the mechanism by which state survives clearing, so clearing them defeats the purpose. Apply the same thinking to any tool whose results you rely on later.

The triggers must be ordered against each other. Clearing fires at 60k input tokens, compaction at 150k. If you set the compaction trigger below the clearing trigger, compaction always wins and the clearing strategy never runs. Compaction’s minimum is 50,000, so there is not much room to invert them accidentally, but it is worth checking rather than assuming.

The cost function needs a fix

The previous post closed with a cost function that reads the four billed buckets out of the usage object. Enabling compaction breaks it, and the docs say so directly:

“The top-level input_tokens and output_tokens do not include compaction iteration usage. They reflect the sum of all non-compaction iterations. To calculate total tokens consumed and billed for a request, sum across all entries in the usage.iterations array.”

That is the worst possible failure mode for a cost tracker: it under-reports exactly the requests that cost the most, because a compaction pass reads your entire window. A dashboard built before you enabled the feature will show costs falling at the moment they rise.

The patch is small:

def iteration_cost(u) -> float:
    """Cost of one sampling iteration. Rates from the previous post."""
    return (
        u.get("input_tokens", 0)                  * RATES["input"]
        + u.get("cache_creation_input_tokens", 0) * RATES["cache_write"]
        + u.get("cache_read_input_tokens", 0)     * RATES["cache_read"]
        + u.get("output_tokens", 0)               * RATES["output"]
    )

def message_cost(usage) -> float:
    """Total billed cost of a response, compaction included."""
    iterations = usage.get("iterations")
    if iterations:
        # compaction ran: top-level totals are incomplete by design
        return sum(iteration_cost(i) for i in iterations)
    return iteration_cost(usage)

When the answer is to do nothing

Every lever here has a floor below which it costs more than it returns. Anthropic is unusually direct about this, and the thresholds are worth knowing before you spend a sprint:

• Under 10 tools, or every tool used every request, or definitions under 100 tokens — skip tool search. You will pay a search round trip to save nothing.
• Conversations that never approach 50,000 input tokens — compaction cannot fire; its minimum trigger value is 50,000.
• Clearing more often than the rewrite pays back — if cleared tokens times requests-before-the-next-clear does not exceed 11.5 times what you keep, the feature is a net cost on a 5-minute cache, 19 times on a 1-hour one.
• Bills dominated by output — if the cost-weighted mix shows half your spend is output tokens, context work is aimed at the wrong half of the invoice. Effort levels and model choice will move more.

There is a version of this work that is pure loss: a week of engineering, a security surface, a broken cost dashboard, and a 4% saving on a bill that was never mostly context. The measurement stage exists to catch that before it happens.

Symptom to lever

The quick reference, which is what this page is really for:

The series

This playbook sits on top of four posts, each one lever in depth:

1. Context editing — clearing spent tool results, the parameters that matter, and why the cache invalidation is the part that bites.
2. Compaction — summarizing the whole conversation server-side, the hidden sampling pass on your invoice, and when summarizing destroys information the agent needed.
3. The MCP context tax — the roughly 55k tokens of definitions you pay before any work happens, and the two GA features that cut it.
4. Token savings are not dollar savings — converting any of the above into money, and why two levers on the same request can differ 90-fold in what they are worth.

The thread running through all four: context engineering is genuinely worth doing, and it is worth doing for the right reason. It buys window headroom, lower latency, and better tool selection, and it prevents the failed runs that get billed in full and then repeated. It is a reliability discipline that sometimes saves money, not a cost lever that sometimes improves reliability. Teams that adopt it the first way stay happy with it. Teams that adopt it the second way go looking for the savings and find 9%.

Verified on 2026-07-28 against Anthropic’s official documentation: context editing (both strategies, parameters, ordering rule, cache behavior, memory integration), compaction (beta header, trigger minimum, usage.iterations billing, caching recipe), the memory tool (GA status, client-side model, path-traversal warning), tool search, programmatic tool calling, and pricing. Beta identifiers and parameter shapes change; re-check them against the docs before shipping rather than copying from any article, this one included. See our methodology for how we verify.