Ich habe $500 ausgegeben, um Claude Sonnet 4.6 vs Opus 4.6 zu testen – hier ist mein Ergebnis

Warum ich dieses Experiment durchgeführt habe

Jeder veröffentlicht Benchmark-Tabellen, die Claude Sonnet 4.6 und Opus 4.6 vergleichen. Mit einer kurzen Suche findet man ein Dutzend davon. Aber Benchmarks messen die Modellleistung bei standardisierten Aufgaben — sie sagen einem nicht, was passiert, wenn man um 2 AM knietief in einer unordentlichen Codebase steckt und versucht, ein Feature auszuliefern.

Ich wollte eine einfachere Frage beantworten: Bei welchen der tatsächlichen Aufgaben, die ich jeden Tag als Entwickler erledige, verdient Opus 4.6 seinen 5-fachen Preisaufschlag?

Also habe ich ein kontrolliertes Experiment aufgebaut. Über 3 Wochen hinweg habe ich jede Coding-Aufgabe durch beide Modelle laufen lassen — gleiche Prompts, gleiche Codebases, gleiche Evaluationskriterien. Ich habe Kosten, Output-Qualität, Zeit bis zur Fertigstellung und die Anzahl der benötigten Korrekturen nachverfolgt.

Die Rechnung belief sich auf etwa $500. Hier ist alles, was ich gelernt habe.

Der Aufbau: Wie ich den Test strukturiert habe

Ich habe die Claude API direkt mit identischen System-Prompts für beide Modelle verwendet. Keine Wrapper, keine Assistenten, keine speziellen Konfigurationen — nur reine API-Aufrufe, damit der Vergleich sauber ist.

Getestete Modelle:

• Claude Sonnet 4.6 (claude-sonnet-4-6) — $3 Input / $15 Output pro Million tokens
• Claude Opus 4.6 (claude-opus-4-6) — $15 Input / $75 Output pro Million tokens

Methodik:

• Gleicher Prompt für jede Aufgabe, gesendet an beide Modelle innerhalb derselben Stunde
• Jede Aufgabe bewertet nach: Korrektheit, Code-Qualität, Vollständigkeit und Anzahl der benötigten Follow-up-Prompts
• Alle Aufgaben stammen aus realen Projekten — keine synthetischen Benchmarks
• Ich habe jedes Modell auf einer Skala von 1-10 für jede Dimension bewertet

Die Preisdaten stammen direkt von Anthropic's offizieller Pricing-Seite. Die Geschwindigkeitsmessungen stammen aus den Artificial Analysis Benchmarks.

Szenario 1: Debugging einer Race Condition in asynchronem Code

Die Aufgabe: Eine Node.js-Anwendung hatte einen intermittierenden Fehler, bei dem Datenbank-Schreibvorgänge in der falschen Reihenfolge abgeschlossen wurden. Der Bug trat nur unter Last auf. Ich gab beiden Modellen die relevanten Quelldateien (etwa 8K tokens Kontext) und die Error-Logs.

Sonnet 4.6 Ergebnis: Identifizierte das fehlende await in einer Promise-Kette innerhalb von zwei Interaktionen. Schlug vor, die Schreibvorgänge in eine Transaction zu kapseln. Sauberer, korrekter Fix.

Opus 4.6 Ergebnis: Identifizierte dieselbe Ursache bereits bei der ersten Interaktion, ging aber weiter — es markierte eine zweite potenzielle Race Condition in einem benachbarten Modul, die mir nicht aufgefallen war. Es erklärte zudem, warum der Bug intermittierend war (Event-Loop-Timing unter concurrent Connections) und schlug einen strukturellen Fix unter Verwendung einer Write-Queue vor.

Gewinner: Opus 4.6

Der Unterschied lag nicht im Finden des Bugs. Beide fanden ihn. Opus fand den zweiten Bug und lieferte architektonischen Kontext, der ein zukünftiges Problem verhinderte. Dies deckt sich mit dem, was Anthropic darüber berichtet, dass Opus 4.6 bessere Debugging-Fähigkeiten besitzt und die Fähigkeit hat, eigene Fehler zu erkennen.

Kosten: Sonnet $0.12 | Opus $0.58

Szenario 2: Erstellung von CRUD-Endpoints für eine REST API

Die Aufgabe: Generierung eines vollständigen Satzes von CRUD-Endpoints für eine "Projects"-Ressource in einer Express.js-Anwendung mit TypeScript, Prisma ORM, Input-Validierung über Zod und ordnungsgemäßer Fehlerbehandlung.

Sonnet 4.6 Ergebnis: Erstellte alle fünf Endpoints (Create, Read One, Read All mit Pagination, Update, Delete) in einer einzigen Antwort. Die Input-Validierung war korrekt, die Fehlerbehandlung solide, die TypeScript-Typen präzise. Bereit zum Kopieren und Testen.

Opus 4.6 Ergebnis: Erstellte dieselben fünf Endpoints mit fast identischer Struktur. Fügte etwas detailliertere Kommentare hinzu. Enthielt außerdem einen Middleware-Vorschlag für die Authentifizierung, nach dem ich nicht gefragt hatte.

Gewinner: Sonnet 4.6

Die Ergebnisse waren funktionell identisch. Sonnet war schneller, günstiger und blähte die Antwort nicht mit ungefragten Architekturvorschlägen auf. Für klar definierte, abgegrenzte Aufgaben wie die CRUD-Generierung bringt die zusätzliche Argumentationstiefe von Opus außer Kosten nichts.

Kosten: Sonnet $0.08 | Opus $0.41

Szenario 3: Refactoring einer monolithischen Komponente in kleinere Teile

Die Aufgabe: Eine 600 Zeilen lange React-Komponente, die Benutzerprofile verwaltet — einschließlich Form-State, API-Aufrufen, Berechtigungsprüfungen und Rendering-Logik — sollte in kleinere, testbare Teile zerlegt werden. Ich stellte die vollständige Komponente sowie die zugehörige Testdatei zur Verfügung.

Sonnet 4.6 Ergebnis: Teilte die Komponente in vier Teile auf: eine Container-Komponente, eine Form-Komponente, einen Berechtigungs-Hook und einen API-Hook. Angemessene Zerlegung. Allerdings wurde vergessen, zwei Import-Pfade in der Testdatei zu aktualisieren, und der Berechtigungs-Hook hatte ein subtiles State-Management-Problem, da ein Callback nicht memoisiert wurde.

Opus 4.6 Ergebnis: Aufteilung in fünf Teile mit einer saubereren Trennung. Es erstellte eine dedizierte Typ-Datei, aktualisierte alle Importe einschließlich der Testdatei korrekt und der Berechtigungs-Hook wurde ordnungsgemäß memoisiert. Es bemerkte außerdem, dass die ursprüngliche Komponente ein potenzielles Memory Leak in einem Effect-Cleanup hatte und behob es.

Gewinner: Opus 4.6

Hier wird der Unterschied deutlich. Dateiübergreifendes Refactoring mit Dependency-Tracking ist genau das Szenario, in dem der 76% Score von Opus 4.6 beim MRCR v2 (Multi-File-Reasoning und Code-Review) in praktischen Nutzen umschlägt. Die Lösung von Sonnet benötigte zwei Korrekturrunden. Opus lieferte im ersten Durchgang ein korrektes Ergebnis.

Kosten: Sonnet $0.22 (einschließlich Korrekturen) | Opus $0.95

Szenario 4: Schreiben von Unit Tests für bestehenden Code

Die Aufgabe: Schreiben umfassender Unit Tests für ein Zahlungsverarbeitungsmodul mit mehreren Edge Cases — abgelaufene Karten, unzureichende Deckung, Netzwerk-Timeouts, Teilrückerstattungen und Währungsumrechnung.

Sonnet 4.6 Ergebnis: Generierte 14 Testfälle, die alle von mir beschriebenen Szenarien abdeckten. Die Tests waren gut strukturiert mit klaren Describe/It-Blöcken. Das Mock-Setup war korrekt. Zwei Edge Cases, die ich nicht explizit erwähnt hatte (leerer Betrag, negativer Betrag), wurden einbezogen.

Opus 4.6 Ergebnis: Generierte 16 Testfälle. Ähnliche Struktur. Fügte einen Test im Integration-Stil hinzu, der den vollständigen Zahlungsfluss End-to-End verifizierte. Etwas wortreicher in den Testbeschreibungen.

Gewinner: Unentschieden (Sonnet 4.6 beim Preis-Leistungs-Verhältnis)

Beide lieferten exzellente Test-Suiten. Opus fügte zwei zusätzliche Tests hinzu, aber diese waren nicht signifikant besser. Für die Testgenerierung liefert Sonnet eine gleichwertige Qualität bei 5-fach geringeren Kosten. Sofern Sie keine extrem komplexe Business-Logik testen, ist Sonnet die richtige Wahl.

Kosten: Sonnet $0.09 | Opus $0.47

Szenario 5: Schreiben technischer Dokumentation

Die Aufgabe: Generierung einer API-Dokumentation für ein internes SDK — einschließlich Methodensignaturen, Parameterbeschreibungen, Rückgabetypen, Anwendungsbeispielen und Anleitungen zur Fehlerbehandlung für 12 öffentliche Methoden.

Sonnet 4.6 Ergebnis: Saubere, gut organisierte Dokumentation. Jede Methode hatte eine Beschreibung, eine Parametertabelle, einen Rückgabetyp, ein Beispiel und einen Fehlerabschnitt. Konsistente Formatierung durchweg.

Opus 4.6 Ergebnis: Fast identische Dokumentation. Opus fügte am Ende einen Abschnitt "Häufige Muster" hinzu, der zeigte, wie Methoden zusammenwirken — was nett, aber ungefragt war.

Gewinner: Sonnet 4.6

Dokumentation ist eine Aufgabe, bei der die Prägnanz von Sonnet tatsächlich ein Vorteil ist. Wie von Entwicklern beim Vergleich der beiden Modelle angemerkt, fügt Opus bei einfachen Aufgaben manchmal unnötige Erklärungen hinzu, was tokens und Zeit verschwendet. Bei der Dokumentation wünscht man sich Klarheit und Vollständigkeit, nicht Geschwätzigkeit und Philosophie.

Kosten: Sonnet $0.14 | Opus $0.72

Szenario 6: Code Review für einen Pull Request

Die Aufgabe: Review eines 400 Zeilen langen Pull Requests, der eine Caching-Ebene zu einer API hinzufügte. Ich wollte, dass beide Modelle Bugs identifizieren, Verbesserungen vorschlagen und Sicherheitsbedenken markieren.

Sonnet 4.6 Ergebnis: Fand drei Probleme — eine fehlende Cache-Invalidierung beim Update, ein potenzielles Memory Leak durch unbegrenztes Cache-Wachstum und einen Vorschlag zur Hinzufügung von TTL. Gutes, umsetzbares Feedback.

Opus 4.6 Ergebnis: Fand dieselben drei Probleme plus zwei weitere — eine Timing-Attack-Schwachstelle bei der Cache-Key-Generierung und ein subtiles Problem, bei dem gleichzeitige Anfragen während der Cache-Befüllung veraltete Daten zurückgeben könnten. Schlug ein spezifisches Muster (Read-Through Cache mit Distributed Locks) vor, um das Nebenläufigkeitsproblem zu beheben.

Gewinner: Opus 4.6

Code Reviews bei sicherheitsrelevantem Code sind ein weiterer Bereich, in dem Opus die Nase vorn hat. Die Timing-Attack-Schwachstelle war real und nicht offensichtlich. Dies deckt sich mit Berichten von Entwicklern, die Opus besonders stark finden, wenn der Fehler eine große architektonische Fläche überspannt.

Kosten: Sonnet $0.11 | Opus $0.53

Szenario 7: Rapid Prototyping eines neuen Features

Die Aufgabe: Erstellung eines Echtzeit-Benachrichtigungssystems mit WebSockets — serverseitiger Handler, clientseitiger Hook und eine Benachrichtigungskomponente mit Animationen. Zeit war die Priorität, nicht Perfektion.

Sonnet 4.6 Ergebnis: Lieferte eine funktionierende Implementierung in einer einzigen Antwort. Der WebSocket-Handler, der benutzerdefinierte React-Hook und die Benachrichtigungskomponente funktionierten alle zusammen. Die Animation war CSS-basiert und flüssig. Kleines Problem: keine Reconnection-Logik.

Opus 4.6 Ergebnis: Ergebnis in ähnlicher Qualität, enthielt aber Reconnection-Logik und eine Exponential-Backoff-Strategie. Fügte zudem einen Heartbeat-Mechanismus hinzu. Die Generierung dauerte aufgrund der geringeren token-Geschwindigkeit etwa 30% länger.

Gewinner: Sonnet 4.6

Beim Prototyping zählt Geschwindigkeit mehr als Vollständigkeit. Sonnet's schnellere Output-Generierung (etwa 47 tokens pro Sekunde gegenüber 40 bei Opus) ermöglicht engere Iterationszyklen. Die von Opus hinzugefügte Reconnection-Logik war gut, aber ich hätte sie ohnehin in einem zweiten Durchgang hinzugefügt. Prototyping belohnt schnellen, "gut genugen" Output.

Kosten: Sonnet $0.10 | Opus $0.48

Szenario 8: Architektonische Entscheidungsfindung

Die Aufgabe: Wir mussten uns zwischen einer Monorepo- und einer Polyrepo-Struktur für ein Microservices-Projekt entscheiden. Ich lieferte die Teamgröße, Deployment-Anforderungen, CI/CD-Einschränkungen und Service-Grenzen. Ich bat beide Modelle, die Tradeoffs zu analysieren und einen Ansatz zu empfehlen.

Sonnet 4.6 Ergebnis: Lieferte eine solide Pro/Contra-Analyse. Empfahl ein Monorepo mit Turborepo basierend auf der Teamgröße. Vernünftig, aber etwas generisch.

Opus 4.6 Ergebnis: Stellte drei klärende Fragen, bevor es sich auf eine Empfehlung festlegte — zur Deployment-Frequenz, zu serviceübergreifenden Datenabhängigkeiten und ob das Team Erfahrung mit Monorepos hat. Nachdem ich geantwortet hatte, lieferte es eine differenzierte Analyse, die einen hybriden Ansatz empfahl: Monorepo für Shared Libraries und eng gekoppelte Services, separate Repos für unabhängig bereitgestellte Services mit unterschiedlichen Release-Zyklen. Es skizzierte zudem einen Migrationspfad von der aktuellen Struktur.

Gewinner: Opus 4.6

Opus geht besser mit Ambiguität um. Wie zahlreiche Entwicklerberichte bestätigen, stellt Opus bessere klärende Fragen und trifft vertretbarere Annahmen. Für Senior Engineers, die an komplexen architektonischen Entscheidungen arbeiten, spart dieses Verhalten Stunden an Hin und Her.

Kosten: Sonnet $0.07 | Opus $0.62

Die finale Scorecard

Hier ist die Leistung jedes Modells über alle acht Szenarien hinweg, bewertet auf einer Skala von 1-10 für die Output-Qualität:

Opus 4.6 gewinnt: 4 Szenarien (Debugging, Refactoring, Code Review, Architektur) Sonnet 4.6 gewinnt: 2 Szenarien (Dokumentation, Prototyping) Unentschieden: 2 Szenarien (CRUD-Endpoints, Test-Schreiben)

Aber hier ist der Teil, den die Scorecard verbirgt: Sonnet 4.6 war in 6 von 8 Szenarien die richtige Wahl, wenn man die Kosten einbezieht. Die beiden Szenarien, in denen es deutlich schlechter abschnitt (Refactoring und Architektur), sind Aufgaben, die die meisten Entwickler ein paar Mal pro Woche erledigen, nicht Dutzende Male am Tag.

Die Kosten-Realität

Über drei Wochen des Testens sah die Rechnung wie folgt aus:

Opus kostete im Durchschnitt 5.25x mehr pro Aufgabe. Für denselben Satz an Aufgaben lieferte Sonnet 90% der Qualität bei 19% der Kosten.

Hätte ich den hybriden Ansatz verwendet — Sonnet für Routineaufgaben, Opus nur für die 20% der Aufgaben, die Refactoring, Debugging und Architektur betreffen — hätte meine Gesamtrechnung etwa $160 statt $500 betragen. Das ist eine Reduzierung um 68% bei fast keinem Qualitätsverlust.

Dies deckt sich mit dem, was Produktionsumgebungen berichten: Das Hybrid-Router-Muster, bei dem 80-90% der Anfragen an Sonnet gehen und nur kritische Aufgaben an Opus eskaliert werden, spart 60-80% der API-Kosten.

Drei Muster, die mir aufgefallen sind und die Benchmarks nicht erfassen

1. Opus ist besser darin zu sagen: "Warte, ich brauche mehr Informationen"

Bei zweideutigen Prompts neigt Sonnet dazu, einen vernünftigen Standard zu wählen und damit zu arbeiten. Opus hält inne und fragt nach. Das ist unglaublich wertvoll für architektonische Arbeit, aber leicht nervig für Routineaufgaben, bei denen man einfach nur möchte, dass es eine Entscheidung trifft und weitermacht.

2. Sonnet ist besser darin, Anweisungen wörtlich zu befolgen

Wenn ich eine detaillierte Spezifikation gab, baute Sonnet exakt das, was ich verlangte. Opus "verbesserte" manchmal Dinge, nach denen ich nicht gefragt hatte — fügte Abstraktionsebenen hinzu, schlug Muster vor, berücksichtigte Edge Cases außerhalb des Scopes. Für Aufgaben, bei denen man Konformität statt Kreativität wünscht, gewinnt Sonnet.

3. Der Qualitätsunterschied vergrößert sich mit der Kontextlänge

Bei Aufgaben unter 10K tokens Kontext konnte ich die Modelle kaum auseinanderhalten. Sobald der Kontext 30K tokens überschritt — große Refactorings, dateiübergreifende Reviews — wurde Opus spürbar kohärenter. Dies entspricht dem 76% Score von Opus 4.6 beim MRCR v2 für Multi-File-Reasoning in langen Kontexten.

Wo die Benchmarks liegen (zur Referenz)

Für diejenigen, die die Zahlen wollen, hier sind die wichtigsten Benchmarks Stand März 2026:

Quellen: Anthropic Modellübersicht, Artificial Analysis, Claude 5 Benchmark-Analyse

Der SWE-bench-Abstand beträgt nur 1.2 Punkte. Aber der GPQA Diamond-Abstand (wissenschaftliches Denken) ist massiv — 17 Punkte. Und der MRCR v2-Abstand (dateiübergreifende Arbeit mit langem Kontext) ist der Punkt, an dem der wirkliche praktische Unterschied liegt.

Meine Empfehlung: Der Entscheidungsrahmen

Nach $500 und drei Wochen Testen ist hier mein Entscheidungsbaum:

Verwenden Sie Sonnet 4.6, wenn:

• Die Aufgabe gut definiert ist mit klaren Anforderungen
• Sie neuen Code von Grund auf schreiben (Endpoints, Komponenten, Skripte)
• Sie eine schnelle Iterationsgeschwindigkeit benötigen (Prototyping, exploratives Coding)
• Sie Tests oder Dokumentation generieren
• Die Kontextlänge unter 20K tokens liegt
• Sie ein begrenztes Budget haben oder ein hohes Anfragevolumen bewältigen

Verwenden Sie Opus 4.6, wenn:

• Die Aufgabe Refactoring über mehrere Dateien hinweg mit komplexen Abhängigkeiten beinhaltet
• Das Modell über Tradeoffs nachdenken soll, bevor es sich auf ein Design festlegt
• Sie nicht offensichtliche Probleme in großen Codebases debuggen
• Sie sicherheitskritischen Code reviewen
• Die Kontextlänge 30K tokens überschreitet und Kohärenz entscheidend ist
• Die Kosten einer falschen Antwort die Kosten des Modellaufrufs übersteigen

Verwenden Sie beide (Hybrid-Router), wenn:

• Sie ein Produktionssystem mit gemischter Aufgabenkomplexität aufbauen
• Sie die 60-80% Kostenersparnis von Sonnet mit dem Sicherheitsnetz von Opus für schwierige Probleme kombinieren möchten

Für Teams, die Entwickler-Tools bauen — wir nutzen eine Version dieses hybriden Ansatzes bei ZBuild — ist das Router-Muster zum Industriestandard für 2026 geworden.

Was ich anders machen würde

Wenn ich dieses Experiment noch einmal durchführen würde, würde ich eine dritte Dimension hinzufügen: die Messung, wie viele Follow-up-Prompts jedes Modell benötigte, um ein produktionsreifes Ergebnis zu erzielen. Mein Bauchgefühl sagt mir, dass dies Opus bei komplexen Aufgaben noch stärker begünstigen würde, da seine Genauigkeit beim ersten Versuch bei dateiübergreifender Arbeit durchweg höher war.

Ich würde außerdem mit aktiviertem Extended Thinking für Opus testen, was Berichten zufolge dessen ohnehin schon starkes Debugging und architektonisches Denken weiter verbessert.

Fazit: Beginnen Sie mit Sonnet 4.6 für alles. Sie werden schnell merken, wenn eine Aufgabe Opus erfordert. Die Aufgaben, die es erfordern, sind spezifisch, relativ selten und wertvoll genug, um den Aufpreis zu rechtfertigen.

Quellen

• Anthropic — Introducing Claude Opus 4.6
• Anthropic — Claude Models Overview
• Anthropic — Claude Pricing
• Artificial Analysis — Claude Sonnet 4.6 Performance
• Claude 5 — Opus 4.6 Benchmark Analysis
• Bind AI — Sonnet 4.6 vs Opus 4.6 for Coding
• Emergent — Claude Sonnet vs Opus 2026
• DEV Community — Opus 4.6 vs Sonnet 4.6 Coding Comparison
• Macaron — Claude Opus 4.6 for Code Review
• Apiyi — Opus 4.6 vs Sonnet 4.6 Comparison Guide
• Medium — Tested Sonnet 4.6 vs Opus 4.6 for Vibe Coding