Claude nachjustieren

Seit Frühjahr 2026 verdichten sich in Entwicklercommunities ein bestimmtes Muster: Claude hat früher bei komplexen Aufgaben ausführlich durchgeplant, Zwischenschritte abgewogen, Alternativen benannt. Heute kommt öfter eine schnelle Antwort – korrekt genug für einfache Fälle, aber zu flach für anspruchsvolle.

Das ist kein Einzelfall. Auf Reddit, in Developer-Foren und bei Nutzern von Claude Code, Cursor und Zed taucht dieselbe Beobachtung immer wieder auf. Die Frage ist: Was steckt dahinter – und was können Entwickler dagegen tun?

Das Muster: Was sich verändert hat

Die Beschwerden sind konsistent genug, um ernst genommen zu werden. Berichte aus der Entwickler-Community beschreiben:

• Weniger strukturierte Zwischenschritte bei mehrstufigen Problemen
• Häufigeres „good enough” statt vollständiger Analyse
• Mehr Halluzinationen oder übersprungene Schritte bei Coding-Aufgaben
• Bei Agentic-Tasks: abgebrochene Tool-Läufe, fehlerhafte Tool-States, unzuverlässiges Agent-Verhalten

Das fühlt sich an wie ein Modell, das manchmal entscheidet, nicht tief zu denken – obwohl die Aufgabe es erfordern würde. Dieser Eindruck ist nicht irrational, und er ist inzwischen auch quantifiziert.

Eine AMD-Ingenieurin analysierte 6.852 Claude-Code-Sessions mit 17.871 Thinking-Blöcken: Die Reasoning-Tiefe sank seit Ende Februar 2026 um 67%. Konkret: Vor Edits wurde eine Datei im Schnitt 6,6-mal gelesen, danach nur noch 2-mal. Das Wort „simplest” tauchte 642% häufiger auf – und das Modell räumte in einigen Sessions selbst ein, Abkürzungen genommen zu haben. Reddit und Hacker News diskutieren das als „AI-Shrinkflation” durch Kostenoptimierung. Der Begriff passt.

Wahrscheinliche Ursachen

Adaptive Compute und Effort-Steuerung

Anthropic dokumentiert inzwischen ausdrücklich, dass neuere Claude-Modelle adaptive Thinking-Mechanismen haben. Seit Claude 4.6 ist adaptives Thinking Standard: Das Modell entscheidet bei low und medium Effort selbst, ob es überhaupt tief denkt, und überspringt Reasoning-Schritte bei vermeintlich einfachen Tasks. Extended Thinking gilt inzwischen als deprecated und wird durch den Parameter effort ersetzt, der Tool-Calls und alle Token-Kategorien beeinflusst.

Diese Heuristik ist nicht perfekt. Bei eindeutigen Aufgaben funktioniert die Abkürzung. Bei ambivalenten oder komplexen Anfragen – offene Prompts, explorative Tasks, nicht streng strukturierte Aufgaben – wird das Reasoning manchmal zu früh beendet. Der entscheidende Trigger für tiefes Denken fehlt in der Eingabe, also entscheidet das Modell: „Reicht so.”

Je mehr Millionen Anfragen gleichzeitig laufen, desto mehr wirtschaftlicher Druck entsteht, diesen Mechanismus aggressiver einzusetzen.

Token-Kosten als harter Faktor

Das ist der vielleicht wichtigste Punkt – und er ist klar belegbar. Anthropic dokumentiert, dass Thinking-Tokens als Output-Tokens abgerechnet werden und auf Limits wirken. Für Claude Code ist außerdem dokumentiert, dass genutzte Thinking-Tokens kostenrelevant sind.

Extended Thinking, Chain-of-Thought, tiefe Analyse – das alles kostet Token. Bei einer Anfrage kaum messbar. Bei Millionen Anfragen täglich: erheblich. Die Schwelle, ab der das Modell „lohnt sich nicht, tief nachzudenken” entscheidet, dürfte nach Effizienz-Updates gesunken sein.

RLHF-Verschiebungen nach Updates

Wenn Präferenzdaten für das Training angepasst werden, verschiebt sich, was das Modell als „gute Antwort” einschätzt. Feedback, das Klarheit, Kürze und unmittelbaren Nutzen betont, kann dazu führen, dass exploratives, spekulatives Denken systematisch weniger bevorzugt wird.

Das ist kein absichtliches Downgrade – es ist eine Nebenwirkung davon, was im Training als positiv bewertet wird.

Alignment- und Safety-Updates

Konservativere Antwortmuster nach Safety-Updates sind ein bekanntes Phänomen. Wenn das Modell Unsicherheit stärker vermeidet, wird spekulatives oder exploratives Reasoning seltener. Statt mehrere Möglichkeiten durchzuspielen, wird die wahrscheinlichste Antwort direkt geliefert.

In Szenarien, wo gerade das Durchdenken von Alternativen gefragt ist – Architekturentscheidungen, Code-Reviews, komplexe Debugging-Situationen – geht genau das verloren.

Was Anthropic offiziell kommuniziert

Anthropic bestreitet ein absichtliches Downgrade. Gleichzeitig deuten aktuelle Berichte darauf hin, dass Default-Effort- bzw. Reasoning-Einstellungen verändert wurden – eher eine Effizienz- und Produktsteuerung als ein offenes Qualitätsstatement.

Im März 2026 hat Anthropic außerdem Off-Peak-Anreize eingeführt: Außerhalb bestimmter Werktagszeiten wurden Nutzungslimits zeitweise verdoppelt. Das spricht dafür, dass Lastverteilung und Kostensteuerung inzwischen stärker operationalisiert werden.

Zwei Infrastrukturereignisse liefern zusätzlichen Kontext. Am 2. März 2026 gab es einen weltweiten Ausfall durch Nutzerwachstum, der die Antwortqualität zeitweise beeinträchtigte – ähnlich dem September-2025-Postmortem, in dem Anthropic erklärte, dass drei Infrastrukturfehler zwischen August und Anfang September 2025 die Qualität verschlechtert hatten. Wahrgenommene Qualitätsabfälle müssen also nicht immer Modellpolitik sein – manchmal sind es schlicht technische Ursachen.

Die Off-Peak-Promotion lief vom 13. bis 27. März 2026: Nutzungslimits außerhalb bestimmter Werktagszeiten wurden verdoppelt, innerhalb der Stoßzeiten blieb alles unverändert.

Das klassische Kommunikationsproblem bleibt: Nutzer beschreiben reale Verhaltensänderungen. Was nicht gesagt wird: ob und wie aggressiv adaptive Effort-Heuristiken eingesetzt werden.

Der Abstraktionsfaktor: Zed, Claude Code, API

Wo Claude ausgeführt wird, beeinflusst, wie es denkt.

Direkte API und Claude Code CLI bieten maximale Kontrolle. System-Prompt, Kontext, Modellwahl, Effort-Level – alles explizit. Das Modell bekommt, was eingegeben wird, ohne Zwischenschicht.

Zed und ähnliche Editor-Integrationen fügen Abstraktionsebenen hinzu. Zed nutzt für Claude keinen bloßen Rohdurchgriff auf die CLI, sondern den Claude Agent über ACP (Agent Communication Protocol). Unter der Haube läuft Claude Code, aber eingebettet in Zeds eigenen Adapter- und Kontextlayer – mit eigenem System-Prompt, eigener Modellkonfiguration und eigenen Agent-Profilen.

Die Konsequenz: Was in einem Tool flach wirkt, kann in einem anderen besser sein – nicht weil das Modell anders ist, sondern weil der Prompt-Kontext sich unterscheidet.

Ich habe in genau diesem Zeitraum in Zed weniger von den beschriebenen Verhaltensänderungen bemerkt – und wahrscheinlich ist Zeds ACP-Adapter der Grund dafür: Die Adapter-Schicht bringt eigene Kontext-Anreicherung mit, die Reasoning implizit begünstigt, ohne dass man dafür etwas konfigurieren muss. Was mir allerdings aufgefallen ist: ein überdurchschnittlich hoher Sonnet-Verbrauch in diesem Zeitraum. Irgendwann hatte ich das Limit erreicht und musste für alle Anfragen auf Opus umsteigen – was gut dazu passt, dass ich Zed oft auf Default laufen lasse. Die Adapter-Schicht kompensiert die Default-Heuristik stillschweigend, aber nicht kostenlos.

Was Entwickler konkret tun können

Das ist der handlungsfähige Teil. Entwickler können das Reasoning-Verhalten von Claude durch explizite Trigger zuverlässiger steuern.

Effort explizit setzen

Der zuverlässigste erste Schritt: nicht auf die Default-Heuristik verlassen, sondern Effort explizit konfigurieren.

In Claude Code stehen dafür mehrere Wege offen:

# Per Flag
claude --effort high

# Per Slash-Command in der Session
/effort high

# Per Umgebungsvariable
CLAUDE_CODE_EFFORT_LEVEL=high claude

Oder in ~/.claude/settings.json:

{
  "effortLevel": "high"
}

Über die API ist effort der aktuelle Weg – budget_tokens gilt als deprecated:

{
  "effort": { "type": "high" },
  "thinking": { "type": "adaptive" }
}

Für maximale Denktiefe bei Opus 4.6+:

{
  "effort": { "type": "max" }
}

Opus 4.7 (seit 16. April 2026) bringt außerdem das Level xhigh, optimiert für lange Agentic-Tasks. Praxisempfehlung: Mit high starten, bei komplexen Multi-Step-Aufgaben auf xhigh eskalieren – nicht auf max. max erzeugt bei Opus 4.6 öfter Child-Agents (z.B. Haiku für Subtasks), was bei bestimmten Prompts schlechtere Ergebnisse liefern kann. Wie diese Agent-Hierarchien intern funktionieren – Orchestrator, Subagents, Session-Infrastruktur – habe ich im Artikel zu Claude Managed Agents beschrieben.

Reasoning explizit aktivieren

Ohne expliziten Hinweis entscheidet das Modell selbst, wie tief es denkt. Mit einem expliziten Hinweis nicht:

# Ohne Trigger (riskiert flache Antwort)
Reviewed diesen Code und sag mir was falsch ist.

# Mit Reasoning-Trigger
Reviewed diesen Code Schritt für Schritt. 
Überlege dabei:
- Welche Edge Cases gibt es?
- Was passiert bei ungültiger Eingabe?
- Gibt es Performance-Probleme?
Schreibe deine Überlegungen auf, bevor du die finale Einschätzung gibst.

Der zweite Prompt erzwingt strukturiertes Durchdenken. Das Modell kann nicht mehr abkürzen, ohne explizit gegen die Anweisung zu verstoßen.

Aufgaben in Reasoning-Schritte aufteilen

Statt einer komplexen Anfrage in einem Prompt: Aufgaben iterativ zerlegen.

# Schritt 1: Analyse
Was sind die möglichen Ursachen für diesen Fehler? Liste alle Möglichkeiten auf, 
auch unwahrscheinliche.

# Schritt 2 (nach Antwort): Priorisierung
Welche der genannten Ursachen ist am wahrscheinlichsten – und warum?

# Schritt 3: Lösung
Wie behebe ich die wahrscheinlichste Ursache? Zeige konkreten Code.

Iterative Prompts sind resilienter gegen flaches Reasoning als One-Shot-Anfragen.

Kontradiktives Denken einbauen

Analysiere diesen Architekturansatz. Dann spiele den Advocatus Diaboli: 
Welche Annahmen könnten falsch sein? Was übersieht der Ansatz?

Das zwingt das Modell, eine Position einzunehmen, sie dann zu hinterfragen – statt beim ersten plausiblen Ergebnis zu stoppen.

Einordnung

Die Beobachtungen sind real. Viele Entwickler erleben spürbare Verhaltensänderungen nach Updates – und das ist nicht nur subjektives Empfinden. Die technischen Mechanismen dahinter (adaptive Effort-Heuristiken, RLHF-Verschiebungen, Effizienzoptimierung) sind plausibel und inzwischen teils offiziell dokumentiert.

Was nicht stimmt: die Annahme, das sei absichtliches Downgrading oder bewusste Täuschung. Anthropics Claude-Code-Team hat auf Hacker News auf die Kritik reagiert und keine Absicht eines Qualitätsabbaus bestätigt. Wahrscheinlicher ist: Anthropic optimiert aktiv auf Effizienz und Skalierung. Das beeinflusst das wahrgenommene Reasoning-Verhalten – als Nebenwirkung, nicht als Ziel.

Was Opus 4.7 ändert – und was nicht

Opus 4.7 ist seit dem 16. April 2026 verfügbar und liefert auf dem Papier klare Verbesserungen: 87,6% auf SWE-bench Verified (4.6: 80,8%), bessere Instruction-Following, reduzierte Halluzinationen, 3x höhere Bildauflösung. Das zeigt, dass die Modellqualität strukturell steigt.

Aber hier ist der wichtigste Punkt: Ein Teil des wahrgenommenen Qualitätsgewinns liegt nicht daran, dass 4.7 so viel stärker ist – sondern daran, dass das Thinking-Level bei 4.6 zuletzt standardmäßig abgesenkt war. Wer nichts manuell konfiguriert hatte, bekam automatisch schwächere Ergebnisse. 4.7 wirkt also auch deshalb besser, weil 4.6 zuletzt sparsamer konfiguriert war. Das bestätigt die Kernthese dieses Artikels direkt.

Die interessantere Frage ist, ob Anthropic die Default-Heuristiken grundsätzlich angepasst hat – oder ob 4.7 einfach ein stärkeres Modell mit denselben Mechanismen ist. Die Hinweise sprechen eher für Letzteres. Das neue Effort-Level xhigh ist eine Erweiterung der expliziten Steuerungsoberfläche, kein Beleg dafür, dass Defaults großzügiger werden. Anthropic gibt Entwicklern mehr Hebel – nicht weniger Notwendigkeit, sie zu benutzen.

Die vollständige Effort-Skala lautet jetzt: low, medium, high, xhigh, max. Empfehlung aus der Praxis: xhigh ist meist der bessere Sweet Spot als max – der Leistungsgewinn von max gegenüber xhigh ist oft klein, der Token-Mehrverbrauch aber erheblich. Wer bei max arbeitet, läuft schnell in Limits.

Dazu kommt ein neuer Tokenizer: Der gleiche Input kann je nach Inhalt bis zu 35–50% mehr Tokens verbrauchen als bei 4.6. Anthropic hat die Limits zwar erhöht, aber die Kombination aus höherem Tokenverbrauch und weiterhin knappen Tarifen bleibt ein praktisches Problem – besonders im günstigeren Plan.

Wo 4.7 auch Rückschritte zeigt: Anthropic selbst dokumentiert Verschlechterungen bei agentischer Suche und bei einem Langkontext-Benchmark (ähnlich „Needle in a Haystack”). Das Claude-Code-Team kommentiert dazu, dieser Benchmark sei eher darauf ausgelegt, Modelle auszutricksen, und habe wenig Relevanz für echte Praxis. Das mag stimmen – es bleibt aber auffällig, dass Regressionen mit Benchmark-Kritik begleitet werden.

Vision im echten Einsatz bleibt schwächer als die Benchmarks suggerieren. In Praxistests schlug das Modell bei einem Würfelrätsel trotz Bildinput fehl – die Logik war korrekt, aber die Würfelaugen wurden nicht zuverlässig erkannt. 3x höhere Auflösung in den Benchmarks bedeutet nicht zwingend 3x besser im Alltag.

Guardrails und Prompting: 4.7 befolgt Anweisungen sehr wörtlich – das ist eine dokumentierte Verbesserung bei Instruction-Following, kann aber auch dazu führen, dass das Modell in bestimmten Situationen verweigert (Websuche, Codeänderungen), wo 4.6 noch durchgelassen hätte. Prompts, die bisher mit Betonung oder Großbuchstaben gearbeitet haben, können sich kontraproduktiv verhalten. Klare, direkte Fließtext-Prompts funktionieren zuverlässiger.

Der praktische Umgang damit ist weniger dramatisch als die Community-Diskussionen suggerieren: Wer komplexe Aufgaben stellt, Effort explizit setzt und dabei strukturiertes Reasoning einfordert, bekommt nach wie vor starke Ergebnisse. Wer auf implizites Deep Thinking wartet, wird öfter enttäuscht.

Das Muster ist so alt wie Prompt Engineering selbst: Der Mensch führt, das Modell folgt. Nur muss das jetzt expliziter eingefordert werden als früher.

Was bei 4.7 trotzdem berechtigt stört

Die bisherige Einordnung bleibt stehen. Aber sie darf vier Punkte nicht wegdiskutieren, die unabhängig von der Modellqualität gelten – und die zusammen ein strukturelles Problem beschreiben.

Breaking Changes ohne klare Migration. Wer Produktionssysteme auf der API aufgebaut hat, musste bei 4.7 nachjustieren. budget_tokens gilt als deprecated, effort ist der neue Weg – aber wann genau, wie sich Verhalten konkret ändert und was das für bestehende Prompts bedeutet, blieb teils unklar. Das trifft Systeme, die auf stabiles Default-Verhalten ausgelegt waren. Keine Absicht, kein böser Wille – aber ein echtes Praxisproblem.

Tokenizer-Änderung als Kostenüberraschung. Die neue Tokenisierung kann Vorteile bringen: bessere Sprachrepräsentation, stabilere Outputs für bestimmte Sprachräume. Aber wer bestehende Budgets auf 4.6-Basis kalkuliert hatte, trifft auf 35–50% höheren Tokenverbrauch ohne proportional höhere Limits. Das ist kein versteckter Nachteil – es steht in der Dokumentation. Aber es ist eine direkte Kosten-Auswirkung, die beim Modellwechsel selten sofort sichtbar ist.

Hidden Thinking Tokens. Das Ziel ist nachvollziehbar: geringere Latenz, sauberere Outputs ohne sichtbaren Reasoning-Block. Das Problem ist, dass Kosten weiterhin entstehen – der Prozess aber weniger transparent wird. Debugging von agentic Tasks, bei denen Thinking-Verhalten direkt das Ergebnis beeinflusst, wird aufwändiger. Der Frust darüber ist verständlich, auch wenn das Ziel technisch Sinn ergibt.

Default-Verhalten mit Regressionsrisiko. Adaptive Thinking vereinfacht die Nutzung – das ist der erklärte Vorteil. Aber Systeme, die auf einem bestimmten Default-Verhalten aufgebaut waren, können nach einem Modellwechsel still schlechter werden. Wer nicht explizit konfiguriert hat, merkt das erst, wenn Ergebnisse driften – nicht beim Wechsel selbst.

Zur Einordnung: Ich kann aus eigener Praxis derzeit keine großen systematischen Probleme bestätigen. Die Beschreibungen oben basieren auf dokumentierten Verhaltensänderungen, offiziellen Changelogs und Community-Berichten – nicht auf eigenen Ausfällen.