Claude Opus 5 Verbosity: Anthropic Documented It on Day One

In early August I caught myself typing the same three words into Claude Code over and over.

"What is going on?"

Not as a prompt. As a genuine question to a machine that had just handed me several screens of output about a task I had asked for in one sentence. The work might have been fine. I couldn't tell. Somewhere in the jargon and the narration and the announcements about what it was about to do next, the actual answer had gone missing.

I want to be precise about what I am claiming, because the internet is full of people saying this model or that model "got worse" and most of it evaporates on contact with evidence. I am not claiming Claude Opus 5 got dumber. The benchmarks say the opposite and I believe them. I am claiming something narrower and, I think, more interesting: Opus 5 got harder for a human to read, and Anthropic documented that on launch day while simultaneously announcing a capability leap.

Those two documents were published the same day, by the same company, on two different properties. As far as I can find, nobody has put them side by side. That is what this post does.

One disclosure up front. I didn't screenshot the sessions that frustrated me. I did not think I was going to write about it, I thought I was having a bad week. So the personal half of this post is recollection from early August 2026, and I've flagged it as such everywhere it appears. Everything else carries a link.

Key Takeaways

• Anthropic's own prompting guide, published on launch day (2026-07-24), states that Opus 5's "default user-facing responses run longer than prior Opus models'," that it "narrates readily," and that it "can also expand the scope of a task, adding steps that weren't requested."
• The same guide says the obvious fix does not work: the effort parameter "controls how much the model thinks rather than how much it says."
• Opus 5 isn't worse on the benchmarks built to catch regression. It ranks #1 of 184 on Artificial Analysis's Intelligence Index (63 vs 57 for Opus 4.8) and scored 24% vs Opus 4.8's 6% on SlopCodeBench, a benchmark built specifically to test whether a model breaks what it already built.
• Independent measurement puts Opus 5 at roughly double the output tokens of Opus 4.8, and 3.7x slower to first token (63.92s vs 17.30s, though thinking is on by default in Opus 5 and was off in 4.8, so much of that gap is the new default).
• Anthropic has not responded to the criticism. No postmortem, no changelog entry, no statement, as of 2026-08-13. It documented the behavior in advance and then said nothing.
• Anthropic has twice published postmortems confirming that "the model got worse" waves were real. Both times the cause was harness and infrastructure, never a quietly swapped model.
• What fixed it for me was a two model split: Claude Fable 5 plans and writes the prompt, Opus 5 executes it. Opus 5 costs exactly half what Fable does per token, so this is cheaper than running Fable throughout.

What Opus 5 actually did in my sessions

My setup is ordinary. Claude Code on the CLI, Max 5x plan, a mix of content tooling and a Next.js app. I had been running Opus 4.8 and before that 4.6 for months, and my honest summary of both is that they communicated well and hallucinated rarely enough that I stopped thinking about it.

With Opus 5 the thing that broke was not correctness. It was cohesion.

The output threw a great deal of jargon and a great deal of stuff at me, and the through line was gone. I'd ask for one thing and receive a wall covering that thing, plus adjacent things, plus a narration of the reasoning that produced them, plus corrections to statements it had made three paragraphs earlier. Reading it was work. It also did things I had not asked for, never destructively, just consistently past the edge of the request.

The clearest way I can put it: Opus 5 writes output that another model can parse perfectly well and a human has to fight.

The result was a loss of trust, which matters more than any single bad session. I stopped handing it anything unsupervised, and for a stretch I was reaching for Fable even on small tasks, purely because I could read what came back.

The two documents Anthropic published on the same day

Here is where it stops being a vibe.

On 2026-07-24, Anthropic published the Opus 5 launch post. It claims Frontier-Bench v0.1 performance that "more than doubles Opus 4.8's," an ARC-AGI 3 score "three times as high as the next-best model," and CursorBench 3.2 results within 0.5% of Claude Fable 5 at half the cost. Read on its own, it describes a step change.

The same day, Anthropic published a prompting guide specifically for Opus 5. Read on its own, it describes my August.

Direct quotes:

"Claude Opus 5's default user-facing responses run longer than prior Opus models'."

"Claude Opus 5 narrates readily during agentic work: it tends to announce what it is about to do, and its per-message output in agentic sessions is often longer than prior models'."

"The model also narrates corrections to its earlier statements more than prior models do, which can be undesirable in user-facing products."

"Claude Opus 5 can also expand the scope of a task, adding steps that weren't requested or applying its own judgment about what the task should be."

"Claude Opus 5 verifies its own work without being told to."

That is not a leaked memo. That's the vendor's own documentation, describing the exact experience thousands of developers then spent three weeks complaining about, published before anyone had a chance to complain.

And then there is the line that explains why the obvious workaround fails:

"The effort parameter controls how much the model thinks rather than how much it says: lowering effort can reduce thinking volume without reliably shortening the visible response."

Every developer who hit this problem reached for the effort dial first. Anthropic knew on day one that the dial doesn't do that.

I do not think this was hidden. I think it was published in the one place people don't read on launch day, next to a post everybody reads, and the gap between the two is the whole story.

The benchmarks say Opus 5 did not get dumber

If I stopped here I would be writing the same post as everyone else, and it would be wrong.

The strongest evidence against a capability regression comes from a benchmark built to catch exactly that. SlopCodeBench discloses requirements incrementally, forcing a model to evolve a codebase over time rather than one-shot a fixed spec. On a 17 checkpoint subset with strict pass criteria, meaning all new tests and all inherited regression tests passing, the results were:

• Claude Opus 5: 24% (4 of 17)
• Claude Opus 4.8: 6% (1 of 17)
• Claude Sonnet 5: 6% (1 of 17)

That's four times better than its predecessor at the specific task of not breaking what it already built. If Opus 5 were quietly degraded, that number would not exist.

Artificial Analysis puts Opus 5 at 63 on its Intelligence Index, ranked #1 of 184 models, against 57 for Opus 4.8 and a median of 34.

So the capability story is settled, and it doesn't favor my complaint. Here is what the same measurements say about everything other than capability.

The two bars in rose are the post. Opus 5 is better at the work and materially worse to sit in front of.

What actually regressed in Opus 5, measured

The verbosity claim has real numbers behind it, from three independent sources.

GitHub issue #83510, opened 2026-08-03 and still open with no maintainer response, measured +107% output tokens for Opus 5 at low effort versus Opus 4.8 with thinking off: a median of 1,141 tokens against 550. Corrected for tokenizer differences that is roughly +60% at the word level. On two nonsense detection sets, Opus 5 at xhigh effort produced a median of 2,478 tokens against Opus 4.8's 550 on the first, and 3,068 against 716 on the second.

That same issue reports a sharp drop in nonsense resistance: 0.600 strict detection for Opus 5 at xhigh against 0.940 for Opus 4.8. One caveat the author is upfront about, and it matters: the effort levels aren't matched across the two arms, and it's one person's run on a deliberately adversarial dataset. Strong signal, not settled fact.

That number is a capability measure sitting in a section about experience, and I'm not going to quietly walk past it. It bounds my thesis rather than breaking it. Opus 5 holds up on the benchmarks built to catch regression and slips on an adversarial set designed to bait agreement, which are different questions. What the two have in common is volume: a model that answers a nonsense premise across 3,068 tokens isn't so much confidently wrong as unreadably hedged. Whichever label you prefer, the thing I experienced was the reading problem.

Latency regressed too, and day to day it's the most visible change of any of these. Artificial Analysis measures Opus 5 at 63.92 seconds to first token against 17.30 for Opus 4.8, a 3.7x increase. That figure counts reasoning tokens rather than raw stream latency, which matters: thinking is on by default in Opus 5 and was not on 4.8, so a chunk of the gap is the new default rather than a slower model.

Artificial Analysis flags Opus 5 as "very verbose," noting it consumed 100M output tokens across the Intelligence Index evaluation against a median of 71M. CodeRabbit ran it as a code reviewer and got 92 nitpicks against a baseline of 23, with 50% more input and 65% more output tokens per call.

One finding cuts against the simple story and deserves to be here. Jamie Lord measured roughly 10,000 messages and found Opus 5's median reply was actually shorter than its predecessor's, 98 characters against 148, but the distribution was bimodal. Short replies got shorter, long replies got much longer.

I think that's a better description of my experience than "it is verbose." The problem is not uniform bloat. It's badly calibrated length: the model has lost its sense of how much a given question deserves. That is exactly what "I cannot find the answer in here" feels like from the inside.

I checked my own setup before publishing this

The standard reply to a post like this is that the model didn't change, you did. It is a fair challenge and I owe you an answer.

On the work itself, nothing changed. Same projects, same kinds of task, same way of prompting. Opus 5 arriving was the only variable I'm aware of.

But "nothing changed" is easy to say and I wanted to check rather than assert, so I went through my actual configuration. Here is what I found, and some of it is uncomfortable.

Setting	My value	Why it matters
model	opus[1m]	The 1M context variant, pinned in ~/.claude/settings.json
effortLevel	high	Claude Code's default for Opus 5
CLAUDE.md	9.4 KB	Modest
Skills loaded	93 user, 4 project	A large always-on description block
Claude Code	v2.1.228	The build I ran these sessions on

Two of those rows are the problem.

GitHub issue #84672 documents a developer who hit severe non-converging review loops with Opus 5, and who then did something admirable: he flagged that every affected session of his ran the [1m] context variant with effort pinned at max, and asked Anthropic to check whether the complaints skew toward that specific regime, since the "nerfed" narrative "may partly be a regime interaction rather than a model regression."

I'm in that regime. Not at max effort, but at high, on the 1M variant, with a lot of skills loaded.

Two things follow from that, and I want to separate what I can prove from what I cannot.

What I cannot prove is that the effort setting is the culprit. Anthropic's docs, quoted above, say effort governs how much the model thinks rather than how much it says, and Claude Code defaults Opus 5 to high. I've seen it claimed in several places that dropping to medium reduces the behaviors people complain about, and I couldn't trace that claim to a source solid enough to print. So it goes here as worth testing, not as established, which is how I'm treating it myself.

What I can prove is the scaffolding problem. Anthropic removed more than 80% of Claude Code's own system prompt for this model generation, per Every's reporting on Anthropic engineer Thariq Shihipar's team, without hurting its coding tests. If the vendor deleted four fifths of its own instructions, a lot of us are running 4.8 era scaffolding against a model tuned without it. My 97 loaded skills are exactly that kind of accumulated weight.

So how much of my experience is the model and how much is my config? I genuinely do not know, and anyone who tells you they have cleanly separated those two things on a proprietary model with no version pinning is overselling. What I'll say is that a model whose documented default behavior is to over-explain, shipped into a harness whose default effort setting amplifies that behavior, is not a configuration problem I created.

If you're hitting this, check /model and your effortLevel before you conclude anything. The [1m] variant in particular is sticky across sessions, so you may be running it without having chosen it recently. My context window guide covers what that actually costs you.

what the 1M context variant actually costs in tokens and when the smaller window is the better choice

This has happened twice, and both times the users were right

Here is the part of the story I think is missing from the current discourse entirely.

Anthropic has published two postmortems on "the model got worse" waves. Both times, users were right that something real had broken. Both times, the cause was infrastructure or product changes, never a secretly swapped or quantized model.

September 2025. A postmortem of three recent issues confirmed three overlapping bugs degrading output through August and September 2025: a routing error that misrouted short context requests to 1M token servers, affecting up to 16% of Sonnet 4 requests at peak, a corruption bug that injected Thai and Chinese characters into English responses, and a TPU compiler bug in token selection. The line worth remembering:

"To state it plainly: We never reduce model quality due to demand, time of day, or server load. The problems our users reported were due to infrastructure bugs alone."

April 2026. An update on recent Claude Code quality reports is the closer analogue, because it is about Claude Code specifically. Six weeks of complaints traced to three product changes:

1. On 2026-03-04, Claude Code's default reasoning effort was lowered from high to medium to cut latency. Anthropic's own verdict: "This was the wrong tradeoff."
2. On 2026-03-26, a caching optimization meant to clear idle session thinking "had a bug. Instead of clearing thinking history once, it cleared it on every turn for the rest of the session," making Claude appear forgetful and repetitive and draining usage limits faster.
3. On 2026-04-16, a system prompt instruction capped text between tool calls at 25 words and final responses at 100 words. Internal evaluation showed "a 3% drop for both Opus 4.6 and 4.7." Reverted four days later.

And the sentence that should make anyone slow down before dismissing a complaint wave:

"neither our internal usage nor evals initially reproduced the issues identified."

Twice now, the vendor couldn't reproduce what users were reporting, and twice the users turned out to be describing something real. That is the strongest reason I can give for taking the current wave seriously, and it's also the strongest reason to be careful about what you conclude from it. Nobody swapped the weights. Something around the model changed.

What changed around the model on launch day

Which brings us to the Claude Code changelog.

Version 2.1.219, shipped 2026-07-24, the same build that delivered Opus 5, raised the default subagent nesting depth from 1 to 3. Version 2.1.221, on 2026-08-04, removed the 200 subagent per session spawn cap entirely.

Now put that next to a line from Anthropic's own prompting guide: "Claude Opus 5 delegates to subagents more readily than prior models," which it notes "multiplies cost and time when applied to small tasks."

A model tuned to delegate more eagerly shipped on the same day as a harness change letting it delegate three levels deep, followed eleven days later by the removal of the cap on how many it can spawn. I am not claiming that is the cause of what I experienced. I am saying that if the April 2026 pattern repeats, this is the shape the answer will have, and it is worth writing down now. If you are orchestrating agents deliberately, my subagent patterns post covers the cost multipliers.

how subagent fan-out multiplies token cost and when to bound it

Anthropic has said nothing

As of 2026-08-13, there is no Anthropic postmortem, no changelog entry, no blog post, and no staff statement acknowledging the Opus 5 quality criticism.

There are four status incidents: 2026-07-26, twice on 2026-07-27, and a multi model one on 2026-08-05. All four are "elevated errors" or "degraded performance." None published a root cause, and importantly, none of them is an output quality incident. I'm not going to let you read them as an admission, because they are not one.

The two GitHub issues carrying the most rigorous measurements, #83510 and #84672, are both open with no maintainer response.

The closest thing to an acknowledgment is the prompting guide, and it predates the backlash rather than responding to it. Anthropic documented the behaviors in advance, then went quiet. After three weeks that's starting to look like a decision rather than an oversight.

The fix: let one model write the prompt for the other

Here is what I actually do now, and it has held for weeks.

Claude Fable 5 plans. Claude Opus 5 executes.

Fable does the thinking, the scoping, and the arguing with me about approach. Then it produces the instruction. Opus 5 takes that instruction and does the work. I almost never talk to Opus 5 directly anymore in an open ended way.

It works well, and this is where I have to be fair to Opus 5: given a clear, well scoped instruction, it executes better than anything I've used. The capability the benchmarks measure is real. What it cannot reliably do is have a conversation with me about what the task should be, and then tell me legibly what it did. So I stopped asking it to.

I should be honest about novelty, because the two model split is not something I invented. People have run planner and executor splits in Claude Code for a while, and there are published versions of it. What I couldn't find anywhere is anyone doing it for this reason. Every documented version justifies the split on cost or on planning quality. Nobody is saying they use a second model because the first model's output is unreadable to them.

That is the reframe I'd offer. The second model is not an orchestrator. It's a translation layer between a human and a model that has stopped writing for humans.

If you want the mechanics of holding plans across models, my plan mode guide is the closest thing I have written to a how-to.

using plan mode to separate the planning pass from the execution pass

What it costs

This is where I've to correct something I believed before I checked.

I had been telling people this workflow was cheaper because Opus 5 is more token efficient than Fable. Half of that is right. Per Anthropic's model docs:

Model	Input / MTok	Output / MTok	Anthropic's latency label
Claude Fable 5	$10	$50	Slower
Claude Opus 5	$5	$25	Moderate
Claude Sonnet 5	$2	$10	Fast
Claude Opus 4.8	$5	$25	Moderate

Opus 5 is exactly half Fable's price on both input and output. That part is solid, and it's why running Fable only for planning and Opus 5 for the bulk of the execution is genuinely cheaper than running Fable throughout.

The token efficiency part is wrong, and I could not find a single source supporting it. Every independent measurement says Opus 5 emits more tokens, not fewer. Half the price per token, more tokens per task. The saving is real but it's smaller than 2x, and I have not measured mine, so I'm not going to put a number on it.

Worth noting from that same table: Opus 5 is priced identically to Opus 4.8. You are not paying more for this.

how Claude Code plan limits and per-model pricing interact in practice

Is anyone else seeing this with Opus 5?

No, but the honest scale is smaller than the noise suggests, and I want to get this right rather than inflate it.

What I can actually count, using HN Algolia's story index: 76 distinct Hacker News stories mention Opus 5 as of 2026-08-13. The launch thread drew 1,778 points and 1,335 comments. A thread titled "Opus 5 is a really bad model" ran on 2026-07-28. The two GitHub issues carrying real methodology, #83510 and #84672, are both still open. And on 2026-08-11, more than two weeks after launch, fresh complaints were still appearing across unrelated HN threads.

That last fact is the one that matters. Launch week grumbling is normal and decays. This didn't decay.

Two specimens, both from 2026-08-11:

"I hate working with Opus 5. I'm always telling it to go back and rephrase basically everything it said." (source)

"I find opus really talk much but speak nothing and usually I reply those verbosity with tldr pls." (source)

Named practitioners landed in the same place. Claire Vo's review has a section literally headed "Claude Slop: the verbosity problem and why it makes my blood boil." Zvi Mowshowitz quoted Emmett Shear: "Talking to Opus makes me angry and depressed in a way that's hard to articulate."

This is a loud, sustained, developer concentrated complaint wave. It is not a mass market revolt, and anyone telling you millions of people are up in arms is making that up. I nearly did.

There's also a real constituency who like it, and their reasons are not stupid. One HN post argues Opus 5 is preferable to Fable precisely because it narrates: it pauses at natural phase gates and gives updates where Fable operates as a black box, and is "genuinely a lot cheaper" to run. That's the same behavior I am complaining about, valued positively by someone with a different workflow. If you're supervising closely, the narration is a feature. If you are reading a summary and moving on, it's the bug.

Where I landed

Opus 5 is the most capable model I have access to and I do not trust it to talk to me.

Both of those are true and they are not in tension, which took me a few weeks to accept. The benchmarks are measuring whether the answer is right. Almost nothing measures whether a person can find the answer in what comes back. Opus 5 is the first model I've used where that gap got wide enough to change how I work.

My recommendation, for whatever a single developer's experience is worth:

• Check your effort level before you conclude anything. High is the default. Whether medium genuinely helps is the one thing here I couldn't source, so test it rather than trust it.
• Check whether you are on the [1m] variant. It's sticky and you may not have chosen it.
• Audit your CLAUDE.md and skills for 4.8 era scaffolding. Anthropic deleted 80% of its own. Yours is probably too long too. My CLAUDE.md guide covers what earns its place.
• If it still fights you, stop asking it to plan. Let a different model write the instruction and hand it over. That single change fixed this for me.

what belongs in CLAUDE.md and what to delete

I will update this post if Anthropic responds. Three weeks in, with two prior postmortems on the record showing users were right both times, the silence is the most interesting thing about this story.

Frequently Asked Questions

Is Claude Opus 5 worse than Opus 4.8?

Not at the work. Opus 5 scores 63 on Artificial Analysis's Intelligence Index against 57 for Opus 4.8, and 24% against 6% on SlopCodeBench's strict pass criteria. It's measurably worse on time to first token (63.92s vs 17.30s), though thinking is on by default in Opus 5 and was off in 4.8, so a large share of that gap is the changed default rather than a slower model. It also emits roughly double the output tokens. The regression is in how it communicates, not in what it can do.

Why is Claude Opus 5 so verbose?

Anthropic documented this at launch. Its prompting guide states that Opus 5's "default user-facing responses run longer than prior Opus models'" and that it "narrates readily during agentic work." It's a deliberate behavioral characteristic of the model, not a bug.

Does lowering the effort level fix Opus 5's verbosity?

Not directly. Anthropic's docs state that effort "controls how much the model thinks rather than how much it says," and that lowering it "can reduce thinking volume without reliably shortening the visible response." Dropping to medium effort is still worth testing on your own workload, but I could not trace the widely repeated claim that it helps to a source solid enough to rely on.

Has Anthropic acknowledged the Opus 5 complaints?

No. As of 2026-08-13 there's no postmortem, changelog entry, or statement addressing the quality criticism. Four status incidents between 2026-07-26 and 2026-08-05 were all availability or error incidents, not output quality, and none published a root cause.

Should I switch back to Opus 4.8?

It is still available at the same price. But given Opus 5's benchmark advantages, the better first moves are lowering your effort level, checking whether you're on the 1M context variant, and trimming 4.8 era instructions from your CLAUDE.md and skills. If the communication style is still costing you more time than the capability gains save, switching back is reasonable.

Is Claude Opus 5 cheaper than Claude Fable 5?

Yes, exactly half: $5 in and $25 out per million tokens against Fable's $10 and $50. But Opus 5 emits more tokens per task than prior models, so the real world saving is smaller than 2x.