Claude Fable 5's "Kettle" Leak: The Internal Model ID Hidden in Signed Thinking — What We Know So Far

On August 16 at 11:29:45 p.m. PDT, a researcher on X posted a claim that turned an unglamorous corner of An​thropic's API into a what-we-know-so-far story: decode the server-signed "signature" that rides on every Claude thinking block, they said, and field six names the model that actually answered you. In their reading, responses publicly labeled claude-fable-5 — the Mythos-class Claude Fable 5 that An​thropic has shipped broadly since June 9, 2026, at $10/$50 per million tokens — began carrying an internal identifier that appears nowhere in An​thropic's public documentation: claude-kettle-e2c95a10-v2-prod. Nothing about the response label changed. Nothing about billing, the API's top-level model field, or An​thropic's pinned-snapshot guarantee was shown to change either. What changed was a string buried in a field the documentation explicitly tells developers not to parse.

This is a leak report, not a verdict. The finding is four days old, it rests on a single researcher's decoding that has not been independently reproduced, and An​thropic has not commented on what "Kettle" — or its companion label MYCRO_MODEL_MANATEE — refers to. The useful question is not "did An​thropic swap Fable 5?" The evidence does not establish that. The useful question is what an internal model ID appearing under a public model ID would mean if it were real, and what it would not. Here is what we know so far.

What the leak actually found

The signal is a single X post from @chetaslua (status 2089783170896179632, posted August 16, 2026), written in the account's usual "first with proof" style. The claim, in short:

• Claude's thinking blocks carry a server-signed protobuf in the signature field.

• Field six of that protobuf, the researcher says, holds the identifier of the model that actually produced the response.

• Starting at 11:29:45 p.m. PDT on August 16, 2,582 out of 2,582 sampled signatures carried the same value: claude-kettle-e2c95a10-v2-prod.

• A second internal label, MYCRO_MODEL_MANATEE, also appeared in the same metadata.

The "2,582 of 2,582" figure is doing the rhetorical work: it is the researcher's evidence that this was not a one-off or an A/B slice but a wholesale switch of whatever the identifier points to. What the post does not include is the method behind the decode — no raw signatures, no decoding script, no inferred protobuf schema, no full response metadata. The public evidence is a summary graphic. That makes the finding plausible and currently unverifiable in the same breath.

Why the signature even has a "field six"

Every thinking block Claude returns carries a signature field. Per An​thropic's thinking documentation, that signature is "an encrypted copy of the full reasoning" that you are supposed to pass back unchanged in multi-turn and tool-use conversations, and the API uses it "to verify that thinking blocks were generated by Claude." On Claude Fable 5 the default behavior makes the signature the only visible trace: with display set to "omitted" — the default on Fable 5, Mythos 5, Opus 5, and Sonnet 5 — the thinking block comes back with an empty thinking field and just the signature populated.

The documentation then adds a sentence that matters for any leak built on this field: "The signature field is opaque: don't interpret or parse it." Parsing it is precisely what the Kettle claim does. That is not proof the claim is wrong — the signature has to be machine-readable for An​thropic's own serving stack — but it means the decode was performed against the vendor's explicit instruction, on an undocumented protocol, and the researcher's reconstruction of that protocol has not been published. Every inference built on "field six means the serving model" inherits that uncertainty.

What it does not prove

Start with what the evidence actually is: a response publicly labeled claude-fable-5 carried a previously unreported internal identifier. That is the whole of it. The identifier alone does not establish that An​thropic replaced Fable 5's weights, that a more capable successor exists, that responses got better or worse, or that any request was routed to a smaller model. "Kettle" could be an internal serving deployment name for the very same Fable 5 snapshot; it could be the name of a router component; it could be a classifier in the safety stack. The codename cannot distinguish between those.

An​thropic's own versioning policy explains why the leak is compatible with nothing having changed. From the "Model IDs and versioning" docs, two statements sit side by side:

• "An​thropic does not update the weights or configuration of an existing model ID. When an updated version is available, it ships under a new model ID."

• "Model weights are fixed for a given ID, but the serving infrastructure around the model can change over time. This infrastructure includes components such as the request router, safety classifiers, and sampling logic."

That second sentence is the entire conceptual gap between "Kettle is a scandal" and "Kettle is a routine Monday." The docs even anticipate behavioral drift: "Occasionally, infrastructure updates produce minor differences in observable behavior even when the model ID and weights have not changed." A new router or serving deployment named Kettle would fit inside that sentence exactly. For the leak to be genuinely damning, it would need to show either a new model behind the ID despite the policy, or a mechanism that violated the visibility rules below.

The documented fallback routing Fable 5 already has

Claude Fable 5 already ships with a model-switching mechanism that is real, documented, and meant to be visible. Safety classifiers inspect requests and can route a subset — An​thropic cites offensive cybersecurity, dual-use biology, model distillation, and some frontier chip-development work — to a Claude Opus 5 model. On consumer surfaces the fallback is supposed to be conspicuous: a notice, the serving model's name on the answer, and the model picker switching to Opus. In the API, the response exposes the serving model through the top-level model field and a dedicated fallback content block.

The Kettle claim describes something different, and the difference is the part that would matter: an internal identifier appearing under a response that kept the public Fable 5 label. The researcher's post does not show a fallback notice, a changed API model field, or a fallback block — if it had, the story would be "the documented fallback fired," not "An​thropic is silently routing." Without that, the leak has not shown that any visibility guarantee was violated, because it has not shown what Kettle is.

Why it matters even if nothing changed

Pinned model IDs are a trust mechanism. An​thropic's docs promise that "when you use a model ID in an API request, the underlying model remains constant for the lifetime of that ID" — the whole reason a team can benchmark against claude-fable-5 and expect the result to mean something next quarter. A hidden identifier sitting under that ID, whatever it is, is a reminder that the guarantee covers weights and configuration, not the entire path from request to token. If a genuinely different model ever ran under a public ID without disclosure, every eval, every cost forecast, and every quality regression test keyed to that ID would be silently invalid.

The billing angle sharpens it. Claude Fable 5 costs $10 per million input tokens and $50 per million output tokens — An​thropic's highest published rate. If the serving model ever differed from the billed ID, the question becomes which rate applies and who decides. The leak offers no evidence that happened; the point is only that the signature field is where you would first look for a sign of it.

The timing is also worth noting. This is the third An​thropic signal in nine days: on August 7 the company announced it had retrained Fable 5's biology classifier, cutting biology-related fallbacks by roughly 85% in internal testing; on August 14 its Responsible Scaling Policy Risk Report acknowledged an unreleased internal "Model 2" that An​thropic calls "a noticeable improvement" over Claude Mythos 5 and that it does not plan to release. Both are vendor statements, but together they show An​thropic actively changing the systems around Claude Fable 5 — classifiers on the 7th, an acknowledged internal successor on the 14th — while keeping the claude-fable-5 ID fixed. Kettle would be the same shape of story, minus the disclosure.

What to do about it

For API callers, the practical position is boring and correct: one identifier is not evidence of a swap, and there is nothing actionable in the leak yet. What you can do is make your own evidence. Log the top-level model field and any fallback blocks on the responses you actually receive, and watch token and cost deltas on a fixed workload. If a documented fallback fires, it will be visible in exactly those places. That is the only test that matters for your workload, and it does not depend on anyone decoding An​thropic's signature format.

If you are routing to Claude Fable 5 through OrcaRouter, the same response shape comes back that An​thropic returns, and because we pass provider list prices through with zero markup there is no second set of prices to reconcile — if An​thropic ever changes Fable 5's rate, the new number is live on our side the same day. For an unverified situation like this one, the low-risk way to keep using the model without betting a production path on a rumor is to route a slice of real traffic to Claude Fable 5 with automatic failover to a proven fallback — Claude Opus 5 at $5/$25 per million, or a cheaper coding-tier model — so a quality regression turns into a routing decision instead of an incident. Same key, no second contract, and the failover is a routing-DSL change rather than a rewrite.

What we're watching

• Whether An​thropic comments. The cleanest resolution is a one-line acknowledgment of what Kettle and Manatee are. Silence is itself informative.

• An independent reproduction. Someone publishing raw signatures, the decoding method, and the inferred protobuf schema would move this from one person's graphic to a checkable claim. Until then it is a what-we-know-so-far, not a finding.

• The visibility surface. If claude-fable-5 responses start showing fallback notices, a changed API model field, or fallback blocks, the "documented fallback" reading gets stronger; if not, the "undocumented route" reading does.

• A new model ID. An​thropic's versioning policy says a genuinely new version ships under a new ID. The cleanest confirmation that Kettle is a real successor would therefore be An​thropic releasing something — not routing in place. Watch for a claude-fable-5.1 or similar.

• Whether "Manatee" gets explained. The second label is a thread nobody has pulled yet.

FAQ

Is An​thropic actually routing Claude Fable 5 to a different model?

Not proven. The leak shows that responses labeled claude-fable-5 carried an internal identifier, claude-kettle-e2c95a10-v2-prod, in a signed thinking signature. It does not show that weights changed, that a successor was deployed, or that any request was downgraded. "Kettle" could equally be the name of an internal serving deployment for the same Fable 5 snapshot.

How was the Kettle identifier found?

Researcher @chetaslua says they decoded a protobuf inside the signature field of Claude's thinking blocks and read the model identifier from field six. An​thropic's docs call the signature "opaque" and tell developers not to parse it, and the researcher's decoding method has not been published, so the claim is not yet independently reproducible.

Does this violate An​thropic's pinned-model guarantee?

Unknown. An​thropic's versioning docs say it never updates the weights or configuration of an existing model ID and that new versions ship under a new ID — but they explicitly allow the serving infrastructure around a model (the request router, safety classifiers, sampling logic) to change. A Kettle identifier could be exactly that kind of change, which would not violate the guarantee.

How would I know if the model serving me changed?

Watch the top-level model field in API responses, look for fallback content blocks, and track token and cost deltas on a fixed workload. An​thropic's documented fallbacks are meant to be visible in those places. There is no public API field that exposes the Kettle identifier.

The honest read is that a leak has named something, not proven what it is. The Kettle identifier is real in the only sense a leaked string can be: a researcher says it is there, 2,582 of 2,582 times, starting on the night of August 16. What it points to — a new model, a renamed deployment, a router component, a classifier — remains unverified, and An​thropic's own documentation offers a perfectly mundane explanation for the whole thing. That is the value of the piece and its limit. Until a raw signature is published or An​thropic says what Kettle is, the right posture is to treat it as a what-we-know-so-far: worth watching, worth logging your own traffic for, and not worth changing your model choice over — especially when a routing layer lets you keep the option open either way.