Anthropic hat Claude Sonnet 4.6 im Februar 2026 als neues Default-Modell für Free- und Pro-Nutzer vorgestellt – mit der Ansage, dass es Coding, mehrstufige Agenten-Workflows, Long-Context-Reasoning und allgemeine Wissensarbeit deutlich verbessert, bei gleicher oder besserer Qualität und geringerem Preis als frühere Modelle. Kurz darauf wurde Claude Opus 4.7 als „flagship“ für besonders anspruchsvolle Software-Engineering-Tasks und Agenten veröffentlicht, mit noch stärkerer Instruktions-Treue, besserer Selbstüberprüfung und deutlich höheren Erfolgsraten auf komplexen Benchmarks.anthropic+5
Auf dem Papier ergibt das eine saubere Produktlogik: Sonnet 4.6 als starker, günstiger Standard – Opus 4.7 als Premium-Tier für die härtesten Fälle.anthropic+2
In meinem Alltag als Entwickler funktioniert diese Logik nicht.
Nicht, weil Opus 4.7 zu teuer wäre.
Sondern weil Sonnet 4.6 in der Praxis so oft Mehrarbeit erzeugt, dass das vermeintlich günstigere Modell am Ende teurer wird.
Inhaltsverzeichnis
Das falsche Verständnis von „günstig“
Wenn man Artikel und Ankündigungen liest, bekommt man ein klares Bild: Sonnet 4.6 soll einen großen Teil der Lücke zu Opus schließen – ähnlich stark, aber deutlich günstiger. Viele Berichte loben Sonnet 4.6 für weniger Halluzinationen, bessere Instruktions-Befolgung, robustere CoT-Reasoning-Ketten und bessere Performance auf praktischen Benchmarks.venturebeat+4
Das ist die Sicht von außen.
Von innen – mitten in laufenden Projekten, in echten Repos, mit echten Bugs und echten Deadlines – sieht die Sache anders aus. Für Entwickler ist das relevante Preismodell nicht „Dollar pro Million Tokens“, sondern etwas Brutaleres: Wie oft zwingt mich dieses Modell, denselben Bug zweimal anzufassen?
Ein Modell kann nominal günstiger sein und trotzdem teuer, wenn es systematisch Rework provoziert: erst mit dem Modell arbeiten, dann gegen das Modell arbeiten.
Genau so fühlt sich Sonnet 4.6 für mich aktuell an.
Ein konkreter Fall: Raten statt debuggen
Ich hatte eine Session mit einem neuen Modal in einer bestehenden Anwendung. Die Ausgangslage war nicht exotisch: ein Panel, ein Workflow-Ring, eine „Executor“-Card, ein Modal, das sich partout nicht öffnen wollte, ein 404 im Log. Ich habe Sonnet 4.6 den aktuellen Zustand beschrieben: URL, sichtbare Elemente, XHR-Logs.
Die Reaktion des Modells war symptomatisch:
„Ja, genau das ist die Card! Einfach draufklicken — das Modal sollte aufgehen.“
Als das nicht passierte und ich die Logs zeigte, kam die nächste Schicht Selbstsicherheit:
„Das 404 ist erwartet — aber das Modal öffnet sich trotzdem nicht. Es gibt wahrscheinlich einen JS-Fehler vor dem openModal-Aufruf.“
Das Problem ist nicht, dass diese Sätze technisch völlig unsinnig wären. Das Problem ist, dass sie wie Debugging klingen, aber keins sind. Da wird nichts hart überprüft: kein tatsächlicher Blick in das konkrete openModal, keine saubere Analyse der bestehenden Modals, kein systematischer Vergleich von Struktur und CSS, keine echte Verifikation der Hypothese.
Stattdessen folgte ein Muster, das ich bei Sonnet 4.6 mehrfach erlebt habe:
- Es stellt eine Frage („siehst du den Ring?“), ignoriert dann Teile der Antwort.
- Es formuliert Hypothesen („404 ist sicher erwartet“), behandelt sie aber wie Fakten.
- Es rewritet UI-Strukturen („ich passe das Modal an“), ohne wirklich sauber zu prüfen, welche Klassen, IDs und Styles im System tatsächlich existieren.
Das Ergebnis in dieser Session war ein mehrfach umgebautes Modal: falsche Klassen, Inline-Styles, die openModal aushebeln, und ein von der restlichen UI-Logik entkoppelter Dialog, der optisch nicht zum bestehenden System passt. Kurz gesagt: plausible Aktivität, aber keine robuste Problemlösung.
Das ist das Muster, das in der Summe teuer wird. Nicht der große Knall. Der sanfte Drift.
Der gleiche Fall mit Opus 4.7: Diagnose vor Aktion
Als ich dasselbe Problem anschließend mit Opus 4.7 weitergedacht habe, war der Unterschied sofort spürbar. Nicht, weil plötzlich alles „magisch“ funktioniert hätte, sondern weil die Arbeitsweise eine andere war.
Zuerst benannte Opus 4.7 die offensichtlichen UX-Defizite, ohne sich in technische Details zu flüchten:
„Du hast völlig recht. Das Modal hat mehrere harte UX-Fehler:
- Titel läuft über — kompletter Marker-Titel mit #sprint-…-Tag im h2
- Null Kontext — User sieht nicht welcher Marker, keine Task-Details, kein Ziel
- JSON-Textarea ist unzumutbar — niemand tippt {„files_changed_json“:“[]“,“diff_stat_text“:““,…} per Hand
- Kein CLI-Hinweis — aber genau dafür gibt’s den claude-task-Helper
- View B zeigt keine Task-Details — goal, allowed_files, stop_conditions sind unsichtbar
- Keine Bedienanleitung — was passiert nach „Prompt kopieren“?“
Erst danach kam der entscheidende Satz:
„Ich rewrite das komplett und prüfe zuerst was record_execution wirklich erwartet:“
Genau hier trennt sich für mich „AI, die Text generiert“ von „AI, die mit mir entwickelt“. Anthropic beschreibt Opus 4.7 selbst als signifikante Verbesserung für schwierige Software-Engineering-Aufgaben, insbesondere mit besserer Selbstüberprüfung, höherer Erfolgsquote bei End-to-End-Tasks und robusterem Verhalten in Agenten-Workflows. In dieser Session hat es sich genau so verhalten.pureai+2
Verifikation statt Vibe
Als ich Opus 4.7 explizit bat, die Umsetzung systematisch zu prüfen, kam nicht der übliche „dürfte passen“-Reflex, sondern ein echter Verifikationsmodus: Tests laufen lassen, Payload-Felder gegen API-Code abgleichen, onclick-Handler und DOM-IDs matchen, Endpunkte prüfen.
Es fand nicht nur kosmetische Unsauberkeiten, sondern einen echten funktionalen Fehler:
„Jetzt ein echter Bug — der /prompt-Endpunkt verlangt X-Agent-Task-Token-Header, aber der Browser sendet keinen.“
Der anschließende Fix war nicht perfekt im Sinne eines OWASP-Tutorials, aber pragmatisch nachvollziehbar: Same-Origin-Requests aus der Dashboard-UI anhand des Sec-Fetch-Site-Headers durchlassen, CLI-Tools weiterhin über Token schützen. Für ein internes Cockpit ist das zumindest ein bewusst gewählter Trade-off, kein blindes „lass einfach alles durch“.developer.mozilla+1
Damit war es aber nicht getan.
Die „kleinen“ Fixes, die in der Praxis groß sind
In einem zweiten Durchlauf nahm sich Opus 4.7 Dinge vor, die viele Modelle gar nicht sehen, die aber im Alltag extrem wichtig sind.
1. Clipboard-Fallback für nicht-secure Contexts
Die erste Version des Prompts-Kopierens nutzte direkt navigator.clipboard.writeText. Das funktioniert in modernen Browsern nur in sogenannten „secure contexts“, d.h. auf HTTPS-Seiten oder speziellen localhost-Umgebungen. In einem realistischen Setup wie http://192.168.x.x im LAN scheitert das.github+2
Der erzeugte Fix sah so aus:
jsfunction _agentHandoffCopyToClipboard(text) {
// Moderne API bevorzugt (HTTPS / localhost)
if (navigator.clipboard && window.isSecureContext) {
return navigator.clipboard.writeText(text);
}
// Fallback fuer HTTP-LAN-Setups (execCommand ist deprecated, funktioniert aber ueberall)
return new Promise(function(resolve, reject) {
try {
var ta = document.createElement('textarea');
ta.value = text;
ta.setAttribute('readonly', '');
ta.style.position = 'fixed';
ta.style.left = '-9999px';
ta.style.top = '0';
document.body.appendChild(ta);
ta.focus();
ta.select();
ta.setSelectionRange(0, text.length);
var ok = document.execCommand('copy');
document.body.removeChild(ta);
if (ok) resolve();
else reject(new Error('execCommand copy returned false'));
} catch (e) { reject(e); }
});
}
Die Clipboard-API im Secure-Context zuerst zu nutzen und für HTTP-Setups auf document.execCommand('copy') zurückzufallen, ist genau der pragmatische Kompromiss, den MDN-Dokumentation und Diskussionen zu Clipboard-Fallbacks nahelegen – auch wenn execCommand formell deprecated ist.web.nodejs+2
2. Einstiegspunkt im Panel-Header
Vorher gab es nur einen Einstieg über eine spezielle Workflow-Ring-Card. Projekte ohne diesen Ring hatten faktisch keinen Button, um das Handoff-Modal zu öffnen. Opus 4.7 zog den Einstieg direkt in den Panel-Header hoch:
xml<div style="display:flex;gap:8px;align-items:center;">
<button class="btn btn-sm btn-secondary" onclick="openAgentHandoffFromPanel()" title="Agent-Task anlegen oder oeffnen">
<i data-lucide="play-circle" class="icon icon-xs"></i> Agent-Task
</button>
<button class="board-panel-close" onclick="closeSectionPanel()" title="Schliessen">×</button>
</div>
Mit einem globalen _currentSection-Objekt, das Marker-ID, Titel und Ziel enthält, konnte das Modal so direkt aus jedem geöffneten Panel gestartet werden. Das ist nicht spektakulär – aber es ist genau die Sorte UX-Fix, die darüber entscheidet, ob ein Feature im Alltag wirklich existiert.
3. Race-Condition-Fix bei asynchronen Requests
Ein subtileres, aber extrem wichtiges Problem war eine potenzielle Race Condition: Wenn man das Modal für Marker A öffnet, schnell schließt und sofort für Marker B wieder öffnet, können verspätete Responses für A die Ansicht von B überschreiben. Das ist ein klassischer Fehler bei asynchronen UI-Updates.codefixeshub+2
Opus 4.7 schlug ein Guard-Pattern vor:
js// Existierenden offenen Task suchen. markerId einfangen, damit spaete
// Responses nach Modal-Wechsel nicht in die neue Instanz hineinfunken.
var requestedMarker = markerId;
api.get('/api/agent-tasks?marker_id=' + encodeURIComponent(markerId))
.then(function(task) {
if (_agentHandoffMarkerId !== requestedMarker) return;
if (task && task.task_id) {
_agentHandoffShowTask(task);
}
})
.catch(function(err) {
if (_agentHandoffMarkerId !== requestedMarker) return;
// ...
});
Das ist genau die Art von „stale response“-Schutz, über die inzwischen zahlreiche Artikel und Best Practices im Frontend-Bereich schreiben: Antworten nur anwenden, wenn der Zustand noch derselbe ist wie zum Zeitpunkt der Anfrage.frontendatlas+1
Was das über Sonnet 4.6 und Opus 4.7 wirklich sagt
Anthropic verkauft Sonnet 4.6 als das Modell, das den „Sweet Spot“ zwischen Qualität und Kosten trifft, und Opus 4.7 als das Modell für besonders schwierige Fälle. In der Realität meines Workflows zeigt sich ein anderes Bild:anthropic+1
- Sonnet 4.6 erzeugt oft plausible, aber nur halb geprüfte Lösungen. Es arbeitet sprachlich sauber, aber debuggt zu selten wirklich. Die Folge sind Runden von Rework.
- Opus 4.7 verhält sich deutlich mehr wie ein echter technischer Partner: es identifiziert funktionale Bugs, denkt UX mit, berücksichtigt Infrastruktur-Realitäten (Clipboard/HTTP) und schützt die UI vor subtilen Race Conditions.
Der Punkt ist nicht, dass Sonnet 4.6 „schlecht“ wäre. Viele Benchmarks und Use-Cases sprechen dafür, dass es für Office-Work, Wissensarbeit und leichteres Coding durchaus stark sein kann. Der Punkt ist, dass es für meinen realen Dev-Alltag in kritischen Bereichen zu oft Nacharbeit erzwingt.indiatoday+2
Und Nacharbeit ist teurer als Tokens.
Meine Konsequenz
Für mich ist Sonnet 4.6 als Daily Driver für ernsthafte Entwicklungsarbeit derzeit disqualifiziert. Nicht, weil es nichts kann, sondern weil es mich zu oft denselben Fehler zweimal anfassen lässt: einmal mit dem Modell, einmal gegen das Modell.
Ich nutze Sonnet 4.6 inzwischen nur noch für ungefährliche Nebenarbeit – Doku, Spezifikationen, Zusammenfassungen, triviale Snippets. Für echte Software-Entwicklung, Debugging, Refactors und UI-Fixes setze ich auf Opus 4.7 oder andere Modelle, die sich in der Praxis bewährt haben.
Das eigentliche Problem mit Sonnet 4.6 ist für mich deshalb nicht seine nominelle Qualität oder sein Preis.
Das eigentliche Problem ist, dass es in der Rolle, für die es verkauft wird, zu oft doppelte Arbeit erzeugt.
Und ein Modell, das doppelte Arbeit erzeugt, ist nicht günstiger.
Es ist nur günstiger angeschrieben.
