Welcome to the show.
James, imagine this: you ask Claude for a code fix,
and instead of a neat little patch,
it starts sprinkling random Thai or Chinese characters into an English
reply, drops a syntax error into the generated code,
and then just...
cuts the answer off halfway with NO error message.
That was not one-off weirdness.
In Anthropic's September 2025 postmortem,
they said three separate infrastructure bugs,
one after another, degraded Claude responses from August through
mid-September,
and roughly 30% of Claude Code users saw at least one bad message in
that window.Thirty percent is the number that sticks.
Not "a few unlucky edge cases" -- THIRTY.
That's basically one out of three Claude Code users getting at least
one poisoned response between August and mid-September.
And the no-error-surfaced part is the bit that freaks me out,
because if the model crashes loudly,
fine, you know you've got a problem.
If it answers confidently with corrupted output,
now the developer starts doubting their own benchmark,
their own tests, their own eyes.Exactly.
It's like your trail bike makes a funny noise,
but only every sixth ride, and only when you're already late.
You don't know if the bike's broken or if you've gone a bit spare.
Anthropic laid out a timeline,
and the first bug starts on August 5: some requests were routed to servers
configured for an upcoming 1M-token context window.
Not the general setup people expected -- this upcoming configuration.
So traffic gets silently misrouted,
and right there you've got weird behavior before anyone's even talking
about model quality in the abstract.Wait -- August
5 is early.
So this wasn't "one bad deploy on one day." This was the start of a chain.
And that 1M-token context window server config,
even hearing that phrase, you can feel how easy it would be to dismiss.
Like, "oh, infra stuff." But misrouting to the wrong server class means
you're not even testing the model you THINK you're testing,
right?That's the tension.
People say "the model got weird," but one of these failures wasn't the
model getting moody -- it was traffic going somewhere it shouldn't.
Then August 25 brought a second issue: output corruption from a runtime
optimization misconfiguration.
That's a nasty one, because now it's not just where the request lands;
it's the actual generation path getting mangled.
That's where those garbled characters,
truncated responses, and incoherent outputs fit the picture much more
directly.August 25 twice,
though -- because there was ALSO an XLA/TPU compiler bug that surfaced
the same day, tied to mixed-precision arithmetic.
And that's a different beast.
Misconfiguration is one category of problem.
A compiler bug in XLA on TPUs with mixed precision...
that's the sort of sentence that makes every ML engineer sit up straight,
because now the system can choose subtly wrong tokens in a way that's
hard to reproduce.Yeah,
and "subtly wrong tokens" sounds small until you think about what code
generation IS.
One token off can turn valid code into broken code.
One token off in prose can be invisible.
One token off in a command or import path can waste an afternoon.
So when Anthropic says there were three separate infrastructure bugs,
that matters because these weren't three copies of the same failure.
One silently misrouted traffic.
Another corrupted output probabilities through runtime optimization gone
wrong.
And the XLA/TPU mixed-precision issue nudged token selection off in ways
that were slippery and hard to pin down.The phrase I'd use is
epistemic damage.
Not just software damage -- trust damage.
If generated code acquires syntax errors,
okay, a linter catches some of that.
If English replies suddenly spit out Thai or Chinese characters,
you know something is off.
But if the model is merely choosing the wrong token occasionally,
and it still looks plausible, now your A/B test might pass one hour and
fail the next.
Your eval suite might say the prompt is the problem when the real issue
is lower in the stack.That's the bit I keep coming back to.
Developers love to assume the bug is in their prompt,
or their parser, or some midnight change they pushed with a cup of terrible
shed coffee in hand.
Been there.
But this postmortem is a good reminder that infrastructure bugs can masquerade
as application bugs.
If a response truncates with no surfaced error,
you might waste hours rewriting perfectly decent code.
If corruption sneaks into probabilities,
you can end up "fixing" the wrong thingAnd Anthropic publishing the timeline
matters for exactly that reason.
August 5 for the routing issue.
August 25 for the runtime optimization misconfiguration.
August 25 again for the XLA/TPU compiler bug with mixed-precision arithmetic.
Those dates give developers something concrete to line up against their
own logs.
Because otherwise "Claude felt off for a while" really does sound like
vibes.
This was NOT vibes.
It was three specific failures,
over a specific window, affecting a specifically large slice of
users.
And then you get the other kind of AI pain -- not silent degradation,
but hard breakage.
Opus 4.
7 shipped on April 16, 2026,
and if your old config passes temperature,
top_p, or top_k with any non-default value in the Messages API,
you now get a 400.
So something as innocent-looking as temperature: 0.
7 -- a setting teams
have copied around for years -- can stop production COLD.Temperature
0.
7.
That's the sort of line sitting in config files like an old garden gnome
-- nobody remembers who put it there,
but everybody's afraid to move it.
And now Opus 4.
7 says, nah mate,
400.
Not "we'll ignore it." Not "deprecated warning." Just a hard API failure.
Exactly.
And there's a second breaking change right next to it: thinking.
budget_tokens
is gone too.
Extended thinking budget control is removed from the API surface for
this model, and passing that setting also returns a 400.
So if you upgraded by swapping the model name and left the rest of your
request body untouched, you could break on TWO fronts before the model
even starts generating.Let me try to explain it back.
Old habit says, "new model, same knobs." You keep temperature,
maybe top_p, maybe top_k, maybe thinking.
budget_tokens if you've been
tuning that.
In Opus 4.
7, those familiar knobs aren't just ignored -- some of them
are basically wired to the trapdoor.
Is that fair?
That's fair.
And the trapdoor number is 400,
which developers hate because it's immediate and very unromantic.
Your app just fails.
Then there's the sneakier problem: cost.
Opus 4.
7 uses a new tokenizer,
and Anthropic says it can use anywhere from 1x to 1.
35x more tokens than
earlier models depending on content type.
So your prompt and output can look basically unchanged to a human,
but the bill goes up because the tokenizer slices the text
differently.[questioning
tone] That 1.
35x is the sticky one for me.
Thirty-five percent more tokens without changing what the user THINKS
they said or got back -- that's like your servo at the petrol station
charging extra because it decided your jerry can has more edges today.
Same fuel, bigger bill.
And because it's "depending on content type," you can't just assume one
neat multiplier across everything.
Right,
and for agentic apps there's another wrinkle: reports of regressions
in long-context retrieval and agentic search at default effort levels.
The workaround people have pointed to is using high or xhigh effort in
Claude Code for agentic workloads.
Which means the default may not be good enough for the exact class of
tasks a lot of teams care about -- multi-step searching,
tool use, long-context reasoning.And that's where
the "just bump the version"
habit absolutely bites you.
Because now the upgrade isn't one thing.
It's API compatibility, removed controls,
tokenization economics, and behavior changes in agentic search.
If your team treats model upgrades like changing a logo in the header
-- easy peasy -- you're in strife.
This is dependency-upgrade territory.
Read the changelog, diff the payloads,
run evals, watch costs, the whole box and dice.I actually
think that's the deeper lesson connecting both stories.
In the 2025 Claude degradation case,
the danger was invisible system behavior making developers mistrust themselves.
In Opus 4.
7, the danger is visible if you look -- 400s,
removed fields, token shifts -- but teams often don't look closely enough
because they treat model swaps as a quick version bump.
Same emotional outcome: the engineer on call at 1 a.
m.
is staring at a dashboard thinking,
"Did I break this, or did the platform move under me?"Yeah.
And maybe that's the new default mindset: don't treat a model name like
a cosmetic string.
Treat it like upgrading a database engine,
or a compiler, or a payment SDK.
Because if a harmless old temperature: 0.
7 can 400 your production app
on April 16, 2026, the real bug isn't just in the release.
It's in the habit of assuming intelligence APIs behave like
plug-and-play
widgets.
They don't.
Anyway -- go audit your config before it audits you.
See ya.That's a solid place to leave it.
See you next time.