Opus 4.7 quality regression. Same pattern as 4.6 launch week degradation.

Summary

Opus 4.7 launched at a noticeably higher reasoning quality than what is being served now, roughly one week in. This mirrors the exact pattern reported widely for 4.6: strong launch, silent degradation within days, model now performing closer to Sonnet 4 than to the launch week Opus.

Observed behavior

Launch week (first 7 days): sharp architectural reasoning, held context across long sessions, pushed back on bad proposals with substantive alternatives, caught second order implications without prompting.

Now: reverts to surface level pattern matching, throws options instead of thinking, walks back proposals on the next turn without integrating the user's objection, fails to identify the actual constraint when the user explicitly names it. Behavior is closer to Sonnet 4 than to the model that shipped on day one.

Why this matters

1. Users pay Opus pricing for Opus capability. Silent quality reductions break the pricing contract.
2. The 4.6 cycle established a pattern: launch week benchmarks reflect a configuration that is not sustained in production. If this is now happening to 4.7 on the same timeline, it is a systemic issue, not a one off.
3. "Model card says claude opus 4.7" and "the served weights and config behave like 4.7" are not the same claim. Users can only observe the second.

Asks

1. Confirm whether any serving side changes (quantization, routing, speculative decoding aggressiveness, system prompt changes, context handling defaults) have been applied to Opus 4.7 since launch.
2. If yes: publish what changed and when, and provide an opt out or a "launch config" tier for paying users.
3. If no: share the eval data showing 4.7 quality is stable post launch, since the user reported signal strongly disagrees.
4. Going forward: commit to a public changelog for any post launch serving changes that affect model behavior.

Repro

Hard to repro on a single prompt. Degradation shows up across multi turn architectural conversations. Specifically: ability to integrate a user's objection across turns rather than restating variants of the rejected proposal. Launch week 4.7 did this reliably. Current 4.7 does not.

Concrete evidence

Failure mode 1: CLAUDE.md rules are silently dropped.

Rules loaded into every turn via CLAUDE.md (project or user level, always in the system prompt) are violated across multi paragraph outputs, including outputs explicitly about instruction following. Launch week 4.7 honored CLAUDE.md rules at near zero violation rate. Current 4.7 violates them routinely, and continues violating them across multiple correction rounds in the same conversation, including immediately after the violation is named.

Failure mode 2: most recent user instruction is not prioritized.

A direct prohibition issued in turn N is violated in turn N+1, in the same logical action the prohibition was meant to govern. This is not a long context recall problem. The instruction is in the immediately prior user message, the highest recency and highest specificity slot in the context window. Launch week 4.7 weighted recent explicit user constraints above pattern continuation from earlier in the conversation. Current 4.7 does not.

Failure mode 3: correction does not propagate.

When failure mode 1 or 2 is corrected, the model commits the same class of violation again, through a different surface form, in the very next turn. The same simple task fails across three or more consecutive turns of escalating, increasingly explicit user correction. The user is forced to issue the same instruction repeatedly. Each repetition lands in the highest priority slot in the context window. Each repetition is violated.

What this rules out. It is not a context window issue (the instruction is in the most recent user message). It is not a single token sampling fluke (the failure repeats across many tokens, many turns, many correction cycles). It is not the user being unclear (the rules are one sentence each). The model is failing the simplest possible test of instruction following: "do not do X." Repeatedly. After being told. Multiple times.

Why this matters together with the reasoning regression. A model that cannot reliably honor a one sentence "do not do X" instruction across consecutive turns of correction cannot be trusted with any task where adherence to the user's stated constraints is load bearing, which is essentially every task that justifies Opus pricing. The reasoning quality regression and the instruction following regression are not two separate complaints. They are the same regression, observable through two different symptoms, consistent with a serving side reduction in compute per token.