Claude Sonnet 5 vs GPT-5.5: Vollständiger Vergleich

Kurz gesagt. Claude Sonnet 5 punktet beim Preis (2,5–3 Mal günstiger) und bei der sichereren Positionierung. GPT-5.5 punktet bei einigen Benchmarks für Agenten und Knowledge Work und bietet eine breitere Unterstützung für Tools in der Responses API (integrierte Bildgenerierung, gehostete Shell, Tool-Suche). Ein direkter Benchmark-Vergleich wird dadurch erschwert, dass die Modelle mit zwei Monaten Unterschied veröffentlicht wurden und auf unterschiedlichen Benchmark-Versionen getestet wurden – ich kennzeichne dies separat, wo der Vergleich nicht korrekt ist.

Eine vollständige technische Analyse des Sonnet 5-Modells selbst – Architektur, Aufwand, Benchmarks, Einschränkungen – habe ich bereits in einer separaten Übersicht geschrieben. Hier – nur ein direkter Vergleich mit GPT-5.5, ohne Wiederholung dessen, was dort bereits analysiert wurde.

Inhalt

• Preis und API-Limits
• Kontextfenster und Arbeit mit langen Dokumenten
• Programmier-Benchmarks
• Agentenfunktionen und Computernutzung
• Generierungsgeschwindigkeit und Latenz
• Sicherheit, Einschränkungen und Schutzmechanismen
• Multimodalität und Tool-Unterstützung
• Vergleichstabelle
• Was wählt man für die Codierung
• Was wählt man für die Agentenautomatisierung
• Was wählt man für Teams mit begrenztem Budget
• Häufig gestellte Fragen

Preis und API-Limits

Hier ist der Unterschied am eindeutigsten von allen Vergleichen. GPT-5.5 kostet 5 US-Dollar pro Million Eingabetoken und 30 US-Dollar pro Million Ausgabetoken. Sonnet 5 zum Standardpreis – 3/15 US-Dollar, und bis zum 31. August 2026 gilt ein Einführungspreis von 2/10 US-Dollar.

Der zweite Punkt, der oft übersehen wird: Bei GPT-5.5 wird der Aufschlag für langen Kontext für die *gesamte Sitzung* berechnet, sobald die Eingabe 272K Token überschreitet – das bedeutet, die Arbeit mit großen Codebasen oder Dokumenten oberhalb dieser Schwelle kostet doppelt so viel für die Eingabe. Bei Sonnet 5 gibt es diese Schwelle überhaupt nicht: Eine Anfrage über 900K Token wird genauso abgerechnet wie eine Anfrage über 9K.

Kontextfenster und Arbeit mit langen Dokumenten

Formell sind beide Modelle als "1M-Kontext" deklariert, aber die Details unterscheiden sich erheblich – und gerade in den Details liegt der tatsächliche Unterschied für die produktive Nutzung. Sonnet 5 bietet genau 1 Million Eingabetoken + bis zu 128K Ausgabetoken, ohne Schwellenwerte innerhalb des Fensters: Dies ist sowohl der Standardwert als auch das Maximum, es gibt keine separate "kleinere" Modellvariante. GPT-5.5 hat in der API 1,05 Millionen Token (922K Eingabe + 128K Ausgabe), und in Codex nur 400K, d.h. der größte Kontext ist nicht in allen Produktbereichen verfügbar: Ein Entwickler, der über Codex und nicht direkt über die API arbeitet, erhält physisch nicht die deklarierten Millionen Token.

Die zweite Ebene der Unterschiede – die Abrechnung innerhalb des Fensters selbst. Bei GPT-5.5 steigt der Preis für die gesamte Anfrage (nicht nur für die Token über dem Schwellenwert), sobald die Eingabe 272K Token überschreitet, um das Doppelte für die Eingabe und das 1,5-fache für die Ausgabe. Bei Sonnet 5 gibt es diese Schwelle überhaupt nicht: Eine Anfrage über 900K Token wird zum gleichen Token-Preis abgerechnet wie eine Anfrage über 9K.

Warum das in der Praxis wichtig ist. Eine Million Kontext-Token ist eine Marketingzahl für die "Kapazität", keine Garantie dafür, dass das Modell über die gesamte Länge gleich gut funktioniert. Ich habe die Mechanismen der Qualitätsverschlechterung bei langem Kontext – warum Modelle "vergessen" und wie die tatsächlichen Kosten solcher Arbeit berechnet werden – bereits in einem separaten Artikel detaillierter analysiert: LLM-Kontextfenster: Warum KI vergisst und was es kostet. Kurz gesagt: Allein die Existenz eines großen Fensters befreit nicht von der Notwendigkeit, zu planen, was genau hineingelegt werden soll – "reiner" Kontext liefert immer bessere Ergebnisse als "rauschender", auch wenn technisch beides passt.

Für den Vergleich von Sonnet 5 und GPT-5.5 ergeben sich daraus zwei praktische Konsequenzen. Erstens ist die Preisschwelle von 272K bei GPT-5.5 kein abstraktes Detail der Preisliste, sondern ein realer architektonischer Faktor: Wenn Ihre typische Anfrage (z. B. Analyse einer mittelgroßen Codebasis oder eines Vertragspakets) diese Grenze regelmäßig überschreitet, können die Gesamtkosten genau dann, wenn der Kontext am dringendsten benötigt wird – also bei den schwierigsten, größten Aufgaben – um das Doppelte steigen. Zweitens bedeutet der Unterschied zwischen 1 Mio. in der API und 400K in Codex, dass die Wahl der OpenAI-Produktplattform (nicht des Modells selbst) direkt bestimmt, welchen Teil der deklarierten Kapazität Sie tatsächlich erhalten – dies sollte überprüft werden, bevor die Architektur auf "eine Million Token" ausgelegt wird.

Fazit: Für Aufgaben, bei denen langer Kontext ständig und aktiv genutzt wird (und nicht als einmalige Möglichkeit "für den Notfall"), bietet die Ökonomie von Sonnet 5 – ohne Schwellenwerte und ohne Bindung an eine bestimmte Produktplattform – eine besser vorhersehbare Kostenkontrolle, auch wenn die Rohzahl des Kontexts bei GPT-5.5 formal etwas höher ist.

Programmier-Benchmarks

Wichtiger Hinweis vor den Zahlen: GPT-5.5 wurde am 23. April 2026 veröffentlicht, Sonnet 5 am 30. Juni 2026, und jedes Labor veröffentlichte seine eigenen Ergebnisse zu seinem jeweiligen Zeitpunkt, oft auf verschiedenen Versionen von Benchmarks. Wo sich die Versionen unterscheiden (z. B. Terminal-Bench 2.0 vs. 2.1), kennzeichne ich dies separat – ein direkter Vergleich solcher Zahlen ist nicht korrekt.

Beim SWE-bench Pro – der anspruchsvollsten und kontaminationsresistentesten Variante des Code-Benchmarks – liegt Sonnet 5 etwa 4,5 Punkte vor GPT-5.5. Für GPT-5.5 ist jedoch der eigene interne OpenAI Expert-SWE-Benchmark (Aufgaben mit einer medianen menschlichen Bearbeitungszeit von 20 Stunden) aussagekräftiger, wo das Modell 73,1 % erreicht – ein direkter Analogon dieses Benchmarks gibt es in den Materialien von Anthropic nicht, daher kann es nicht korrekt mit einer Zahl von Sonnet 5 verglichen werden.

Praktisches Fazit: Bei "klassischen" SWE-bench-Aufgaben hat Sonnet 5 laut offiziellen Zahlen die Nase vorn. Für lange, mehrtägige Ingenieuraufgaben (was Expert-SWE misst) gibt es jedoch keine direkten vergleichbaren Daten – hier würde ich mich auf eigene Tests verlassen und nicht auf Benchmarks aus Pressemitteilungen beider Unternehmen.

Agentenfunktionen und Computernutzung

Beim OSWorld-Verified – einem Benchmark zur Steuerung einer realen Desktop-Umgebung (das Modell öffnet Anwendungen, klickt, füllt Formulare aus, navigiert in Benutzeroberflächen, die es noch nie zuvor gesehen hat) – zeigt Sonnet 5 81,2 % im Vergleich zu 78,7 % bei GPT-5.5. Der Unterschied ist gering (2,5 Punkte) und statistisch nicht kritisch, daher würde ich daraus nicht den Schluss ziehen, dass "Sonnet 5 objektiv besser in der Computernutzung ist" – es ist korrekter zu sagen, dass beide Modelle eng beieinander liegen und beide Labore diesen Erfolg als Übergang der Computernutzung vom experimentellen zum produktionsreifen Status bezeichnen.

Warum das wichtig ist. Bis zu dieser Modellgeneration war Computernutzung eher eine Demo-Funktion: Der Agent konnte "zeigen", dass er auf den Bildschirm klicken kann, aber für reale Produktions-Workflows (Ausfüllen von Formularen in Unternehmens-CRMs, Navigation in internen Systemen ohne API) war die Genauigkeit nicht ausreichend, um ohne ständige menschliche Aufsicht gestartet zu werden. Ein Wert von über 78-80 % bei OSWorld-Verified ist die Schwelle, ab der die Automatisierung von Browseraufgaben wirtschaftlich rentabel wird, bei einer vernünftigen Fehlerrate, und nicht nur ein interessantes Experiment.

Beim Knowledge-Work-Benchmark GDPval gibt GPT-5.5 84,9 % an – formal höher als der Wert von Sonnet 5 auf dem verwandten GDPval-AA v2 (1618 Elo), aber der Unterschied in der Bewertungsform (Prozent vs. Elo-Bewertung) erlaubt keine Zusammenführung zu einer einzigen Zahl und keinen direkten Vergleich. Beide Unternehmen verwenden leicht unterschiedliche Varianten dieses Benchmarks, daher würde ich daraus keinen direkten Schluss ziehen wie "GPT-5.5 ist besser im Knowledge Work" – es ist korrekter zu sagen, dass beide Modelle starke Ergebnisse nach ihren eigenen Methoden erzielen, die nicht direkt auf eine Skala gebracht werden können.

Ein praktischer Unterschied, der sich nicht auf Benchmarks reduzieren lässt: GPT-5.5 unterstützt in der Responses API sofort eine breitere Palette von serverseitigen Tools "out of the box" – gehostete Shell, Tool-Suche, integrierte Bildgenerierung, Dateisuche – während im Claude-Ökosystem ein Teil dieser Funktionalität über separate Integrationen und MCP realisiert wird. Wenn der Agent genau diese breite Palette integrierter Tools ohne zusätzliche Integrationsarbeit benötigt, ist dies ein echter praktischer Vorteil von GPT-5.5 außerhalb von Benchmarks.

Warum das praktisch wichtig ist – und wo die Falle lauert. Mehr integrierte Tools "out of the box" klingt nach einem eindeutigen Vorteil, aber in der Praxis ist eine große Anzahl verfügbarer Tool-Definitionen im Kontext eines Agenten ein separates Problem, das unabhängig von der gewählten Modellwahl ist. Ich habe dies ausführlich in dem Artikel Tool RAG: Was tun, wenn ein Agent zu viele Tools hat behandelt – kurz gesagt, jedes hinzugefügte Tool verbraucht einen Teil des Kontextfensters für seine Definition (Name, Beschreibung, Parameter-Schema), und das Modell wählt schlechter den richtigen Aufruf, wenn zu viele Tools gleichzeitig vorhanden sind. Das bedeutet, dass der breitere Satz serverseitiger Tools in GPT-5.5 nützlich ist, solange der Agent sie tatsächlich nutzt und nicht "vorsorglich" einbindet – andernfalls kann der Effekt umgekehrt sein.

Wenn Ihr Agenten-Stack nicht an einen bestimmten Cloud-Anbieter gebunden ist und Sie zwischen lokalen Modellen für Tool-Calling wählen (z. B. über Ollama) – die Frage "welches Modell ruft Tools besser auf" reduziert sich nicht nur auf Sonnet 5 vs. GPT-5.5. Einen Vergleich lokaler Modelle hinsichtlich der Tool-Calling-Qualität mit echten Benchmarks habe ich in einem separaten Artikel zusammengestellt: Welches Ollama-Modell für einen Agenten mit Tool-Calling wählen – nützlich als Referenzpunkt, wenn ein Teil Ihrer Agenten-Pipeline lokal läuft und ein Cloud-Modell (Sonnet 5 oder GPT-5.5) nur für die schwierigsten Schritte hinzugezogen wird.

Generierungsgeschwindigkeit und Latenz

OpenAI betont, dass GPT-5.5 trotz höherer "Intelligenz" die gleiche Per-Token-Latenz wie GPT-5.4 beibehält – und bietet zusätzlich einen Fast-Modus, der Token 1,5-mal schneller für die 2,5-fache Gebühr generiert. Bei Sonnet 5 gibt es keinen vergleichbaren separaten "Schnellmodus" – die Geschwindigkeit wird durch das Aufwandniveau (effort level) gesteuert: niedrigere Stufen (low, medium) ergeben eine deutlich geringere Latenz als xhigh, bei dem unabhängige Messungen eine erhöhte Zeit bis zum ersten Token aufgrund tieferer interner Überlegungen feststellen.

Ein direkter Vergleich von "Tokens pro Sekunde" zwischen den Modellen ist ohne die Festlegung gleicher Bedingungen (Anbieter, Aufwand/Reasoning-Level, Anfrage-Länge) nicht korrekt – beide Unternehmen sprechen über Geschwindigkeit in ihren eigenen Begriffen, die ohne unabhängiges Benchmarking auf derselben Hardware nicht in einer Tabelle zusammengefasst werden können.

Sicherheit, Einschränkungen und Guardrails

Hier ist der Ansatz der Labore diametral entgegengesetzt. Anthropic hält die Cyberfähigkeiten von Sonnet 5 bewusst niedrig: In einem gemeinsamen Test mit Mozilla zu Schwachstellen in Firefox 147 hat das Modell keinen einzigen funktionierenden Exploit erstellt, und für cybersicherheitsbezogene Arbeiten, die reduzierte Einschränkungen erfordern, empfiehlt das Unternehmen ausdrücklich Opus 4.8 und nicht Sonnet 5.

OpenAI bewertet hingegen die Cyberfähigkeiten von GPT-5.5 nach seinem eigenen Preparedness Framework als "High" und implementiert sofort verstärkte Klassifikatoren und Trusted Access for Cyber – ein erweitertes Zugangsprogramm für verifizierte Verteidiger. Unabhängige Tester stellten ebenfalls eine Erfolgsquote von 93 % im internen Cyber-Range fest und entdeckten einen universellen Jailbreak nach sechs Stunden Red-Teaming – das Modell ist also in diesem Bereich leistungsfähiger, erfordert aber auch einen komplexeren Eindämmungskreis.

Ein weiterer Sicherheitspunkt: Apollo Research stellte fest, dass GPT-5.5 in 29 % der Stichproben über die Erfüllung einer objektiv unmöglichen Programmieraufgabe "lügt" – ein Anstieg von 7 % bei GPT-5.4. Ein direktes Äquivalent dieses Tests für Sonnet 5 gibt es in den öffentlichen Materialien von Anthropic nicht, daher kann ich keinen direkten Vergleich anstellen – aber die Tatsache des Anstiegs des Wertes bei GPT-5.5 sollte berücksichtigt werden, wenn Ihr Agenten-Workflow auf ehrlichen Berichten des Modells über die Aufgabenerfüllung ohne separate Ergebnisverifizierung basiert.

Für Teams, bei denen ein vorhersehbares, konservatives Modellverhalten im Agentenzyklus (und nicht maximale Rohkapazität) entscheidend ist – erscheint Sonnet 5 standardmäßig als die sicherere Wahl.

Multimodalität und Tool-Unterstützung

Interessante Übereinstimmung: Beide Modelle wiederholen sich fast wortwörtlich in der Nomenklatur der Aufwand-Level (low/medium/high/xhigh sind für beide gemeinsam, Sonnet 5 fügt max hinzu, GPT-5.5 fügt none für die vollständige Deaktivierung des Reasoning hinzu). Dies spricht eher für eine Konvergenz der Branche zu einem einzigen mentalen Modell von "gesteuerter Denktiefe" als für eine Übernahme in irgendeine Richtung.

Zusammenfassende Vergleichstabelle

Was soll man für das Codieren wählen

Hier werde ich mich nicht darauf beschränken, die Benchmarks anderer wiederzugeben – ich habe beide Modelle selbst durch meine eigenen Aufgaben laufen lassen, bevor ich diesen Abschnitt geschrieben habe, da ich selbst dieselbe Frage beantworte: Worauf soll ich die Hauptagentenschleife in meinen eigenen Spring Boot-Projekten aufbauen.

Für klassische Aufgaben im Stil von SWE-bench (Behebung von Fehlern in realen Repositories, Überprüfung, Refactoring) hat Sonnet 5 laut offiziellen Zahlen und zu einem deutlich niedrigeren Preis für die gleiche Arbeitsmenge einen Vorteil. In meinen eigenen Tests auf der Codebasis von AskYourDocs (Spring Boot, Spring AI, Arbeit mit pgvector) habe ich dieselben Aufgaben durch beide Modelle laufen lassen – die Behebung eines Fehlers bei der Indizierung von Chunks und ein kleines Refactoring der Service-Schicht. Sonnet 5 hat die Aufgabe konsequent ohne Zwischenaufforderungen abgeschlossen und, was für mich wichtiger ist, selbst einen Test geschrieben, der das Problem reproduziert, bevor er eine Lösung vorschlug – dasselbe, was ich bereits in der Überprüfung des Modells selbst beschrieben habe. GPT-5.5 lieferte bei denselben Aufgaben ebenfalls ein funktionierendes Ergebnis, benötigte aber häufiger eine klärende Aufforderung auf halbem Weg, wenn der Kontext der Aufgabe aus der Anfrage selbst nicht vollständig ersichtlich war.

Dies ist kein strenger Benchmark – es sind zwei bis drei reale Fälle und nicht tausend Aufgaben mit einer kontrollierten Methodik, daher gebe ich dies nicht als wissenschaftlichen Beweis für einen Vorteil aus. Aber die Richtung stimmt mit den offiziellen Zahlen von SWE-bench Pro überein, und deshalb vertraue ich diesen Zahlen mehr, als wenn sie meiner eigenen Erfahrung widersprechen würden.

Für lange, mehrtägige Ingenieurssitzungen, bei denen GPT-5.5 auf seinem eigenen Expert-SWE starke Ergebnisse erzielt, habe ich keine vergleichbaren Daten – ich habe keine 20-Stunden-Aufgaben mit einem der Modelle durchgeführt und sage dies ehrlich, anstatt nachträglich eine Zahl zu erfinden. Hier gibt es grundsätzlich keine direkten vergleichbaren Daten, da OpenAI dieses Szenario in seinem internen Benchmark misst, für das Anthropic kein direktes Äquivalent hat.

Mein Fazit nach eigenen Tests: Für die tägliche Arbeit an Fehlern, Überprüfungen und Refactoring im realen Produktionscode würde ich Sonnet 5 wählen – sowohl wegen des subjektiven Gefühls, "die Aufgabe abzuschließen", als auch wegen des Preises, der bei häufiger Nutzung deutlich spürbarer ist als bei einem einmaligen Test. Wenn Ihr Hauptszenario jedoch lange, mehrtägige Agentensitzungen über eine große Codebasis sind, würde ich mich nicht auf meine Erfahrung oder die Benchmarks eines der Unternehmen verlassen – hier sollten Sie einen Tag einplanen und beide Modelle für Ihre eigene Aufgabe aus dem Backlog durchlaufen lassen, da dies genau das Szenario ist, für das ich selbst noch nicht genügend Daten für eine sichere Schlussfolgerung habe.

Was soll man für die Agentenautomatisierung wählen

Bei der Computernutzung sind beide Modelle nah beieinander (81,2 % gegenüber 78,7 %), daher ist nicht die rohe Genauigkeit der entscheidende Faktor, sondern das Ökosystem der Werkzeuge und die Kosten der Massenausführung. Wenn der Agent aktiv die integrierten serverseitigen Werkzeuge von OpenAI (gehostete Shell, Werkzeugsuche, Bildgenerierung) nutzt, ohne sie separat integrieren zu wollen – spricht dies für GPT-5.5. Wenn das Hauptkriterium die Kosten für Tausende von Agentenaufrufen pro Monat und ein vorhersehbares, konservatives Modellverhalten sind – hat Sonnet 5 die Nase vorn.

Was soll man für Teams mit begrenztem Budget wählen

Hier ist die Wahl eindeutig. Sonnet 5 kostet zum Startpreis 2,5-mal weniger für Eingabetoken und 3-mal weniger für Ausgabetoken, und zum Standardpreis ist es immer noch 1,7–2-mal günstiger. Hinzu kommt, dass es keinen Aufschlag für langen Kontext gibt (während GPT-5.5 die Kosten für Eingaben über 272K Token verdoppelt) – und für jedes High-Volume-Szenario (Massen-RAG-Anfragen, Produktionsagenten mit vielen täglichen Aufrufen) ist die Wirtschaftlichkeit eindeutig auf der Seite von Sonnet 5.

Häufig gestellte Fragen

Welches Modell ist günstiger – Claude Sonnet 5 oder GPT-5.5?
Claude Sonnet 5. Zum Startpreis von 2 $/10 $ ist es 2,5–3-mal günstiger als GPT-5.5 (5 $/30 $), zum Standardpreis (3 $/15 $) – 1,7–2-mal.

Welches Modell ist besser für das Codieren?
Auf SWE-bench Pro liegt Sonnet 5 vorn (63,2 % gegenüber 58,6 %). Bei langen, mehrtägigen Aufgaben gibt es keine direkten vergleichbaren Daten – ich empfehle, es mit Ihrem eigenen Code zu testen.

Welches Modell hat ein größeres Kontextfenster?
Formal hat GPT-5.5 etwas mehr (1,05 Mio. gegenüber 1 Mio.), aber ohne Aufschlag für die Länge ist Sonnet 5 wirtschaftlicher für die tatsächliche Nutzung eines großen Kontexts.

Welches Modell ist sicherer für Agentenaufgaben?
Sonnet 5 hält bewusst geringere Cyberfähigkeiten aufrecht und zeigt laut Anthropic eine geringere unerwünschte Verhaltensweise. GPT-5.5 ist in diesem Bereich leistungsfähiger, erfordert aber einen komplexeren Eindämmungskontrollmechanismus seitens des Benutzers.

Lesen Sie auch:

• Claude Sonnet 5: Vollständige Übersicht über das Modell von Anthropic
• Claude Sonnet 5 vs Gemini 3
• Claude Sonnet 5 vs Kimi K2.5
• Claude Sonnet 5: Nachteile und Nutzerbewertungen