Opus Isn't Dumber. The Harness Was Broken

For the past few weeks, the public story around Claude Code has been simple: Opus got worse.

That story turns out to be wrong.

Anthropic’s April 23 postmortem says the models themselves did not regress, and the Claude API was not affected.¹² The failures were in the product layer around the model: Claude Code, the Agent SDK harness, and Cowork because it runs on that SDK.² In other words, the thing that felt worse was real. The place people pinned it was not.

That distinction matters way beyond Anthropic.

If you build agent products, coding tools, wrappers, SDKs, or orchestration layers, this is one of the clearest recent examples of a truth a lot of teams still do not fully respect: users do not experience the model in isolation. They experience the harness. They experience the defaults. They experience the session logic. They experience the wrapper prompt you thought was harmless.

And when that layer slips, the model takes the blame.

What Actually Broke

Anthropic identified three separate issues.

1. Claude Code’s default reasoning effort got downgraded

On March 4, Anthropic changed Claude Code’s default reasoning effort from high to medium to reduce the long tail of thinking latency that was making the UI feel frozen for some users.¹

I get why they did it. A coding tool that looks hung is a support problem waiting to happen.

But Anthropic later admitted it was the wrong tradeoff. Users would rather take the extra latency and get the smarter default than quietly lose capability and have to discover the fix themselves. Anthropic reverted that change on April 7.¹

This is the first lesson. A model can be identical underneath and still feel materially worse if the product quietly changes how much thinking it gets by default.

That is not a model regression. It is still a quality regression.

2. A session-state optimization made Claude look forgetful

This one is nastier.

On March 26, Anthropic shipped an optimization meant to reduce resume cost for sessions that had been idle for over an hour. The intended behavior was straightforward: if an old session comes back cold and the cache is gone anyway, clear old thinking once, resume the session, and keep going.¹

Instead, a bug kept clearing prior reasoning on every later turn for the rest of that session process.¹

That is how you get a tool that suddenly feels forgetful, repetitive, and weirdly inconsistent. The model keeps moving, but it is doing so with less memory of why it was making previous edits and tool calls. Anthropic says this also likely contributed to reports of usage limits draining faster than expected because the broken behavior kept causing cache misses.¹

If you have ever used an agent and thought, “Why is this thing re-litigating decisions it already made twenty minutes ago,” this is exactly the class of failure you should care about.

It was fixed on April 10 in v2.1.101.¹

3. A prompt change meant to reduce verbosity hurt coding quality

This is my favorite part of the postmortem because it is such a perfect own-goal.

On April 16, Anthropic added a system prompt instruction that said:

“Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”¹

That sounds tidy. Efficient. Product-manager clean.

It also hurt coding quality.

Anthropic says that in combination with other prompt changes, this instruction degraded performance enough that broader ablations later showed a 3% drop on one evaluation set for both Opus 4.6 and 4.7.¹ The change was reverted on April 20.¹

This is the part a lot of AI product teams still do not want to hear. Prompt-layer constraints are not presentation details. They are behavioral controls. If you clamp the wrapper too hard, you are not only making the model terser. You may be changing how well it reasons through the job.

That is especially true in coding tools, where the line between “concise” and “underexplained” gets dangerous fast.

The Important Part: Anthropic Says the Model Did Not Regress

Anthropic’s public thread after the postmortem could not have been clearer.

First: all three issues were fixed in v2.1.116+, and subscriber usage limits were reset.³

Second: the issues stemmed from Claude Code and the Agent SDK harness, which also impacted Cowork. The models themselves did not regress, and the Claude API was not affected.²

That should kill the lazy version of the story.

People were not hallucinating the quality drop. They were feeling a real product regression. But the right diagnosis is not “Opus got dumber.” The right diagnosis is that the layer around Opus got worse in three different ways.

That is a much more useful lesson.

The Comparison That Makes This Harder to Ignore

If you want a sanity check that this was a harness problem and not a raw-model collapse, look at how Opus 4.7 was performing in other coding-agent environments during the same window.

Anthropic’s Opus page quotes Cursor saying Opus 4.7 was a “meaningful jump in capabilities” on CursorBench, clearing 70% versus 58% for Opus 4.6.⁴ Cursor’s own model docs make the same point more directly: Opus 4.7 is a meaningful jump over 4.6 on CursorBench, excels at autonomous multi-step work, and is best used with the high thinking variant.⁵

That does not prove every Cursor session felt amazing. User reports are always mixed, and real product experience is messy. But it does support the central argument here: in at least one other serious coding harness, the same model family was showing stronger results, not weaker ones.

OpenCode is a softer comparison right now. I found primary-source evidence that OpenCode added support for Opus 4.7’s reasoning behavior and related session-compaction improvements, but not a quantified public claim that Opus 4.7 suddenly outperformed 4.6 inside OpenCode the way Cursor is willing to say publicly.⁶ So I would not overstate that case.

That asymmetry is useful on its own. Cursor gives us a direct comparative signal. OpenCode gives us compatibility and harness-evolution signal, but not a clean benchmark claim. Taken together, they still point in the same direction: the more careful you are about separating model quality from harness quality, the easier this whole episode is to understand.

Why This Matters for Every Agent Builder

There is a bad habit in AI product discourse where people treat the model and the product as if they are the same thing. They are not.

A user does not touch raw weights. They touch a stack.

That stack includes:

• the model
• the effort defaults
• the session and memory rules
• the system prompt
• tool routing
• retry behavior
• resume logic
• UI affordances
• cost controls
• whatever “smart” wrapper logic the product team slipped in last sprint

Any one of those can make a strong model feel weaker than it really is.

Anthropic’s postmortem is a clean example of that separation of concerns:

• one regression came from defaults
• one came from session-state handling
• one came from the prompt wrapper

None of those are the foundation model itself. All of them hit user trust.

If you are building agents and your eval story is still mostly clean one-shot prompts against direct API calls, you are missing the part that hurts people in real use.

The Wrapper Is the Product

That is the real takeaway here.

Not “Anthropic messed up,” though they did.

Not “Opus is secretly fine,” though Anthropic says it is.

The real takeaway is that the wrapper is the product.

A bad default can make a great model feel mediocre.

A broken resume path can make a smart model act like it has early-onset amnesia.

A well-intentioned prompt constraint can sand off the exact behavior that made the tool useful in the first place.

This is why I keep coming back to the same argument when people discuss model quality like it exists in a vacuum. It does not. Not once you ship.

The shipped experience is what counts.

What Teams Should Learn From This

If you run a coding agent, orchestration stack, or internal developer tool, here is the checklist this postmortem should burn into your process.

1. Track effective behavior, not model name

If your logs say “Opus 4.7” but your defaults changed from high to medium effort, you are not measuring the thing users are actually experiencing.

Model name alone is too coarse. Track effort level, prompt version, tool policy, session age, resume path, and any wrapper flags that can change behavior.

2. Test resumed sessions, not only fresh ones

Anthropic’s ugliest bug lived in the resume path.¹

That is not unusual. Long-running systems usually break at state boundaries: resume, retry, reconnect, interrupt, branch, follow-up. If your evals live only in fresh-session happy paths, you are basically testing the demo build.

3. Treat prompt changes like code changes

This should be obvious by now, but apparently it still needs saying.

If a system prompt change can cut coding quality by 3%, it belongs in the same review discipline as code. Version it. Diff it. Run ablations. Gate it. Roll it out slowly. Be ready to yank it fast.¹

4. Separate harness regressions from model regressions in your comms

Anthropic did one thing right here: once they found the issue, they said the quiet part out loud.²³

That is useful. Teams need to know whether the problem lives in the model, the API, or the product layer. Those are different blast radiuses and different remediation paths.

5. Watch for weird second-order signals

Users were not only reporting lower quality. They were reporting forgetfulness, repetition, strange tool behavior, and faster limit burn.¹

That is exactly the kind of symptom cluster that should tell you the harness is sick even if your top-line benchmark chart still looks respectable.

The Bigger Point

I do not think the value of this postmortem is that it clears Opus’s name.

I think the value is that it gives builders a cleaner mental model for where AI products fail.

The model can be fine.

The user experience can still be bad.

Both statements can be true at the same time.

That is uncomfortable because “the model got worse” is a simpler headline. Simpler, and wrong.

The harder truth is that the real product lives in the glue code, the defaults, the caching behavior, the prompt layer, and the boring session machinery almost nobody wants to write blog posts about until it catches fire.

Well, it caught fire.

And Anthropic just gave everyone building agents a very expensive reminder that the harness counts.

Bottom Line

Despite popular belief, Opus is not dumber. Anthropic says the model did not regress.²

Claude Code got worse because the harness got worse.

A downgraded reasoning default shaved off intelligence. A broken resume optimization made sessions lose prior reasoning. A wrapper prompt meant to reduce verbosity clipped coding quality.¹

That is the story.

If you build AI products, that should worry you more than a straight model regression would. Model regressions are obvious targets. Harness regressions are sneakier. They ship as product polish, latency fixes, or prompt cleanup. Then they quietly rot the experience while the model takes the blame.

That is why this postmortem matters.

Not because Anthropic stumbled.

Because this is what the next generation of AI product failures is going to look like.

---

Footnotes

1. Anthropic, “An Update on Recent Claude Code Quality Reports,” Anthropic Engineering, April 23, 2026, https://www.anthropic.com/engineering/april-23-postmortem. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴

2. ClaudeDevs (@ClaudeDevs), “The issues stemmed from Claude Code and the Agent SDK harness, which also impacted Cowork since it runs on the SDK. The models themselves didn’t regress, and the Claude API was not affected,” X, April 23, 2026, https://x.com/ClaudeDevs/status/2047371124238062069. ↩ ↩² ↩³ ↩⁴ ↩⁵

3. ClaudeDevs (@ClaudeDevs), “Over the past month, some of you reported Claude Code’s quality had slipped. We investigated, and published a post-mortem on the three issues we found. All are fixed in v2.1.116+ and we’ve reset usage limits for all subscribers,” X, April 23, 2026, https://x.com/ClaudeDevs/status/2047371123185287223. ↩ ↩²

4. Anthropic, “Claude Opus 4.7,” accessed April 23, 2026, https://www.anthropic.com/claude/opus. ↩

5. Cursor, “Claude 4.7 Opus,” Cursor Docs, accessed April 23, 2026, https://cursor.com/docs/models/claude-opus-4-7. ↩

6. OpenCode, “Changelog,” accessed April 23, 2026, https://opencode.ai/changelog. ↩