A longtime user says Claude Code and Opus 5 lost their focus

A blogger recounts how he gradually became an Anthropic user: after hosting his own generative AI interface and switching models through OpenRouter, he noticed Anthropic's models consistently gave more concise answers than comparable OpenAI models and drifted toward Sonnet. When he needed to summarize a book, Gemini Pro spun for a few minutes and produced something short; the same task in Opus took three to four minutes and delivered exactly what he wanted. Around the same time he adopted Claude Code, preferring it over Aider, Cursor and Copilot because it worked the way he would himself, grepping the repo for relevant files and reading them as it went. He still uses Claude Code daily through an employer-provided enterprise subscription and calls it a real productivity boost. But he says the tool now increasingly feels like something he has to fight, and that it has become far less focused, especially with the arrival of Claude Opus 5. He cites several unnamed people voicing the same complaint that Opus 5 is lazy, sloppy and verbose, and a ranking attributed to '@theo' that places Opus below gpt-5.6-sol, luna, kimi k3 and deepseek v4 flash. He traces the bloat to three sources. First, the model itself: Opus 5 is extremely chatty and hard to keep on task, which he believes is why Anthropic released its Concise Output Style, though he thinks the lack of focus predates Opus 5. Second, the tooling: he says the Claude Code /doctor command used to simply run through setup and confirm everything worked, and has since been turned into an audit of all prompts and systems, which he calls a surface-level fix for a systemic problem, alongside what he describes as an ever-growing pile of skills, MCPs and CLAUDE.md files. Third, the marketing: he points to Anthropic's AI-native SDLC Playbook, which he says he had to run through an AI model to make sense of, and which, as he understands it, advocates for a world where the kind of full-codebase audit /doctor now performs happens daily. He argues that removing friction from turning ideas into code makes it easier to introduce bloat, and that as code generation gets cheaper, each feature needs more scrutiny before shipping, not less. He closes by urging Anthropic to get back to basics and offers a five-question framework he uses to keep bloat in check: whether a feature should exist at all, whether it is needed now or can wait, what the minimum scope to ship it is, whether there is an easier way to build it, and whether it should be built at all rather than handled by someone or something else.

Key facts

  • The author switched to Anthropic's models after noticing through OpenRouter that they gave more concise answers than comparable OpenAI models, and found Opus took three to four minutes to produce a book summary he was happy with, versus a shorter, less satisfying result from Gemini Pro.
  • He adopted Claude Code over Aider, Cursor and Copilot because it explored a codebase by grepping and reading files the way he would, and he still uses it daily through an employer-provided enterprise subscription.
  • He says Opus 5 has become chatty and prone to unrequested over-engineering, citing Anthropic's own Concise Output Style as evidence the company is trying to rein it in, and a ranking attributed to '@theo' placing Opus below gpt-5.6-sol, luna, kimi k3 and deepseek v4 flash.
  • He points to Claude Code's /doctor command, which he says used to just confirm setup worked and now audits all prompts, skills, MCPs and CLAUDE.md files, as an example of tooling bloat.
  • He proposes his own five-question framework, covering whether a feature should exist, whether it is needed now, its minimum scope, simpler alternatives, and who should build it, as a way to keep bloat in check.

Why it matters

The post captures a sentiment among long-time Claude Code users that the tool, and the Opus 5 model behind it, have grown less focused as Anthropic ships features quickly. The author treats Anthropic's own Concise Output Style, released to curb Opus 5's verbosity, as evidence the company already recognizes the problem. The piece frames verbosity and feature sprawl, rather than raw capability, as the risk worth watching in fast-moving agentic coding tools.

Who it affects

Developers and enterprises running Claude Code day to day, including the author, who uses it through an employer-provided enterprise subscription. It also concerns anyone weighing Claude against rivals: the author cites a ranking, attributed to '@theo', that places Opus below gpt-5.6-sol, luna, kimi k3 and deepseek v4 flash.

How to use it

There is no product change or pricing to act on here. The author offers a five-question framework for anyone building features to fight bloat: whether a feature should exist at all, whether it is needed now or can wait, what the minimum viable scope is, whether there is a simpler way to build it, and whether the team should build it at all rather than hand it to another group or tool. He also points to Anthropic's existing Concise Output Style as a way to curb Opus 5's verbosity today.

How solid is it

This is one user's opinion piece, published on his own blog and cross-posted to Hacker News, not a study or survey. Its supporting evidence is largely anecdotal: unnamed quotes from other people making similar complaints, and a ranking attributed to '@theo' given without methodology, scores or a link. The author also says he ran Anthropic's AI-native SDLC Playbook through an AI model to understand it and is not certain he read it correctly. The piece includes no response from Anthropic.

Risks and caveats

The argument rests on the author's own perception and secondhand, unnamed quotes rather than measured data; the Gemini-versus-Opus timing comparison is a single anecdotal case. His description of the AI-native SDLC Playbook is an admitted paraphrase, not a direct quotation, so it may not accurately represent what Anthropic actually proposed.

“You are not going crazy, Opus 5 does write really differently to other Opuses”

— unnamed commenter cited by the author