When a new LLM flagship launches, the capacity to serve it has to come from somewhere and as scaling laws tell us, the newer models will be bigger and require more compute than previous versions. Often, the easiest target is the outgoing model: it gets shifted to fewer, cheaper, or more constrained accelerators to make room for the new demand. This is a standard infrastructure efficiency play, but it comes at a steep cost to consistency. Over the last six months, we’ve tracked the hourly stability of Claude’s Opus family through multiple transitions:
What we found is a concern for any workload that assumes pinning to a specific model version is a guarantee that the model will behave consistently and as tested. There is no guarantee on model behavior, especially not when the compute resources & infrastructure that that guarantee is based on is under severe pressure.
Setup
At VAIL, we work on understanding model identity and behavior using techniques like behavioral fingerprinting. We actively monitor popular model APIs to understand how often the behavior fluctuates indicating changes made to the serving infrastructure and the model itself. We call this stability monitoring - lightweight and continuous tests to understand how model behavior is changing overtime.
Using data from the Stability Arena, we compute a stability score in [0, 1] — a measure of output consistency: how reproducibly an endpoint returns the same answer to the same input over time, and how well it agrees across serving paths. High stability means “ask it the same thing and you get the same thing (accounting for expected non-determinism).” Low stability means the endpoint’s behavior is drifting or noisy.
This post focuses on findings from the Stability Arena about Anthropic’s Opus model APIs (served directly by Anthropic, not via a hyperscaler). We looked at the daily stability scores for Opus model endpoints over the last 6 months (February 7, 2026 - July 9, 2026), 14 days before and after the release date for a new Opus model. The objective was to understand what the impact is on older versions of Opus when a new Opus model is released.
Release Dates
Opus 4.6: Feb 5, 2026
Opus 4.7: Apr 16, 2026
Opus 4.8: May 28, 2026
The findings are alarming for any large enterprise that assume they will get consistent behavior when they pin their applications to a specific model. This is a risky assumption, as our data indicates.
Flagship Launches Degrade Stability
When a new version of Opus is released, stability scores for the older version drops significantly. For two weeks before the release of Opus 4.7, Opus 4.6 showed high stability scores - the behavior observed through the API was consistent, hour over hour, day over day. When Opus 4.7 was released, the stability scores for Opus 4.6 were impacted, a > 20% decline in consistency. When Opus 4.8 was released, Opus 4.7 and Opus 4.6 were impacted by an even larger amount.
No changes were made to our monitoring probes, the same endpoint with the same probes. We are pinning to the same version of the Opus model in the API requests for all probes.
Immediate Decline, Slow Recovery
Not only is the drop in stability significantly, the decline happens almost immediately. And the recovery is slow. Stability scores drop as soon as the new model is released and continue to decline for several weeks. This could be a function of a staged rollout where compute resources are shuffled to accommodate the new model and its larger share of the compute resources needed to serve.
It can take several more weeks before the older model endpoints are back to having stable, consistent behavior. Even though the models are the same and the APIs are responding, there is a risk that the model behavior has drifted away from the model’s behavior during an evaluation or assessment made by an enterprise to move the workload into production.
Why: Resource starvation and aggressive re-serving
We can’t see inside Anthropic’s serving stack, so what follows is informed inference, not confirmed mechanism. But the Opus-only signature points strongly in one direction: when a new flagship launches, the cheapest capacity to reclaim is the outgoing flagship’s, and the outgoing model gets re-served more aggressively on less (or different) hardware.
Opus is the largest, most accelerator-hungry model in Anthropic’s lineup. A new Opus arrives with an enormous appetite for top-tier GPUs. Where does that capacity come from on day one? The most convenient source is the previous Opus generations — shrink their fleet, repack them onto fewer or older accelerators, and turn on every trick that lets you fit a huge model into a smaller footprint.
There are a variety of methods that Anthropic can use to reduce the compute footprint for a model like Opus:
Quantization / reduced precision. Dropping to a lower-precision serving format is a standard way to reclaim memory and throughput.
Heterogeneous hardware and cross-fleet routing. Under a capacity crunch, requests to the old model get spread across mixed GPU generations and regions. Different kernels and different floating-point reduction orders produce numerically different logits. On a shallow model this washes out; across dozens of transformer layers it accumulates into visibly different outputs.
Aggressive dynamic batching. Packing more requests per batch to raise utilization changes reduction order and, depending on the kernel, the numerics of attention and matmuls. More batching pressure → more run-to-run variance.
Speculative decoding and KV-cache tricks. Throughput hacks that are meant to be output-neutral are only approximately so in practice, and the approximation error shows up as exactly the kind of consistency drift a stability probe detects.
Large models are sensitive to these techniques and they can and do change the behavior of the model from one serving paradigm to another. None of these change the model’s identity. All of them change their behavior at the token level. And critically, none of them are visible to the customer. Tokens are still being generated (uptime) and at reasoning latency & throughput. But each token is different than before.
As the compute setup changes, it would require any application (pinned to the older model) to reassess their workloads under these conditions to assess the impact on behavior and consistency.
How much can you trust the model when it’s running on less compute?
The honest answer from the data is: meaningfully less, for a window of weeks after each flagship launch. Concretely, a 20–36% drop in output consistency means:
Determinism you validated at qualification time no longer holds. Golden-output tests, snapshot tests, and answer-diffing start flaking.
Structured outputs degrade fastest. JSON/schema adherence, tool-call argument stability, extracted fields, classification labels is where inconsistency turns into real failures. The model call looks fine; the pipeline three steps later breaks.
Your defensive costs go up. Retry loops, self-consistency sampling, stricter validators all raise token spend and tail latency during precisely the weeks stability is lowest.
“Pin the version” is not a behavior guarantee. A version pin freezes weights and the API surface; it does not freeze the serving configuration or hardware. Reproducibility is what quietly erodes during a launch window.
What we’d tell a team building on these endpoints
Treat every new-flagship launch as a 2–6 week risk window for any older model you depend on.
Monitor output consistency, not just uptime and latency. This failure mode is invisible to standard availability SLAs; it only shows up in output-variance metrics.
Push for behavioral commitments, not just availability commitments, if deterministic behavior on a pinned version is contractually important to you.
Note on Fable 5
We left out findings related to Fable 5 as its release was not as smooth as the others. Fable was initially released on June 9th, 2026 and then removed due to its being placed on export control list by the US Government. It was then re-released on July 1st, 2026 with more guardrails and downgrading to Opus 4.8 at the model’s discretion. The serving complexity here is much more complex and requires more internal information about the serving configuration which are not accessible or verifiable.