Ask HN: Why are Claude models so verbose? | Hacker News Reader

Ask HN: Why are Claude models so verbose?

11 pointsJacobWolf13 comments

Hello! First time poster, longtime reader. I’m a professional software engineer at a startup with about 50 engineers. My primary languages are Ruby (Rails), TypeScript (React), and Go.

Of my colleagues, I’m one of the ones who tries to keep up with new AI models on every release. When there’s a new frontier or open-weight model, I’ll give it an honest try for a few days as my main driver and report back to my colleagues.

I’m a Cursor user at work and in my side projects. My go-to models are GPT-5.6 Sol on high/xhigh for planning, GPT-5.6 Sol on low/Grok 4.6 on medium for implementation, and the occasional Claude Fable 5 for complex, harder-to-understand and implement tasks. Many of my colleagues are exclusively Claude users and use Claude Code.

I’m not the first one to observe this but I feel like any time I use Fable, Opus, or Sonnet, they are extremely verbose. They make a ton of extra code comments, they ignore instructions, and they invent solutions for things solved by language built-ins or preinstalled libraries like Active Support and es-toolkit. I don’t see this happening with any other model at the same rate.

My question are: Why do we think the Claude models do this at a seemingly higher rate? And have people found any effective means to curb this behavior?

Claude Code has output styles; one of the predefined styles is Concise [1].

    Concise: Claude leads with the result, skips preamble and narration, and
    keeps responses short by default, while doing the engineering work as
    thoroughly as in the Default style. When you ask for an explanation or
    more detail, Claude answers in full. Claude always keeps the complete
    content of error reports, security warnings, and confirmations for
    destructive actions. Requires Claude Code v2.1.237 or later.

[1]: https://code.claude.com/docs/en/output-styles

Came here to say this. Output styles help a lot in cutting down the fluff.

I've had to put hard rules into Claude - and I still have to reinforce them - not just CLAUDE.md (make sure not over 40k characters) but hooks that force a read of .md files on startup, etc. Some sessions still bend the rules along the way, but hooks help bring them back into line automatically. I don't worry too much about verbosity - so I haven't tried to curb that. I just ask "give me the short version" when needed. I let the comments happen for future session passes.

As for "things solved by X" - part of my rules includes a list of "check X first" before planning or implementation - do not reinvent what is already solved". Seems to help.

I think there are a few nuances here:

1. On the ignore instructions point: using Cursor with Claude as the underlying model is quite different from using Claude directly through Claude Code. The agent/tooling layer can have a pretty big impact on the behavior.

2. On verbosity: IMO, Claude's default writing style tends to be more verbose than GPT's. GPT models are generally more concise when coding, while Claude often explains more. That said, I think this can be mitigated quite a bit by how you harness the model.

3. I agree that it’s worth trying new models. The pace of AI development is so fast that models can change significantly in a short time. But I’d also suggest trying different agent tools rather than sticking with Cursor alone. The tooling and agent loop can make a big difference too.

I churned off of Cursor for about a year to use Claude Code from spring 2025 to spring 2026 and I noticed it’d regularly ignore CLAUDE.md & Claude rules. It’s part of why I came back to Cursor. The Cursor harness has produced more reliable results, but the excessive verbosity is still pretty common across harnesses, in my experience.

One of the things I struggled with for a while was diffing the configs between tools when switching over and keeping them all straight. I recently built a free directory I’ve been hacking on to continually diff coding agents docs and source code to illustrate the differences.

Happy to share if you think it’ll add value.

Consider that verbosity on Token Generation is negligible with respect to the tokens consumed for the prompt and the context, so I think it is just a writing style than can be appreciated or not (to me it is not so bad).

We can control it (claude.md and plus use 'rules') but, it would be better if not verbose before I set it. yeah

IMO: The extra code comments always help further to understand the context and perform quickly the debugging when needed.

I've been messing around with output styles for a bit to try and reduce the madness that is opus 5's extremely disorganized and verbose output. I haven't had a lot of success, but they did just release their own concise style so I'm trying that out now. I'm hoping they figured this out because it's really degrading the experience and usability.

Because models that chat to themselves generate more tokens, hence more money is spent.

Easy

That's an over-simplification though, because models that waste tokens will lose users. Efficiency is a great marketing feature.

Why would LLMs be concise and to the point? There is no truth in these machines.

p.s. You've just discovered a load bearing seam with your dossier and have a right to push back on this.

Reply on news.ycombinator.com