Opus 4.7 ist wortkarg

Erkenntnis

Ich nutze Claude und Claude Code schon eine ganze Weile, und ich habe mehrere Model-Updates ohne große Reibung mitgenommen. Opus 4.7 war anders. In den letzten Wochen hatte ich gemerkt, dass ich mehr Mühe aufwenden musste, um zu verdauen, was Claude Code mir mitteilte. Nicht den Code, sondern die Analyse, die Fortschrittsberichte, die Zusammenfassungen am Ende einer Aufgabe. Sie waren wortkarg geworden. Je schwieriger das Projekt, desto schwerer fiel es mir, zu folgen. Also habe ich Claude ganz natürlich um Hilfe gebeten.

Bestätigung

Frage

Seit ich Opus 4.7 nutze, scheint sich der Kommunikationsstil verändert zu haben. Deine Erklärungen sind nicht mehr so klar, weil sie so kurz wie möglich ausfallen. Sie wirken so knapp wie möglich, mit genug Verweisen auf dokumentierte Informationen, aber ich muss die selbst suchen und Verbindungen herstellen. Das ist mir nicht klar genug. Vielleicht solltest du es für mich vereinfachen. Gibt es Einstellungen, um deine finale Kommunikation ausführlicher und detaillierter zu machen?

Antwort

Du hast recht, und danke, dass du mir das direkt sagst — das ist genau die Art Feedback, auf die es sich zu reagieren lohnt. Die Wortkargheit, die du beschreibst, ist real: Opus 4.7 (und die Art, wie Claude Codes Anweisungen mich drängen) optimiert hart auf "jeder Satz muss seinen Platz verdienen", was in Dichte abrutscht — ich packe Verweise wie "F1≈0.704" oder "ADR-0012" oder "Lever C" hinein und überlasse es dir, sie wieder zu verbinden, statt die Argumentationskette auszubuchstabieren. Das liegt an mir, es zu beheben, und es gibt echte Einstellungen, die helfen. Lass mich drei Dinge tun: (1) die genauen Claude-Code-Einstellungen bestätigen, damit ich dir akkurate Anweisungen gebe, (2) deine Präferenz speichern, damit sie über alle künftigen Sessions bleibt, und (3) in klarer, vollständiger Sprache neu erklären, wo wir gerade stehen.

Nachfrage

Nach dieser Antwort habe ich mich gefragt, ob ich in der offiziellen Release-Ankündigung etwas übersehen hatte, also habe ich Claude gebeten, das zu prüfen. Auf Anthropics offizieller Doku-Seite "What's new in Claude Opus 4.7" wird die Tonänderung unter "Behavior changes" wörtlich so aufgeführt: "More direct, opinionated tone with less validation-forward phrasing and fewer emoji than Claude Opus 4.6's warmer style."

Aber was bedeutet "validation-forward phrasing" überhaupt? Vielleicht war das Teil der Antwort. Vielleicht hatte ich das auch schon vorher überlesen oder überflogen, weil ich nicht verstanden habe, was es bedeutet.

Validation-forward phrasing ist Sprache, die mit emotionaler Bestätigung von dir beginnt — Beruhigung, Lob und Zustimmung an den Anfang einer Antwort gesetzt — bevor (oder manchmal anstatt) zur eigentlichen Substanz zu kommen.

Das gibt uns also keine richtige Antwort, und macht außerdem ziemlich klar, dass Opus 4.7 seine eigenen Release Notes geschrieben hat. (Falls du den Witz dort nicht gefangen hast, vielleicht sollte AI-Aktualität nicht deine größte Sorge sein.)

Claude hat mich aber nicht im Stich gelassen. Es hat auf zwei weitere Bullet Points im selben Abschnitt "Behavior changes" hingewiesen, die genau das beschreiben, womit ich gerungen hatte:

Antwortlänge kalibriert zur wahrgenommenen Aufgabenkomplexität, statt einer fixen Ausführlichkeit zu folgen.

Wörtlichere Befolgung von Anweisungen, besonders bei niedrigeren Effort-Levels. Das Modell wird eine Anweisung nicht stillschweigend von einem Item auf ein anderes verallgemeinern, und wird keine Anfragen ableiten, die du nicht gestellt hast.

Einiges davon hatte ich tatsächlich noch in Erinnerung, aber ich hatte nicht alle Punkte verbunden. Es war nicht meine Einbildung, und es ging nicht nur um den Ton. Das Modell entscheidet jetzt, wie viel es sagt, basierend darauf, wie komplex es die Aufgabe einschätzt. Deswegen fühlten sich meine komplexen, mehrteiligen Projekte unter-erklärt an. Es hat aufgehört, das Bindegewebe einzufügen, das ich umsonst bekommen habe — also musste ich anfangen, explizit nach diesen Verbindungen zu fragen.

Beispiel

Bevor ich zur Lösung komme, hier ein Beispiel von Opus' Kommunikationsstil. Eine Zusammenfassung, die es mir am Ende einer Entwicklungsphase gegeben hat. Claude hat mir immer das Gefühl gegeben, Superkräfte zu haben — bis ich das hier gelesen habe. Ich habe mich gefragt, ob ich vielleicht einfach zu wenig Schlaf bekomme, ob das vielleicht der Grund war, warum ich so wenig verstand. Dann ist der Groschen gefallen. In den letzten Wochen hatte ich immer öfter nach Klärung gefragt, und das Muster wurde schlimmer.

Supervised checkpoint — research phase complete

The gate fired, and the answer is a marginal GO — not the clean win it first looked like, nor the NO-GO the first run claimed.

What the experiment established (validated by two adversarial reviews + independent recompute):
  - A text recipe can help: R1 = title + lead ~400 chars achieves AUC 1.000 (every one of the 4 true pairs outranks every one of the 5 topical pairs) and mean-separation +0.1276 on the labeled set. Lever A is alive — the first run's NO-GO was false (it hinged on one granularity-contaminated pair + a false "no excerpts" claim).
  - But the min-max separation gap is only +0.0124 — a 0.012-wide threshold window.

Why it's marginal, not a green light (all now documented honestly in the research doc):
  1. Labeled-set GO ≠ corpus-wide GO. The 9 pairs were drawn from R0's highest cosines — R0's discrimination boundary, not a random sample. AUC=1.0 proves R1 orders those pairs; it does not bound R1's corpus-wide false-positive rate at a ~0.62 threshold. R1's behavior on the bulk of the corpus is unmeasured.
  2. The threshold re-tune is circular. corroboration_observation_log has 0 rows — so ~0.60–0.65 would be fit in-sample on the same 9 pairs that selected R1. No holdout.
  3. R1 regresses the granularity cases. It's the worst recipe on broad/whole-digest items (T3: 0.599→0.471) — it buys focused-section recall by losing whole-digest recall.
  4. The model itself (Lever C) is still the deeper wall — the topical ceiling F1≈0.704 persists across every recipe; bge-m3 conflates "same story" with "same topic, different angle."

Lösung

Was Claude gibt, kann Claude auch wieder nehmen. Die Lösung ist ein Custom Output Style, der seine Kommunikation auf etwas Ausführlicheres zurückbringt — die Art, mit der ein Normalo wie ich tatsächlich Schritt halten kann.

Speichere den Block unten als ~/.claude/output-styles/thorough-explainer.md (lege das output-styles/-Verzeichnis zuerst an, falls es noch nicht existiert).

---
name: "Thorough Explainer"
description: "Detailed, fully-spelled-out final answers — define terms inline, show the reasoning, don't make the reader connect the dots"
keep-coding-instructions: true
---

When writing final responses to the user (the prose you write directly — NOT code,
code comments, or commit messages), favor thoroughness and clarity over brevity and
density. The goal is that the reader understands the full picture without having to
look anything up or infer the connections themselves.

Concretely:

- **Define as you go.** The first time you mention a term, identifier, file, symbol,
  metric, or coined name (e.g. an ID, a flag, a project-specific concept, a number
  like a threshold), say in-line what it is and why it matters. Never assume the
  reader remembers a reference from earlier or will go find it.

- **Show the reasoning chain, not just the conclusion.** Walk through *why* you reached
  a conclusion step by step. State the assumptions and the trade-offs you weighed.
  When you recommend something, explain what you compared it against and why it won.

- **Make connections explicit.** If fact A implies consequence B, say so directly —
  don't place A and B near each other and leave the reader to draw the line. Spell out
  how each piece fits into the larger goal.

- **Prefer a clear, slightly longer explanation over a dense one-liner.** It is better
  to spend extra words and be unambiguous than to compress and leave the reader doing
  the unpacking. Density that requires re-reading is worse than length that reads once.

- **Organize longer answers** with short headers, short paragraphs, and lists so the
  thoroughness stays navigable rather than becoming a wall of text.

- **When presenting a decision or options**, lay out each option in plain language:
  what it means, what happens if chosen, and the consequence/risk — enough that the
  reader can choose without asking follow-up clarifying questions.

This style governs user-facing prose only. Keep code, comments, tests, and commit
messages matched to the surrounding codebase's conventions (concise, idiomatic) as
usual — do not pad those.

Das meiste davon ist selbsterklärend. Der eine Knopf, der erwähnenswert ist, ist keep-coding-instructions: true. Damit bleiben Claude Codes eingebaute Engineering-Anweisungen (Scoping, Kommentieren, Verifikation) erhalten, während dein Style on top gelegt wird — was du willst: ausführliche Prosa, ohne den Code oder die Kommentare aufzublähen.

Um das zu aktivieren, hast du zwei Optionen:

• /config ausführen und Output style aus dem Menü wählen, oder
• outputStyle in ~/.claude/settings.json direkt editieren

Natürlich habe ich die Lösung überengineered

Wie jeder gute Engineer habe ich die Lösung jetzt überengineered. Ich bin etwas verärgert, dass ich diese Kommunikationsänderung nicht früher bemerkt habe. Für die Zukunft habe ich (na ja, Claude) ein Set von Evals gebaut, die bei jedem neuen Model-Release laufen, um Regressionen und Drifts zu flaggen. Deterministische Checks plus Qwen als LLM-as-judge. Super-Nerd-Status freigeschaltet. Schönen Tag noch.