Opus 4.7 hasn't reached the quality level of 4.6 yet — our recommendations

Redaktion · · 5 Min. Lesezeit

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?

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.

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.

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