Claude's memory tool lost its exemption from context editing

Quick answer

As of October 6, 2026, the memory tool is the documented way to keep information alive across a Claude conversation that context editing is busy pruning. The memory tool's own documentation page used to carry one short paragraph telling you to exempt the memory tool from that pruning. That paragraph, and the two code examples under it, are gone.

The heading they lived under is gone too. It was ## Using with Context Editing. It is now ## Context editing integration, and the section is two sentences that point you at another page. The word exclude_tools now appears zero times in the entire memory tool document.

Anthropic's own context engineering cookbook still tells you the recommendation is there. It says the memory tool docs "recommend this explicitly when layering the two", and it links to the anchor #using-with-context-editing. That anchor no longer resolves to anything. A URL fragment never returns an error, so the page loads, you land at the top, and nothing tells you the thing you came for was deleted.

Meanwhile the one surviving combined example, which now lives on the context editing page, ships in nine languages and not one of them sets exclude_tools.

The moment

I was not looking for this. I was reading the memory tool page end to end because my own four mechanisms post from September 2026 closed with a line admitting I had skipped the memory tool and that it deserved its own run. That is the line I was trying to pay off.

So I read the page, got to the context editing section, and found two sentences and a link. That felt thin for the pairing everyone recommends. I went to the other page to find the detail, found a combined example with no exclusion in it, and assumed I had simply misremembered the guidance existing at all.

Then I found Boyuan Chen's documentation diff monitor, which snapshots these pages. The February 17, 2026 snapshot has the paragraph. I had not misremembered it. It had been removed.

Finding 1: the deleted paragraph, and the date range it vanished in

Here is what the memory tool page said on February 17, 2026, taken from that snapshot.

Verbatim: "You can also exclude memory tool calls from being cleared to ensure Claude always has access to recent memory operations:"

Under it, a Python example and a TypeScript example, both carrying the same thing:

{
  "edits": [
    { "type": "clear_tool_uses_20250919", "exclude_tools": ["memory"] }
  ]
}

The August 12, 2026 snapshot of the same page has exclude_tools at zero occurrences, has no Using with Context Editing heading, and already carries the current Context editing integration heading. So the removal happened somewhere between February 17 and August 12, 2026. I cannot narrow it further than that from the snapshots I could find, and I am not going to guess at a reason.

The current memory tool page matches the August state. I counted exclude_tools across the whole document: zero.

Finding 2: the vendor's own cookbook still cites the deleted section

This is the part that makes it more than a tidy-up. Anthropic's context engineering cookbook carries a note that reads, in part:

Verbatim: "when combining clearing with the memory tool, the exclude_tools: ["memory"] setting (shown in the config below) prevents the agent's memory reads and writes from being cleared. Without it, the agent could lose track of what it just saved."

And then it says the memory tool docs "recommend this explicitly when layering the two", linking the anchor #using-with-context-editing on the memory tool page.

That anchor was correct when it was written. It matches the February heading exactly. It does not match anything on the page today.

The control that convinced me this is a break rather than sloppy linking: the same cookbook note links a second anchor on the same page, #prompting-guidance. That one still resolves. The page still has a ## Prompting guidance heading. So the cookbook's links were accurate when authored, and exactly one of them broke, and it is the one carrying the recommendation.

A dead fragment is the quietest possible failure. No status code changes. No redirect. You click a citation, the right page loads, and you scroll looking for something that is not there.

Finding 3: the memory read is the first thing in the queue

I established the mechanical half of this in September 2026 and I am not going to re-derive it here, only join it up. Clearing runs oldest first, in chronological order. The keep default is three tool uses. exclude_tools is unset by default.

What I did not know in September, because I had not read the memory tool page, is what the memory tool does to the front of that queue.

When the memory tool is in your tools array, the API appends an instruction to your system prompt. You do not send it. Its first line is:

Verbatim: "IMPORTANT: ALWAYS VIEW YOUR MEMORY DIRECTORY BEFORE DOING ANYTHING ELSE."

So the session's first tool call is a memory directory read, by server-side instruction. Which means that in a session running both features with the documented configuration, the oldest tool use on record is a memory read, and the oldest tool use is the first one cleared.

That is the whole shape of it. The tool you added to survive clearing has its own output positioned first in line for clearing, and the sentence that told you to prevent that was deleted.

I want to be careful about how strong this is. It is first in line, not always cleared. Nothing is cleared until the trigger fires and there are more tool uses than keep. And the memory content is not destroyed: the files are on your infrastructure, Claude can read them again, and cleared results are replaced with placeholder text rather than vanishing silently. The cost is a repeated read, each repeat itself clearable, each clearing event invalidating a cached prefix you were paying for.

Finding 4: the surviving example is less careful than its neighbour

The combined example now lives in the context editing page's Using with the memory tool section. It ships in nine languages. I checked every one. None sets exclude_tools.

What makes that worth pointing at is the same page's own Advanced configuration example, a few hundred lines earlier. That one does use exclude_tools, and the tool it protects is web_search:

{
  "type": "clear_tool_uses_20250919",
  "trigger": { "type": "input_tokens", "value": 30000 },
  "keep": { "type": "tool_uses", "value": 3 },
  "clear_at_least": { "type": "input_tokens", "value": 5000 },
  "exclude_tools": ["web_search"]
}

Protecting search results is a defensible call: a web search is slow and rate limited and re-running it costs real money, while a local file read is nearly free. I am not arguing that example is wrong. I am pointing out that on one page, the author who was configuring a general agent reached for the exemption, and the author writing the memory section did not, and the memory section is the one documenting the mechanism whose entire job is persistence.

Every occurrence of exclude_tools in the context editing page names web_search. Not once memory.

Finding 5: the sentence that survived the edit is the wrong one

The memory tool page's compaction section, today, says this:

Verbatim: "Context editing clears specific tool results on the client. Compaction automatically summarizes the whole conversation on the server when the conversation approaches the context window limit."

That is backwards on the first clause, and three other vendor pages say so. The context editing page has a section whose heading is literally Context editing happens server-side, and it reads:

Verbatim: "Context editing is applied server-side before the prompt reaches Claude. Your client application maintains the full, unmodified conversation history. You do not need to sync your client state with the edited version."

The compaction overview describes context editing without any client claim. The cookbook says clearing "fires server-side" and lists its trigger as server-side in a table.

This matters more than a preposition should, because acting on it has a documented hard consequence. If you believe context editing is clearing things on your client, the natural response is to mirror the clearing in your own message array so your copy matches what the model saw. The context editing page says that is unnecessary. It also says, two paragraphs down, that client side edits to earlier turns can invalidate thinking blocks in every later assistant turn, and that for accounts created on or after August 31, 2026 a request replaying an invalidated block is rejected unless you opt into dropping it.

So one wrong clause routes a careful reader toward writing code that, on a new account, produces a rejected request. I wrote that synchronisation code once, before reading the correct sentence, and said so at the time. What I did not know is that there is a live page which would have told me to.

The August 12, 2026 diff shows this paragraph was edited in that pass. The link inside it was rewritten to an absolute URL. The clause was left alone. So the edit that removed the correct guidance touched the incorrect sentence and kept it.

Finding 6: the fix is one line and it is not free

The fix is the deleted line. The tool's name must be memory, which the page states as a requirement, so the value is not guesswork:

context_management = {
    "edits": [
        {
            "type": "clear_tool_uses_20250919",
            "trigger": {"type": "input_tokens", "value": 60000},
            "keep": {"type": "tool_uses", "value": 5},
            "clear_at_least": {"type": "input_tokens", "value": 10000},
            "exclude_tools": ["memory"],
        }
    ]
}

The trade I had not thought about until I put the parameter table next to itself: exclude_tools removes tools from the clearable pool, and clear_at_least declines to apply the strategy at all if it cannot clear its minimum.

Verbatim, from the parameter table: "Ensures a minimum number of tokens is cleared each time the strategy activates. If the API can't clear at least the specified amount, the strategy will not be applied."

On an agent whose tool traffic is mostly memory operations, exempting memory can shrink the clearable pool below your floor, and then clearing silently does nothing. Your context grows as though the feature were off. The only signal is an absent entry in context_management.applied_edits, which is a thing you notice only if you were already logging it.

I am labelling that one derived rather than measured. It follows from two documented parameter behaviours sitting in the same table, and I have no key to run it.

What I changed

I added exclude_tools with memory on it to every configuration I have that runs both features. I started asserting that applied_edits is non empty when I expect clearing to have fired, rather than assuming a configured strategy is an applied strategy. And I went back and corrected my own September note, which quoted the correct server-side sentence and did not know a second page contradicted it.

The thing I did not change is the keep value. Raising it to protect the memory read is the wrong instrument: it protects the three or five most recent calls regardless of what they are, which is not the same as protecting the one tool whose output you cannot cheaply reconstruct.

What I did not verify

I have no Claude API key in this environment, so every behavioural claim here is read off current documentation rather than measured. I did not watch a memory read get cleared. I did not observe clearing order in a live session. Findings 3 and 6 are joins across documented behaviours, not experiments, and if the implementation special cases Anthropic-defined tools in a way no page mentions, Finding 3 is wrong and I would not know.

I did not establish when between February 17 and August 12, 2026 the paragraph was removed, and I did not find any changelog entry or release note describing the removal. I looked. I am not claiming none exists.

I did not verify the February and August snapshots against any second independent archive. They come from one monitor, and both are consistent with the current live page in the direction they should be, which is corroboration rather than proof.

I did not read the remaining SDK code paths to check whether any of them inject exclude_tools on your behalf when both features are configured. If one does, the practical exposure is narrower than this reads.

I did not check whether other vendors' context management features exempt their own memory equivalents by default. I have not read their current reference docs, and writing that comparison from memory is exactly how you end up publishing something confidently wrong.

Prior art I am standing on, not restating

Two sources already carry the recommendation itself, and I am crediting rather than claiming it. Anthropic's cookbook, linked above, states the exemption and its reason plainly. Independently, Alcreon's clearing playbook carries it in a tuning table, with exclude_tools default unset and the advice to set it to memory "and anything expensive to re-fetch", alongside the clear_at_least and cache economics. If you want the configuration guidance rather than the documentation archaeology, read that.

What I have not found anywhere, and what this post is actually for, is anyone noting that the recommendation was removed from the docs, that the vendor's own cookbook still cites it at a dead anchor, or that the memory tool page states the inverse of its sibling on where clearing happens.

For the mechanics of clearing itself, including the cache invalidation economics and why clear_at_least exists, my four mechanisms post is the one to read first. For what else counts as part of a prompt prefix, and why that is a separate question from what the cache keys on, see the two prefixes. And if you landed here expecting the CLI feature rather than the API primitive, those are genuinely different things and I keep them apart in what I keep in Claude Code memory.

Postscript: a deleted paragraph leaves no trace on the page that lost it. The citation pointing at it is the only thing that still knows it was ever there.