News for hackers. Stuff that matters.
Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by lukax on Monday November 09, 2026 @04:02AM (#50422979)
I guess it's just capacity problems. They probably have a fixed amount of compute and they need to make space for new models that will be released. So they quantize existing models e.g. in half so that can use 50% of current capacity for new models. They have such massive scale that you just cannot dynamically get that amount of new compute online so they need to work with what they have. No provider has thousands of GPUs idle.
Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by Rapzid on Monday November 09, 2026 @05:55AM (#50423895)
They don't do that. They've said as much and there is zero evidence to support it.

Under load requests queue and take longer.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by cma on Monday November 09, 2026 @06:09AM (#50424003)
There are a couple documented things where it has degraded: in late 2025 or so when they transitioned to TPUs, they had a bug in the compiler for sampling logits in a cheaper way than GPUs because of it being less efficient on TPUs that caused a big degradation.

If you got routed to a TPU instance at some point in your chat another bug kept you there.

Earlier this year in 2026 they decided to save usage by stripping out all thinking tokens if you left your chat idle for one hour (cache timeout) and then came back to it, causing massive degradations. They fixed that, but recently they switched to doing auto-compactions for long running chats in anticipation of them going stale in cache. I think that one is usually what you want anyway and there is at least a way to recover to the uncompacted chat if you really need it, but it might also be a source of some degradation people are seeing now.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by Rapzid on Monday November 09, 2026 @01:04PM (#50429117)
Yes, I'm aware that there have been a number of isolated platform and harness regressions (bugs and behavior changes).

But the model NERF conspiracies are bunk.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by cma on Monday November 09, 2026 @03:42PM (#50431778)
I think the bug one wasn't bad intent, but it was a fact that even without the bug you got different behavior with the approximate logit sampling on TPUs. I say that was jut a minor platform optimization though and wouldn't be too upset about them not disclosing it.

But the harness one was not just a random harness regression; they were getting a huge influx of users and pretty clearly did it to save capacity. Not a great thing when you might be relying on attention to those thinking traces to reduce the risk of prompt injection etc. and it could have gone beyond major task degradation into a safety/security issue.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by Rapzid on Monday November 09, 2026 @04:06PM (#50432138)
Yeah, perhaps but they are also trying to make the harnesses more efficient so they are competitive with their competitors on efficiency. Reducing token use can also reduce context size and improve aligned accuracy in general..

Through the lens of a conspiracy theory this could be viewed narrowly as "cheating" their users to reduce load.

But there are other motivations for the constant work going on in the harnesses that paint a fuller picture.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by nonethewiser on Monday November 09, 2026 @01:32PM (#50429534)
This is what I've been wondering. I mean we all know they are compute constrained so I get that intuition to a point.

However, how would less compute result in degraded performance as opposed to more latency? Like is amount of compute something you can actually tune to control for latency? Wouldn't that imply they are actually serving requests in other models? If I run a very large model locally on a shit computer vs. something maxed out, it's the latency that differs.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by Rapzid on Monday November 09, 2026 @02:57PM (#50431033)
The major providers like Azure along with OpenAI and Anthropic have the concept of "priority processing" which comes with service level guarantees on latency and token throughput. It's more expensive.

They basically dynamically allocate compute into this pool from the general pool to meet demand and SLAs. If demand for priority processing spikes latency in the general pool spikes.

Almost all subscriptions use general pool. That's why it gets really slow sometimes. Unless you use "fast" which acts like priority processing and is super expensive.

So that's part of how they balance compute based on demand and fund the "excess" capacity.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by nonethewiser on Monday November 09, 2026 @03:36PM (#50431692)
Thank you for the information but I'm not sure you understand my question. I'm not surprise to hear these details on how they control for latency.

Im asking on how lower compute could translate to worse model performance. That's the implicit claim being made when people are saying Anthropic nerfs a model (result is bad, not necessarily slow). The only way I can think that could happen is if they actually swapped Opus 5.5 out for a worse model that takes less resources to do inference.

Re:Is Opus 5.5 nerfed? Thinking patterns changed on November 3 by Rapzid on Monday November 09, 2026 @03:58PM (#50432031)
Yes, that's what they are claiming; that the full(er) precision models get heavily quantized and/or distilled to lesser, "nerfed" models and requests get routed to them based on load, time since release, time to new model release, and reading chicken bones.

There is no proof, the frontier labs deny it, and certainly it's not happening on hosts like Azure, Amazon, and etc.. The claim is that it's "trivial" to detect observation, so they serve the normal model if you try to measure it..

Basically the conspricy theory is:

* OpenAI/Anthropic nerf their models regularly to reduce compute demand

* It's impossible to measure and thus prove