Claude Opus 4.5 vs. Claude Sonnet 4.5: Wann sich ein Aufpreis für die Behebung von Codeproblemen lohnt – und wann nicht

Die Entscheidung lautet nicht, welches Modell besser wirkt, sondern welches Incident mit den niedrigsten Gesamtkosten löst

Ein Vergleich von Claude Opus 4.5 und Claude Sonnet 4.5 für die Softwarewartung setzt eine präzise Fragestellung voraus. Weder der Tokenpreis noch eine isolierte Demonstration oder ein Benchmark-Ergebnis beantworten allein, welche Option für ein Team sinnvoller ist. Die Entscheidungseinheit sollte ein korrekt gelöstes und akzeptiertes Incident sein: eine Änderung, die den Fehlerkontext reproduziert, Ziel- und Regressionstests besteht, den Umfang nicht unangemessen ausweitet und nur eine vertretbare menschliche Prüfung erfordert.

Ein Preisaufschlag für Opus 4.5 wäre in diesem Vergleich nur gerechtfertigt, wenn er sich in einem messbaren operativen Ergebnis niederschlägt. Das kann eine höhere Rate vollständiger Lösungen, weniger Regressionen, weniger Iterationen durch einen Ingenieur oder eine kürzere Zeit bis zu einem akzeptablen Patch sein. Erreicht Sonnet 4.5 dieselben Akzeptanzschwellen zu geringeren Kosten, schafft ein höherer Preis für diese Ticketklasse nicht zwangsläufig zusätzlichen Nutzen.

Die Analyse muss die Inferenzkosten von den Arbeitskosten trennen. Ein günstiges Modell, das unvollständige Patches erzeugt, dessen Diagnose erst nachbearbeitet werden muss oder das Änderungen außerhalb des Auftragsumfangs vornimmt, kann nach Einrechnung von Wiederholungen, Tool-Ausführungen und Prüfung teurer sein. Umgekehrt sollte ein höher tarifiertes Modell keine Anerkennung für einen plausibel wirkenden Patch erhalten, der eine repräsentative Testsuite nicht besteht.

Dieser Beitrag erklärt keinen allgemeinen Sieger. Er schlägt einen lokalen Test vor, mit dem Engineering-Verantwortliche, KI-Plattformteams und Einkäufer auf Grundlage eigener Evidenz entscheiden können. Er ist außerdem mit dem Vergleichsindex, den Profilen von Claude Opus 4.5 und Claude Sonnet 4.5 sowie den Informationen von Anthropic zu den Modellen und ihren Zugangskanälen vereinbar.

Erstellen Sie vor der Modellausführung einen eingefrorenen und reproduzierbaren Korpus

Der Test beginnt mit dem Korpus, nicht mit dem Prompt. Jedes Incident muss einem Repository, einem unveränderlichen Basis-Commit, einer Ausführungsumgebung und einer überprüfbaren Fehlerdefinition zugeordnet sein. Bewahren Sie das ursprüngliche Ticket auf, formulieren Sie jedoch eine Aufgabenfassung, aus der Informationen entfernt werden, die nach dem zu simulierenden Zeitpunkt entstanden sind – etwa ein Link zur bereits bekannten Korrektur oder Kommentare, welche die Lösung verraten.

Erstellen Sie für jeden Fall eine minimale Reproduktion, die auf dem Basis-Commit fehlschlägt, sowie eine Testsuite zur Überprüfung der Korrektur. Die Bewertung muss zwischen einer kosmetischen Änderung und einem funktionalen Fix unterscheiden. Eine belastbare Praxis besteht darin, Tests zu definieren, die vor der Korrektur fehlschlagen sollten, sowie Tests, die bereits erfolgreich waren und weiterhin erfolgreich bleiben müssen. Dieser Ansatz entspricht der Validierungslogik, mit der SWE-bench Verified Lösung und Regression unterscheidet, auch wenn Ergebnisse eines internen Korpus nicht mit denen dieses Benchmarks vermischt werden dürfen.

SWE-bench ist eine nützliche methodische Referenz, aber kein Ersatz für einen lokalen Korpus. Die ursprüngliche Arbeit beschreibt einen Satz von Incidents aus realen Python-Repositories; das hilft, die Anforderungen einer Aufgabe zur Bearbeitung von Repositories einzuordnen. Sprachverteilung, Abhängigkeiten, Alter der Incidents und Bewertungsregeln können jedoch von denen des Teams abweichen. Ein internes Ergebnis muss als internes Ergebnis veröffentlicht werden.

Schließen Sie Tickets ohne hinreichend stabile Reproduktion, Änderungen mit Abhängigkeit von nicht kontrollierbaren externen Diensten, Sicherheitslücken mit besonderem Offenlegungsverfahren sowie Aufgaben aus, deren Akzeptanzkriterium rein subjektiv ist. Das Dokumentieren dieser Ausschlüsse verhindert, dass die finale Stichprobe repräsentativer erscheint, als sie ist.

Halten Sie die Bedingungen gleichwertig, aber setzen Sie Gleichwertigkeit nicht mit Identität gleich

Dokumentieren Sie die exakte Kennung jedes Modells, Datum und Uhrzeit der Ausführung, Zugangskanal, Region oder Endpoint, Infrastrukturprovider, Kontextkonfiguration und die bereitgestellten Tools. Für Opus 4.5 nennt die Anthropic-Dokumentation das API-Modell claude-opus-4-5-20251101. Die Dokumentation zum Modelllebenszyklus sollte zu Beginn jeder Testkampagne geprüft werden, um zu bestätigen, dass beide Kennungen noch aktiv sind, und um Ausmusterungen vorherzusehen.

Die Ankündigung von Sonnet 4.5 dokumentiert den API-Zugang und dessen Einführungspreis für Eingabe- und Ausgabetokens. Diese Angabe genügt nicht für die Berechnung endgültiger Kosten: Die Abrechnung kann vom Kanal, der Cache-Nutzung, der Region, Tools und aktuellen kommerziellen Bedingungen abhängen. Bei Amazon Bedrock beschreibt die Dokumentation des Anbieters beispielsweise Unterschiede zwischen globalen und regionalen Endpoints sowie besondere Verfügbarkeitsbedingungen. Vergleichen Sie keine regionale Ausführung des einen Modells mit einer globalen Ausführung des anderen, ohne diesen Unterschied offenzulegen.

Verwenden Sie denselben Systemprompt, dieselbe Aufgabenbeschreibung, dasselbe Antwortformat, Arbeitsverzeichnis, dieselben Lese- und Schreibrechte, erlaubten Befehle, Netzwerkkonnektivität und Iterationslimits. Wenn ein Modell über einen Modus oder eine Fähigkeit verfügt, die dem anderen Modell im gewählten Kanal nicht zur Verfügung steht, behandeln Sie dies nicht als strikt gleichwertigen Test. Sie können es als separates operatives Szenario messen, müssen es jedoch entsprechend kennzeichnen.

Auch die Wiederholungsrichtlinie und Grenzwerte müssen fixiert werden. Ein Wiederholungsversuch nach einem vorübergehenden Infrastrukturfehler kann angemessen sein; mehrere Neustarts, weil das erste Ergebnis schlecht war, verändern die verfügbare Intervention. Die Regel muss für beide Modelle gelten und alle abrechenbaren Versuche erfassen.

Trennen Sie Tickets nach Schwierigkeit und Fehlermechanismus

Ein globaler Mittelwert kann genau die Information verdecken, welche die Kaufentscheidung bestimmt. Klassifizieren Sie die Fälle, bevor die Modelle ausgeführt werden. Eine erste Schicht kann lokalisierte Korrekturen umfassen: eine fehlerhafte Validierung, einen Randfall oder eine Datentransformation, die auf eine oder wenige Dateien begrenzt ist. Das sind Aufgaben, bei denen ein wirtschaftlicheres Modell die Akzeptanzschwelle früh erreichen kann.

Eine zweite Schicht sollte Fehler enthalten, die das Nachverfolgen von Abhängigkeiten zwischen Modulen erfordern. Dazu gehören etwa Änderungen einer internen Schnittstelle, die Serialisierung, Validierung und entfernte Konsumenten beschädigen, oder Defekte, bei denen das Symptom in einer anderen Schicht als die Ursache auftritt. Hier ist es sinnvoll zu untersuchen, ob eine stärkere Planungs- oder Explorationsfähigkeit Iterationen reduziert; das Ergebnis muss jedoch gemessen und darf nicht aus der Modellkategorie abgeleitet werden.

Die dritte Schicht betrifft mehrdeutige oder schwer reproduzierbare Incidents. Sie können Nebenläufigkeit, gemeinsamen Zustand, besondere Konfigurationen oder unvollständige Anforderungen umfassen. Das Ziel besteht nicht darin, eine lange Erklärung zu belohnen: Es geht darum zu prüfen, ob das Modell überprüfbare Hypothesen formuliert, mit erlaubten Tools Evidenz gewinnt und die Änderung auf die am besten gestützte Ursache begrenzt.

Kennzeichnen Sie zusätzlich Sprache, Repositorygröße, Änderungsfläche, Testtyp und das Vorliegen externer Abhängigkeiten. Mit diesen Merkmalen lässt sich feststellen, ob ein Unterschied auf tatsächliche Schwierigkeit oder auf eine zufällige Konzentration von Tickets in einer Sprache oder einem Modul zurückgeht.

Definieren Sie vollständigen Erfolg, bevor Sie die Ergebnisse sehen

Das Erfolgskriterium muss automatische Validierung und menschliche Prüfung verbinden. Klassifizieren Sie nur einen Patch als vollständigen Erfolg, der Zieltests besteht, einschlägige Regressionstests erhält und die Rubrik zum Umfang erfüllt. Falls das Repository über umfangreiche Tests verfügt, die innerhalb des Budgets durchführbar sind, führen Sie sie aus; andernfalls legen Sie offen, welche Abdeckung ausblieb und weshalb.

Die menschliche Prüfung muss hinsichtlich des Modells verblindet erfolgen. Geben Sie den Prüfenden Diff, erzeugte Diagnose, Testergebnisse und Ticket, aber weder Modellname noch Kosten. Fordern Sie eine klar definierte Entscheidung: akzeptieren, mit kleineren Änderungen akzeptieren, wegen unvollständiger Korrektur ablehnen, wegen Regression ablehnen, wegen übermäßigen Umfangs ablehnen oder eine andere vorab spezifizierte Kategorie.

Es ist sinnvoll, die Kategorie des Teilerfolgs zu bewahren, sie aber nicht zur Aufblähung der Lösungsquote zu verwenden. Ein Patch, der die betroffene Komponente richtig lokalisiert, aber an einem Randfall scheitert, kann für die Untersuchung der Diagnosequalität nützlich sein. Er ist nicht gleichbedeutend mit einem gelösten Incident. Ebenso kann ein korrekter Fix, der ohne Begründung fremde Dateien ändert, genügend Intervention erfordern, um nicht als vollständiger Erfolg zu zählen.

Die Prüfanweisungen müssen untersagen, Änderungen zu akzeptieren, welche Tests deaktivieren, Assertions abschwächen oder nur generische Ausnahmen einführen, um einen Fehler verschwinden zu lassen. Sie müssen außerdem darauf hinweisen, dass ein neuer Test für sich allein die Korrektheit der Implementierung nicht nachweist.

Messen Sie Kosten, Intervention und Ende-zu-Ende-Zeit

Die Hauptmetrik kann als Gesamtkosten des Loses geteilt durch die Zahl akzeptierter vollständiger Erfolge ausgedrückt werden. Berücksichtigen Sie im Zähler Eingabe, Ausgabe, Cache und jeden weiteren für den Kanal geltenden Abrechnungsposten. Addieren Sie Wiederholungen, fehlgeschlagene Aufrufe, gegebenenfalls kostenpflichtige Tool-Nutzung sowie menschliche Prüf- oder Korrekturzeit, wenn die operativen Kosten und nicht nur die API-Kosten entschieden werden sollen.

Berichten Sie außerdem die Quote vollständiger Erfolge, die Quote der Teilerfolge, erkannte Regressionen, die Zahl menschlicher Interventionen und die Ende-zu-Ende-Latenz. Latenz ist nicht zwangsläufig Modellzeit: Ein Agent kann auf Tools warten, Tests wiederholen oder Ressourcen der kontinuierlichen Integration blockieren. Erfassen Sie nach Möglichkeit Inferenz-, Tool- und menschliche Zeit getrennt.

Verwenden Sie zur Bewertung der Diagnose eine einfache Rubrik: Identifikation der Symptome, kausale Hypothese, gewonnene Evidenz, Erklärung der Änderung und bekannte Grenzen. Eine Diagnose kann auch bei einem Fehlschlag nützlich sein, sie muss jedoch bewertet werden, ohne erzählerische Qualität mit Korrektheit zu verwechseln. Die Bewertung sollte Referenzbeispiele enthalten und bei mehreren Prüfenden eine Regel zur Auflösung von Meinungsverschiedenheiten vorsehen.

Berichten Sie Verteilungen und Ergebnisse nach Schicht, nicht nur Mittelwerte. Eine kleine Zahl komplexer Incidents kann die durchschnittlichen Kosten dominieren. Wiederholen Sie außerdem einen Teil oder das gesamte Los: Die Variabilität zwischen Ausführungen kann die Schlussfolgerung verändern, wenn der Unterschied zwischen Modellen klein ist.

Interpretieren Sie den Aufpreis für Opus 4.5 über Schwellenwerte, nicht über Modellprestige

Opus 4.5 würde einen Aufpreis in einer bestimmten Schicht rechtfertigen, wenn seine Verbesserung bei vollständigen Lösungen die zusätzlichen Kosten und den vermiedenen Prüfaufwand ausgleicht. Das könnte bei Incidents mit Beziehungen zwischen Modulen, mehrdeutigen Diagnosen oder kostspieligen Testzyklen der Fall sein, ist aber eine Hypothese, die das Experiment bestätigen muss. Der Vergleich sollte zeigen, wie viele zusätzliche Fälle die Prüfung akzeptiert und welche menschlichen Kosten dadurch entfallen.

Sonnet 4.5 erreicht die operative Schwelle, wenn es die vom Team festgelegte Akzeptanzquote, Regressionsgrenze, Frist und Kostengrenze erfüllt. Bei lokalisierten Korrekturen kann die Entscheidung zugunsten dieses Modells ausfallen, selbst wenn Opus eine höhere Durchschnittsbewertung erreicht, sofern der Unterschied keine relevanten Kosten senkt. Bei schwierigeren Aufgaben kann das Ergebnis gemischt sein: Sonnet für Triage und begrenzte Fixes, Opus für eine definierte Warteschlange von Incidents, welche ein Komplexitätskriterium überschreiten.

Machen Sie aus der Segmentierung keine allein auf Intuition beruhende Regel. Eine anfängliche Richtlinie kann Signale wie die Zahl betroffener Module, das Fehlen einer klaren Reproduktion oder die Notwendigkeit der Analyse umfangreicher Traces verwenden. Anschließend muss sie gegen die Ergebnisse validiert werden. Sagen diese Signale keine ausreichende Verbesserung mit Opus voraus, erhöhen sie nur die Komplexität, ohne die Entscheidung zu verbessern.

Ankündigungen und technische Karten des Anbieters können Informationen über Verfügbarkeit, Konfiguration und interne Bewertungen liefern. Sie ersetzen diesen Test nicht, weil Tools, Repositories, Prompts, Budget und Erfolgsdefinition möglicherweise nicht denen Ihres Teams entsprechen.

Führen Sie Sensitivitätsanalysen durch und legen Sie die Grenzen offen

Wiederholen Sie den Vergleich mit unterschiedlichen Iterationsbudgets, Kontextgrenzen und eingeschränkten Tool-Berechtigungen. Ein Ergebnis, das von einem sehr hohen Budget abhängt, ist möglicherweise nicht auf einen Betrieb mit strikten Grenzen übertragbar. Ebenso darf ein Vorteil, der mit Netzzugang oder einem proprietären Tool beobachtet wird, nicht allein dem Modell zugeschrieben werden.

Fassen Sie Ergebnisse aus SWE-bench Verified, Terminal-Bench oder anderen Bewertungen nicht mit dem internen Ergebnis zusammen. Es ist zulässig, sie als methodischen Kontext darzustellen, wenn der Unterschied bei Korpus und Harness benannt wird, aber nicht als vergleichbare Zeilen derselben Tabelle. Eine Änderung der Tests, Tool-Richtlinie oder Akzeptanzdefinition verändert die gemessene Aufgabe.

Dieser Test weist auch weder Codesicherheit noch Berechtigung zur Auslieferung, Fähigkeit zur kontinuierlichen Wartung oder Leistung in allen Programmiersprachen nach. Ein in einer isolierten Umgebung akzeptierter Patch kann Risiken einführen, die vom Testsatz nicht abgedeckt sind. Die Produktionsentscheidung muss Prüf-, Continuous-Integration- und Change-Management-Kontrollen beibehalten.

Dokumentieren Sie schließlich die verlorenen Fälle: ausgeschlossene Tickets, Infrastrukturfehler, Prüfungen ohne Konsens und instabile Tests. Sie zu verbergen kann die Schlussfolgerung robuster erscheinen lassen, als sie tatsächlich ist. Transparenz ist besonders wichtig, wenn der Kosten- oder Akzeptanzunterschied zwischen den beiden Modellen gering ausfällt.

Abschließende Vorlage für eine wiederholbare Entscheidung

Legen Sie vor der Auswahl das Ziel schriftlich fest: etwa die Kosten je akzeptierter Korrektur von Wartungs-Incidents zu senken, ohne eine Grenze für Regressionen oder Prüfzeit zu überschreiten. Führen Sie anschließend beide Modelle auf demselben eingefrorenen Los aus und veröffentlichen Sie genügend Parameter, damit die Berechnung intern wiederholt werden kann.

Die Schlussfolgerung muss bedingt formuliert sein. Beispielsweise: Sonnet 4.5 ist die Standardoption für die lokalisierte Schicht, weil es die Akzeptanzschwelle zu niedrigeren Gesamtkosten erreicht; Opus 4.5 wird für die modulübergreifende Schicht reserviert, falls die Wiederholung eine ausreichende Verringerung von Ablehnungen oder menschlicher Intervention bestätigt. Bleibt der Unterschied nach Wiederholung des Loses nicht bestehen, lautet die verantwortungsvolle Schlussfolgerung, dass es in dieser Umgebung nicht genügend Evidenz für einen Aufpreis gibt.

Überprüfen Sie die Entscheidung, wenn sich Modellkennungen, anwendbare Preise, der Kanal, verfügbare Tools oder die Zusammensetzung der Incident-Warteschlange ändern. Eine reproduzierbare Bewertung ist keine einmalige Beschaffung: Sie ist eine regelmäßige Kontrolle einer Entscheidung, die von sich entwickelnden Systemen und Bedingungen abhängt.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.