Opus 4.7 hasn't reached the quality level of 4.6 yet — our recommendations
Anthropic openly post-mortemed the April quality issues in Claude Code and named three causes — reasoning effort, a caching bug, and an overly strict length instruction. We summarized the post-mortem in a separate news piece. This post goes one step further: what do we see in our daily use of Opus 4.7 itself, beyond the three acknowledged bugs — and how do we push back?
Background
The factual post-mortem from Anthropic is summarized here: → Anthropic explains: Why Claude Code performed worse for weeks
Observation 1: Token appetite since Opus 4.7
When Opus 4.7 first rolled out, token usage per session jumped noticeably. The model produced much longer unsolicited explanations than Opus 4.6 — often precisely where a one-liner would have done. That hits the usage budget twice: long outputs on top of an already pricier model.
The open question: was the verbosity a pure training quirk of Opus 4.7 — or a deliberate or accidental lever to push more output tokens? The ≤100-word rule that Anthropic later added to the system prompt reads exactly like an emergency brake for that. Not provable, but the pattern fits.
Same price, more tokens — the hidden cost lever
On paper, Opus 4.6 and 4.7 cost exactly the same: $5 / MTok input, $25 / MTok output. But: Opus 4.7 ships with a new tokenizer that produces up to 35% more tokens from the same text. Concretely: a request that cost $0.10 under 4.6 can cost up to $0.135 under 4.7 — without changing the prompt at all. Code and structured data are hit hardest. If you know this, you can act on it; if you don’t, you’ll just wonder why your usage limits drain faster.
Observation 2: Opus 4.7 overachieves — and it slows you down
A second pattern keeps repeating since the switch to Opus 4.7: the model makes things noticeably more complicated than they need to be. Opus 4.6 used to nail the sweet spot — enough depth without overshooting, and in the vast majority of cases the proposed solution simply fit. Opus 4.7 tips strongly the other way: more clarifying questions, more “let’s also consider X and Y first”, more upfront overhead than the task actually warrants.
The frustrating part is the loop: you want a small change, the model turns it into a full-scale operation, you dig in and challenge the approach — and in three out of four cases the response amounts to “you’re right, this can be done much more simply.” Translation: the initial proposal was oversized from the start. You now have to push back constantly, otherwise you lose your flow.
Important: this happens without any change to CLAUDE.md, without new memory entries, without different configuration — it’s purely the model. Opus 4.7 reads as if it were trained to be even more perfect than the task requires. And exactly that overachieving costs time, tokens, and patience.
Our take
After several weeks of daily use: this is a regression. Anyone who wants to just get on with it has to constantly brake, question, and simplify on 4.7 — none of that was necessary on 4.6.
Honestly: we’re not called BoostN by accident — this is about performance, pace, fast and focused delivery. That is exactly the direction Opus 4.7 is not moving in right now. We haven’t yet found a reliable lever that consistently breaks the model out of its overachieving pattern — the recommendations below help, but they don’t fix the underlying behavior.
How to push back
The good news: this is fixable on the user side.
Recommendations for leaner Claude responses
A few knobs that pay off in practice:
- Set a memory entry: “Answer as concisely as possible. No prose, prefer bullet points. Cap responses at max X words.”
- Explicit escalation clause: “Long, detailed answers only when I explicitly ask for them.”
- No anticipatory explaining: “Don’t explain what you’re about to do — do it. Don’t explain what you did — the diff shows it.”
- Cap intermediate chatter: “Keep text between tool calls to one or two short sentences.”
These rules belong in CLAUDE.md (project-wide) or in user memory (global). Once configured cleanly, you feel the token appetite of future verbose models a lot less.
Quick fix: Switch back to Opus 4.6
If you’re fed up with Opus 4.7, a single line brings back the proven Opus 4.6 in your editor. In the global Claude Code settings file ~/.claude/settings.json:
{
"model": "claude-opus-4-6"
}
Claude Code will immediately use Opus 4.6 again — no overachieving, no new tokenizer, no verbosity. Optionally, make multiple models available for quick switching:
{
"model": "claude-opus-4-6",
"availableModels": [
"claude-opus-4-7",
"claude-opus-4-6",
"claude-sonnet-4-6"
]
}
This lets you switch models on the fly without editing the settings file again. If you also want to save tokens, set "effortLevel": "medium" — with the tradeoff that reasoning runs less deep.
Our solution: KIDOKU + Workflows
The manual approach works — but it’s effort. That’s why we automated it: through our MCP server we control AI behavior via a defined interface, not prompt-and-hope. The result: drastically fewer tokens, faster sessions, and Sonnet at Opus level — even with Opus 4.7.
All features in detail
What’s next
We’re monitoring this. As soon as Anthropic tunes the behavior of Opus 4.7, or a follow-up version returns to the sweet spot of 4.6, we’ll update this post. Until then: brake, simplify, keep it short — or let our automated workflows handle it.
Entdecke mehr
Claude Code: How to enable Fast Mode for Opus 4.6 — and what it costs
Fast Mode for Opus 4.6 is now extra-usage only. Here's how to enable it — and what it really costs you.
GlossarAider
Aider is an open-source AI pair programmer for the command line that edits code directly in the Git repository and commits every change automatically.
LexikonAI Coding Tools Compared
Cursor, Windsurf, Claude Code, GitHub Copilot, Continue.dev, Aider compared. With table and decision guide for four typical developer workflows.