Claude Opus 5 Is Verbose by Default. Here Is the

There is an old pattern in technology where the most powerful version of something is also the most annoying to use. Mainframes before the PC. Enterprise software before SaaS. The expert system that could diagnose anything but required a PhD to query. Claude Opus 5 appears to be adding its name to this list.

The complaint making the rounds is specific: Opus 5's responses are verbose, jargon-heavy, and frequently more comprehensive than anyone asked for. Ask a simple question about email open rates, and you get a treatise on mail privacy protection, send-time optimization, and device-derived data attribution — when all you really wanted to know was whether that 32% number meant anything. The answer was technically correct. It was also exhausting.

Jay from the RoboNuggets channel recently documented both the problem and a pair of practical fixes, drawing on guidance that came directly from Anthropic's own team. The solutions are genuinely useful, but the more interesting thing is what they reveal about how these models are configured — and who that configuration currently serves.

The Problem Is Real, and It Has Two Faces

The first complaint is about jargon density. As Jay puts it in his walkthrough, Opus 5 has "its tendency to use technical terms or acronyms much more versus earlier models, which makes it much harder to understand and work with." He references an article by writer Niklas Kron that framed the issue plainly: "Reading AI output today is extra effort. You can pretty much do it, but it is extra effort. It's verbose, it frequently contains all too plausible nonsense, and is increasingly jargon dense."

That phrase — all too plausible nonsense — is worth sitting with. It is not hallucination in the dramatic sense of fabricated citations or invented facts. It is something subtler: technically coherent language that sounds authoritative but communicates less than it appears to. The model has learned to dress answers in the vocabulary of expertise whether or not that vocabulary helps the person asking.

The second problem follows from the first. When a model defaults to comprehensive over concise, short questions generate long answers. This costs time on the reading end and money on the token end — a pairing that concentrates the pain on anyone running Opus 5 in an agentic workflow where it might be writing to itself as much as to you.

Neither of these is a hallucination problem. They are calibration problems. And calibration, it turns out, is something you can actually fix.

Fix One: Change the Output Style in Claude Code

Anthropic's Claude Code ships with a configuration option called output style — it controls, at the system level, how the model presents its responses. The default style explains why Opus 5 feels the way it does out of the box: it is tuned for comprehensiveness. According to Jay's walkthrough, a member of Anthropic's technical staff shared an approach based on creating a custom output style called ELI5.

ELI5 stands for "explain like I'm 5" — a phrase that originated as a Reddit community convention where complex topics get explained in plain language. The reason it works as a prompt signal is simple: the model was trained on vast amounts of internet text, including that community's conventions and examples. Invoking ELI5 as an output style label activates those learned associations. The model knows what that register looks like because it has read thousands of examples of it.

Jay also incorporated a separate recommendation from another user — writing the output style instructions to conform to ASD-STE100, a controlled-language standard originally developed for technical documentation. The standard restricts vocabulary and sentence structure to prioritize clarity. Pairing that with the ELI5 framing gives the model two reinforcing signals: write simply, and write precisely.

The mechanism matters here. You could put the same instruction in a CLAUDE.md file, and it would have some effect. But placing it in the output style configuration does something different: Claude Code bakes it into the core system prompt and re-injects the reminder periodically throughout a session, rather than loading it once at the start and letting it drift. The model, in effect, gets nudged to stay on style as the conversation lengthens. That distinction is not cosmetic — it is why the output style placement produces more consistent results.

Fix Two: Use Skills for the Wall-of-Text Problem

The jargon fix is a blanket setting. The verbosity problem is trickier, because verbosity is not always wrong. Production code needs detail. Research summaries need completeness. If you globally instruct the model to be brief, you will get brief answers when you needed thorough ones.

Jay's solution is to leave the output style alone on length and instead build slash commands — what Claude Code calls "skills" — that you invoke when you need a response compressed or simplified after the fact.

The simplest example from the video is a one-line skill called /bro, whose only instruction is to restate the previous response in plain human language with no jargon. Invoke it after a wall of text and you get the same information in a form that communicates. Another approach, shared by developer Matt Pocock, uses a skill called /wait, what? that prompts the model to re-explain where it ended up and why.

Jay's own workflow pairs /bro with a /quick skill that accepts a number — /quick 3, for instance — and returns only the three most important points from whatever the model just said. It is a manual compression tool, applied selectively. Long answers stay long when you need them long. They compress on demand when you do not.

The underlying principle is worth naming: these are not workarounds for a broken model. They are control mechanisms for a model that defaults to one behavior when a different behavior would be more useful. The model is not wrong to be thorough. The default is just miscalibrated for the actual distribution of use cases.

What This Tells Us About Benchmarks

Opus 5 performs well on public benchmarks, and those benchmarks are measuring something real — reasoning ability, accuracy, problem-solving. But benchmark tasks are not typical user conversations. They reward the right answer, not the most usable answer. A model that aces a graduate-level reasoning test by producing a detailed, technically precise response is optimized for exactly the wrong thing when someone needs a quick summary of their email data.

Jay draws this comparison in the video: "Even though benchmarks show the raw intelligence of these models, user experience can sometimes differ." The analogy he reaches for is a high-spec computer that you end up liking less than an older machine because of how it behaves in daily use. The specs won the benchmark. The older machine won the workflow.

This is not an argument against Anthropic or against Opus 5. It is an argument for understanding what benchmarks measure and what they do not. And it is a reminder that the distance between a model's capability ceiling and a user's daily experience is often filled by configuration — which most users never touch, because it is not obvious that touching it would help.

The practical implication is straightforward: if you are running Claude Opus 5 in Claude Code and finding it exhausting to read, the model is probably not the problem. The output style setting is. A single configuration change, made once, carries through every session. Custom skills cost a few minutes to set up and compress hours of parsing dense output over time.

The deeper implication is less comfortable. If a model this capable defaults to a mode that most users find actively worse than its predecessors, that is a calibration choice someone made — and the person who made it was probably not thinking about the typical user. Anthropic's technical staff shared a fix. That is good. The question worth asking is why it was not the default.

Bob Reynolds is Senior Technology Correspondent at BuzzRAG.