Evaluating Opus 4.7 and Claude Code Quality Reports

Quality reports about an AI coding assistant can describe several different failures: a model’s answer, the client’s context handling, a changed system instruction, or an integration bug. Treating all of them as evidence that a model became worse makes diagnosis harder.

Opus 4.7 launched on April 16, 2026. Reports around that release deserve scrutiny, but neither a model-generated confession nor an unnormalized count of online complaints establishes a regression rate. The useful approach is to separate confirmed incidents from reproducible observations and unanswered questions.

What the April postmortem establishes

Anthropic’s April 23, 2026 postmortem identifies three changes affecting Claude Code, the Agent SDK and Cowork. Anthropic states that the API and inference layer were unaffected and that the issues were resolved by April 20 in version 2.1.116.

The first change lowered Claude Code’s default effort on March 4 and was reversed April 7; it affected Sonnet 4.6 and Opus 4.6. A separate context-clearing bug introduced March 26 was fixed April 10 and affected those same models. Both predated Opus 4.7.

A verbosity instruction shipped April 16 and was reverted April 20. That change affected Sonnet 4.6, Opus 4.6 and Opus 4.7. The report supports a client-layer quality problem with specified scope, not a claim that all three incidents were defects introduced by the new model.

User reports are leads, not denominators

A detailed issue report can be valuable evidence of a failure. It is strongest when it includes the client version, model, settings, sanitized reproduction and expected behavior. A report that cannot be reproduced still deserves investigation, but its uncertainty should remain visible.

Counts of posts, upvotes or issue labels do not estimate how often a failure occurs. They lack a denominator and can reflect changes in usage, reporting or attention. Do not convert them into a population-level model ranking.

The same applies to an anecdotal token increase or a striking erroneous response. Preserve the concrete observation where it can be supported; avoid turning one observation into a universal causal story about training, intent or deliberate degradation.

Measure costs at the task boundary

The Opus 4.7 release notes describe a tokenizer change under which the same text can use about 1.0–1.35 times as many tokens, depending on content. This is a tokenization range, not a guarantee of the same percentage change in an invoice or completed-task cost.

Record input and output tokens, caching, retries and completion quality for representative tasks. Keep client configuration fixed or record the difference. A longer answer might be useful or redundant; the relevant result is whether it satisfies the requirements and what completing the task consumed.

Reproduce the failure before choosing a remedy

Start with the smallest authorized example that still produces the problem. Remove credentials, private paths and unrelated data. Specify what correct behavior means before rerunning the agent, especially when the task allows several valid implementations.

Capture the exact client and model versions, effort setting, prompt, relevant tools and starting revision. Record whether the issue depends on resuming an old session, making a particular tool call or applying a changed system instruction.

Compare the relevant configurations without changing every variable at once. A fresh session can test a context hypothesis; a client update can test a known fixed defect. An API comparison may help isolate the host layer where tool behavior and permissions can be made comparable.

Keep raw results and distinguish observations from explanations. If the evidence only shows that configuration A failed twice on a particular task, report that result. Do not invent a mechanism or assume configuration B is reliable because it passed once.

Verification still needs external evidence

An agent can claim that tests passed, that a commit exists or that a file was changed. Check the actual test output, repository state and artifact. A natural-language summary is not execution evidence.

Hooks can enforce specific boundaries, such as requiring a successful check before a permitted action. They do not eliminate all hallucinations or guarantee the correctness of the application. Validate the hook itself and describe exactly what it checks.

A fresh reviewer can find additional defects, but correlated errors remain possible. Supply complete authorized evidence and independently verify material findings. Self-verification and model agreement are useful signals only within those limits.

Choose a scoped operational response

For a confirmed defect, use the documented fix and verify it against the reproduction. For an unresolved workflow regression, retain a working configuration or a rollback path while gathering evidence. Select model and effort settings explicitly rather than assuming lower cost means better overall value.

The professional standard is a traceable diagnosis: what failed, under which conditions, what changed, and what evidence supports the remedy. That is more useful than asking a model to narrate its own shortcomings.