Claude's token-efficient tools header has no page left to check (2026)

Quick answer

On 11 October 2026 I set out to delete two beta headers from a request builder nobody had touched in a year. One of them, token-efficient-tools-2025-02-19, no longer has a page. The URL that used to define it now returns a 307 to a migration guide index that mentions neither the feature nor beta headers at all.

The entire surviving description of what that header does is one sentence on one of Anthropic's four model migration guides. It says the headers have no effect. That tells you about the effect. It does not tell you whether the name is still accepted, and the same documentation set is unusually careful about that distinction everywhere else.

The moment

The builder had an anthropic-beta line with two comma-separated values in it, added by someone who left, pinned by nothing, covered by no test. token-efficient-tools-2025-02-19 and output-128k-2025-02-19.

Deleting a header is a one-line change and I wanted to know the blast radius before I made it. Specifically: is this header currently doing something that my code depends on without knowing? I had a reason to ask rather than assume. In September I wrote up the Files API beta header, which is superseded and emphatically not inert: it silently selects an older response shape. So "it is old, therefore it is dead" is a guess I had already watched fail once.

So I went to read the page. There is no page.

Finding 1: the page is gone, and the redirect lands somewhere that mentions neither the feature nor betas

agents-and-tools/tool-use/token-efficient-tool-use returns HTTP 307. The location header is /docs/en/about-claude/models/migration-guide.md.

That target exists and resolves. It is 1,055 bytes. It is a bare index: four bullets linking the Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5 migration guides, then a four-bullet "Get help" section. Occurrences of token-efficient on it: 0. Occurrences of the word "beta" on it: 0.

So the redirect does not land on a successor page, a deprecation notice, or an explanation. It lands on a directory of four documents, and the reader has to guess which one, if any, mentions the thing they came for.

I checked whether the page is indexed anywhere. Anthropic publishes a machine-readable documentation index at platform.claude.com/llms.txt. It is 82,696 bytes, 830 lines, and carries 760 documentation URLs. Occurrences of token-efficient: 0. Occurrences of 128k: 0.

That zero is only worth something if the index would have shown a comparable page, so I ran the control. The index does list Fine-grained tool streaming, Extended thinking (legacy), Beta headers, all four per-model migration guides, and the redirect target itself under the name "Upgrade between model versions". The control fires. The feature has no entry in a 760-URL index that lists all of its neighbours.

Finding 2: the whole surviving description is one sentence, on one of four migration guides

I fetched 19 Anthropic documentation pages for this piece. Total occurrences of token-efficient across all of them: 5, in exactly two files.

Both are per-model migration guides. The Haiku 5.5 guide (19,755 bytes) has 0. The Fable 5.1 guide (93,980 bytes) has 0. So of the four guides the redirect points you at, two of four mention the header, and the redirect does not say which.

The two are not equivalent either. The Sonnet 5.5 guide gives you the instruction and no reason, twice, verbatim:

Sonnet 5.5 migration guide: "Remove token-efficient-tools-2025-02-19 and output-128k-2025-02-19."

The Opus 5.5 guide is the only document in the set that explains anything, under a heading reading "Additional recommended changes":

Opus 5.5 migration guide, verbatim: "Remove legacy beta headers: Remove token-efficient-tools-2025-02-19 and output-128k-2025-02-19. All Claude 4 and later models have built-in token-efficient tool use and these headers have no effect."

That is the complete public description of this feature's current status. One sentence. Note what it is: this is not a deprecation, it is a capability that became default. The thing the header bought you, you now get for nothing. That is good news, and the only place it is written down is a bullet in a model migration guide filed under "recommended" rather than "required".

The canonical places you would look first are all silent. Tool use overview, 39,434 bytes: 0 occurrences. Tool reference, 19,187 bytes: 0. Beta headers, 9,847 bytes: 0.

Finding 3: the docs draw exactly the distinction this case needs, and apply it to the neighbours

This is the part that turned a shrug into a finding.

The beta headers page tells you where to look for a beta name, verbatim:

Beta headers page: "Each feature's documentation states the exact beta name to send."

and, in its version-naming section:

Beta headers page: "Always use the exact beta feature name as documented."

Both instructions are unfollowable for this header, because the feature's documentation is the thing that is gone.

Now look at how the same documentation set handles the two legacy headers sitting in the very same removal bullets. Both of their pages are still live, and both pages tell you precisely what the header still does.

Fine-grained tool streaming on fine-grained-tool-streaming-2025-05-14:

Fine-grained tool streaming page, verbatim: "The exception is a request that still sends the legacy fine-grained-tool-streaming-2025-05-14 beta header, which turns fine-grained streaming on for tools that leave the field unset."

It goes further and names the hard-failure case: the legacy header cannot be combined with a computer use or browser use toolset entry, and "the API rejects a request that sends both". So for that header you are told what it still does, what overrides it, and exactly when it errors.

Extended thinking on interleaved-thinking-2025-05-14 is better still, because it coins the distinction outright:

Extended thinking page, verbatim: "Acceptance is not the same as effect"

and resolves both halves separately, per platform:

Extended thinking page, verbatim: "On the Claude API, the beta header is accepted but ignored."

Read those together and the gap is precise. The vendor's own documentation states that acceptance and effect are two different questions and must not be conflated. For interleaved-thinking-2025-05-14 it answers both. For fine-grained-tool-streaming-2025-05-14 it answers both. For token-efficient-tools-2025-02-19 the only sentence in existence answers the effect half and is silent on the acceptance half, and the page that would have carried the rest is a redirect.

Finding 4: the error contract points at documentation that is not there

The beta headers page also publishes what happens when a name is not valid:

Beta headers page, verbatim: "If you use an invalid beta name, or a beta your organization doesn't have access to, you'll receive a 400 error response"

with the error body shown as "Unexpected value(s) invalid-beta-name for the anthropic-beta header. Please consult our documentation at platform.claude.com/docs or try again without the header."

So there are three states a caller might be in, and the documentation as it stands does not pick between them: the name is still accepted and genuinely inert; or the name has been retired and the request now returns a 400; or acceptance varies by platform, which the extended thinking page shows is a real pattern rather than a hypothetical.

The second state is the interesting one, because the error message instructs you to consult documentation that, for this specific name, no longer exists. And the same page warns that beta features may "Be deprecated or removed", which is a statement about features and not about whether their names keep being accepted afterwards.

I want to be careful here. I could not test this, and I say so plainly below. The point is not that a 400 is likely. The point is that the one-sentence description is not enough to rule it out, and the distinction it leaves open is the one the docs themselves insist on.

Finding 5: keeping the page is the house pattern, which is what makes this one an outlier

The obvious objection is that deleting a page for a retired feature is normal housekeeping. I checked, and on this documentation set it is not the pattern.

I pulled every beta header the four migration guides tell you to remove or replace, then probed the feature page for each. Results:

Six of seven keep their page. One does not. And the index goes out of its way to signal the pattern: the entry for the superseded manual-thinking page is listed as "Extended thinking (legacy)", which is the only entry in all 760 carrying a legacy label. The convention is to keep the page and mark it, and this header is the exception rather than an instance of it.

I did not find a page for the twin header, output-128k-2025-02-19, either. I am not reporting that as a second deletion, because I never located a path where it used to live and a 404 on a URL I guessed is not evidence about anything.

What this changes about the cleanup

Concretely, for anyone with an old anthropic-beta line:

If the header is fine-grained-tool-streaming-2025-05-14 or interleaved-thinking-2025-05-14, go to the feature page. It will tell you what the header still does before you remove it, and in the fine-grained case there is a real behavioural difference to account for rather than a no-op.

If it is token-efficient-tools-2025-02-19, the documented position is that on Claude 4 and later you already have the capability and the header does nothing. Removing it is what the vendor recommends. What you cannot do from the documentation is verify that leaving it in place is harmless, which is the question you actually have when the header is sitting in shared code you did not write.

The honest summary is that the recommendation is almost certainly right and is also unusually hard to check, and that the reason it is hard to check is a deleted page rather than anything about the feature.

What I did not verify

I have no Anthropic API key in this environment, so every claim here is measured from documentation and from HTTP status codes, not from live API behaviour. Specifically:

I did not send token-efficient-tools-2025-02-19 to the API, so I do not know whether it is accepted and ignored or rejected with a 400. That is a prediction I am explicitly not making. The one measurement that would settle it is a single request carrying only that header.

I did not measure what the feature did when it was live. I probed the dated documentation mirror at chenboyuan.com for the removed page on five dates and got 404 on all five, with a 9,379-byte body each time, which is that site's not-found page. That is absence of evidence, not evidence of absence: the mirror simply never captured it. The one page it did capture, the beta headers page on 2026-08-12, also carried 0 occurrences of token-efficient, which tells me the beta headers page never enumerated this name in my observable window rather than that it was delisted. The mirrors are one monitor, not independent sources.

I did not establish when the page was removed, or whether it was removed rather than renamed to a path I did not try.

I did not check Amazon Bedrock, Google Cloud or Microsoft Foundry. The extended thinking page shows platform-to-platform differences in how a legacy header is treated, so if you are not on the first-party API none of the above is safe to assume.

I did not verify the Opus 5.5 claim that Claude 4 and later models have built-in token-efficient tool use. I have no way to measure tool-call token counts here, and it is the one load-bearing factual claim in this piece that I am taking on the vendor's word.

One piece of adjacent reading, credited rather than claimed: Epsilla's write-up of the 1M context window going generally available states of a different header that "The old beta header is simply ignored, requiring no code changes." That is a reasonable reading for context-1m-2025-08-07, which is documented. It is also exactly the assumption I could not confirm for this one. And for a counterweight on the same header, Sumedh Bala's Claude Code cost series documents the opposite failure mode for that same header, verbatim: "Claude Code can drop the context-1m-2025-08-07 beta and silently cap you at 200K context". A header's presence and its absence can both be load-bearing.

I have used these migration guides before, as a source of behavioural change when swapping model strings. This is the first time I have had to use one as the only surviving documentation for a feature.

Postscript: the request builder still has both headers in it. I will take them out on Monday, which is the correct call and the one I can least verify.