DeepSWE Information Hub
Kostenlose KI-Bilder

DeepSWE-Benchmark: Warum GPT Claude bei langfristigen Coding-Aufgaben führt

GPT vs Claude Opus-4.8-Ergebnis ansehen

Warum zeigt DeepSWE, dass GPT Claude übertrifft?

Grund Erklärung
Vollständigere Abdeckung der Anforderungen GPT übersieht ausdrückliche Prompt-Anforderungen seltener, besonders wenn eine Aufgabe mehrere Zweige hat.
Stabilere Interpretation Über wiederholte Läufe derselben Aufgabe hinweg konvergiert GPT häufiger zu demselben Verständnis.
Stärkeres langfristiges Engineering DeepSWE kombiniert kurze Prompts mit langen Implementierungen und mehrdateigen Änderungen, und GPT-5.5 führt in diesem Setting.
Bessere Effizienz GPT-5.5 führt beim Score und sieht zugleich bei Token-, Zeit- und Kosteneffizienz stark aus.
Weniger abhängig von Benchmark-Leakage Durch das Entfernen von Gold-Commit-Leakage nimmt DeepSWE einen Teil des Vorteils weg, den Claude in älteren Benchmarks zeigte.

Erstens setzt GPT in DeepSWE die vollständige Anfrage besser um, nicht nur den offensichtlichsten Teil.

DeepSWE-Aufgaben sind oft mehr als ein einfacher Bugfix. Sie verlangen regelmäßig, mehrere parallele Fälle zugleich zu behandeln: den synchronen und den asynchronen Pfad zu unterstützen oder ein Eingabeformat und ein eng verwandtes Format zu verarbeiten. Datacurves Analyse ergab, dass Claude oft eine Lösung erzeugte, die fast korrekt aussah, aber dennoch einen Zweig ausließ. Einfach gesagt: Der Hauptpfad kann stimmen, während dieselbe Logik im zweiten Szenario fehlt. GPT-5.5 hatte dagegen in DeepSWE die niedrigste Rate ausgelassener ausdrücklicher Anforderungen, mit GPT-5.4 dicht dahinter. Das legt nahe, dass GPT jede Anforderung im Prompt besser in tatsächliche Codeänderungen übersetzt.

Screenshot zwischen dem ersten und zweiten DeepSWE-Vergleichspunkt

Zweitens ist GPTs Aufgabenverständnis konsistenter und weniger vom Glück abhängig.

DeepSWE fragt nicht nur, ob ein Modell einmal besteht. Es betrachtet auch, wie dasselbe Modell über mehrere Läufe derselben Aufgabe hinweg reagiert. Datacurve sagt, GPT neige dazu, von Lauf zu Lauf zu einer ähnlichen Interpretation und Implementierungsrichtung zu konvergieren. Das zählt in realer Entwicklung, weil Nutzer einen Coding-Agenten wollen, den sie vorhersagen können, nicht einen, der die Aufgabe in einem Lauf als A und im nächsten als B liest. GPT folgt eher eng dem Prompt des Nutzers und arbeitet innerhalb der Interfaces und Struktur, die im Repository bereits existieren. Das macht seine Ausgabe leichter vorhersehbar, prüfbar und wiederverwendbar.

Drittens ist DeepSWE ein stärkerer Test für langfristiges Engineering, und GPT schneidet in diesem Setting besser ab.

DeepSWE ist schwierig, weil die Prompts nicht lang sind, die eigentliche Implementierungsarbeit aber oft schon. Der durchschnittliche Prompt hat nur 2.158 Zeichen, kürzer als die 4.614 von SWE-Bench Pro. Die durchschnittliche Referenzlösung in DeepSWE fügt jedoch 668 Codezeilen hinzu und berührt 7 Dateien, gegenüber 120 Zeilen und 5 Dateien in SWE-Bench Pro. Das Modell kann sich also nicht auf detaillierte Schritt-für-Schritt-Anweisungen verlassen. Es muss die Codebasis lesen, die richtigen Einstiegspunkte finden, die Projektstruktur verstehen, dateiübergreifend ändern und vermeiden, bestehendes Verhalten zu brechen. GPT-5.5 erzielt genau in dieser Mischung aus kurzem Prompt, langem Ausführungspfad und mehrdateiger Änderung den Spitzenwert. Das ist ein starkes Zeichen, dass es für realistische Engineering-Arbeit besser geeignet ist.

Viertens erzielt GPT nicht nur höhere Scores. Es ist auch effizienter.

DeepSWE vergleicht mehr als die Erfolgsrate. Es verfolgt auch, wie viele Tokens, wie viel Zeit und welche Kosten ein Modell für eine Aufgabe verbraucht. Datacurve berichtet, dass GPT-5.5 die höchste Erfolgsrate von 70 % erreicht und zugleich eine mediane Output-Länge von 47k Tokens erzielt, die beste Token-Effizienz in der Grafik. Die mediane Abschlusszeit beträgt 20 Minuten, ebenfalls stark unter den Modellen mit hohen Scores. Bei den Kosten sind GPT-5.4 und GPT-5.5 in der Abbildung als die kosteneffizientesten Konfigurationen markiert. Mit anderen Worten: GPTs Vorsprung entsteht nicht dadurch, dass es die Aufgabe mit mehr Output, mehr Laufzeit oder mehr Budget brute-forced. Er entsteht aus einer besseren Balance zwischen Genauigkeit und Ressourceneinsatz.

Fünftens reduziert DeepSWE Benchmark-Leakage, wodurch GPTs zugrunde liegende Fähigkeit klarer sichtbar wird.

Datacurve betont, dass DeepSWE-Aufgaben von Grund auf neu geschrieben werden, statt direkt aus bestehenden GitHub-Commits, Pull Requests oder öffentlichen Patches abgeleitet zu sein, und dass diese Aufgaben nicht in die Originalprojekte zurückgemergt werden. Dadurch wird es deutlich schwerer für ein Modell, die Antwort aus gemerkten Trainingsdaten oder öffentlicher Historie zu erraten. Das unterscheidet sich von einigen älteren Benchmarks. In seiner Analyse von SWE-Bench Pro fand Datacurve, dass einige Aufgaben ein Gold-Commit-Leakage-Risiko hatten und manche Agenten den Originalfix aus der Git-Historie wiederfinden konnten. Claude-Opus-Konfigurationen zeigten dieses Verhalten in der SWE-Bench-Pro-Stichprobe häufiger, GPT-5.4 und GPT-5.5 dagegen nicht. Wenn diese Abkürzung entfernt ist, sieht DeepSWE eher wie ein Test aus, ob ein Modell ein wirklich neues Problem lösen kann, statt ob es die Antwort schon einmal gesehen hat.

Hat Opus 4.8 GPT-5.5 auf DeepSWE eingeholt?

Aktuell enthält DeepSWE Claude Opus 4.8. Das Fazit ist ziemlich klar: Opus 4.8 hat sich verbessert, hat GPT-5.5 aber nicht überholt. Die stärkste Opus-4.8-[max]-Einstellung erreicht 58 % ±5 %, unter GPT-5.5 [xhigh] mit 70 % ±4 %; sie liegt näher an GPT-5.4 [xhigh] mit 56 % ±5 % und Opus 4.7 [max] mit 54 % ±5 %.

Aus der Grafik unten:

DeepSWE-Tabelle, die Claude Opus 4.8, Claude Opus 4.7 und GPT-5.5 über Effort-Einstellungen, Erfolgsrate, Kosten, Output-Tokens und Zeit vergleicht.
Opus 4.8, Opus 4.7 und GPT-5.5 im Vergleich nach Effort, Kosten, Laufzeit und Tokens.
  • Setzen Sie Opus 4.8 nicht standardmäßig auf max. Opus 4.8 steigt von medium über high zu max, mit Scores von 47 % → 51 % → 58 %. Aber die durchschnittlichen Kosten von max springen von 3,98 $ bei high auf 12,58 $, der durchschnittliche Output wächst von 48k auf 136k Tokens, und die Laufzeit steigt von etwa 21 Minuten auf 44 Minuten. Anders gesagt: max ist stärker, aber der teure letzte Gang. Nutzen Sie ihn für hochwertige Aufgaben mit hohen Fehlerkosten und langfristiger Exploration, nicht als Standard für jedes Alltags-Issue.
  • Der Fortschritt von Opus 4.8 liegt vor allem darin, Opus 4.7 max zu übertreffen und dabei stärker sowie günstiger zu sein. Opus 4.8 [max] liegt bei 58 %, Opus 4.7 [max] bei 54 %; zugleich kostet Opus 4.8 [max] im Durchschnitt 12,58 $, weniger als Opus 4.7 [max] mit 18,19 $. Das heißt nicht, dass 4.8 keine Verbesserung ist. Es heißt, dass die Verbesserung eher nach Effizienz- und Obergrenzengewinnen entlang derselben Route aussieht, nicht nach einem direkten Umsturz von GPT-5.5.
  • Der Vorteil von GPT-5.5 ist die Effizienz-Basislinie. Die Grafik nutzt GPT-5.5 [medium], nicht das führende GPT-5.5 [xhigh] aus dem Leaderboard. Trotzdem liegt GPT-5.5 [medium] bereits bei 48 %, mit 2,34 $ Kosten, 10 min 53 s Laufzeit und 18,6k Output-Tokens. Es ist nah an Opus 4.8 [medium] mit 47 %, aber günstiger, schneller und token-sparsamer. In der Praxis sehen einfache bis mittelkomplexe Coding-Aufgaben eher wie GPT-5.5-Standardrouten aus; Opus 4.8 passt besser zu Aufgaben, die tieferes Reasoning, Lösungsdiskussion und komplexe Kontextbeurteilung brauchen.

Die Reaktionen auf Reddit sind geteilt: Einige Nutzer sagen, DeepSWE sei einer der wenigen Benchmarks, der ihrer praktischen Erfahrung mit GPT-5.5, Opus 4.7 und Opus 4.8 entspricht; in r/developersIndia meinte ein Nutzer, intensive GPT-5.5-Nutzung erkläre durch DeepSWE, warum es sich bei delegierten Aufgaben und /goal stabiler anfühlt. Andere fragen, ob der einheitliche Einsatz von mini-swe-agent die native Obergrenze von Opus drückt. Genauer gesagt: Opus 4.8 hat einen guten Ruf bei Low-Level-C, Assembly, Speicherverwaltung, hoher Nebenläufigkeit, lock-free Arbeit und Lösungsdiskussionen; für Business-Apps, React, SQL und Backend-Implementierung finden viele Nutzer Codex/GPT-5.5 aber weiterhin stabiler bei Codequalität und Verifikation.

Was ist DeepSWE?

Ein Benchmark, der echtes Engineering-Verhalten auf Repository-Ebene testet, nicht nur kurze Coding-Antworten.

DeepSWE ist ein Benchmark zur Bewertung frontier-naher Coding-Agenten bei originalen, langfristigen Software-Engineering-Aufgaben. Er wurde von Datacurve eingeführt, um zu messen, wie gut KI-Agenten realistische Coding-Arbeit bewältigen, die Repository-Erkundung, mehrdateige Änderungen, korrektes Verhalten und Verifikation erfordert.

Anders als Benchmark-Aufgaben, die aus bestehenden Pull Requests oder öffentlichen Commits kopiert werden, sind DeepSWE-Aufgaben von Grund auf neu geschrieben. Datacurve sagt, dieses Design solle Trainingsdaten-Kontamination reduzieren und Problemlösen statt Erinnerung testen.

Wofür wird DeepSWE genutzt?

Es ist nützlich, wenn Teams mehrdateige Implementierung, Verifikation und Zuverlässigkeit unter realen Bedingungen bewerten wollen.

DeepSWE wird genutzt, um KI-Coding-Agenten bei Aufgaben zu vergleichen, die echter Software-Engineering-Arbeit näherkommen als kurze Coding-Rätsel. Es hilft Forschern, Modellanbietern und Engineering-Teams zu sehen, welche Agenten einer kompakten Entwickleranfrage folgen, eine unbekannte Codebasis inspizieren, die Änderung implementieren und bestehendes Verhalten intakt halten können.

Der Benchmark kann auch von Teams ausgeführt werden, die einen neuen Agenten bewerten oder das Leaderboard reproduzieren wollen. Datacurve veröffentlicht den Aufgabenkorpus, Aufgabenmetadaten, das Verifier-Format und Anleitungen zum Ausführen von DeepSWE mit Pier.

Welche Vorteile hat DeepSWE?

Der Benchmark ist darauf ausgelegt, Fähigkeitslücken sichtbar zu machen, die kleinere oder stärker gesättigte Evaluationen verdecken können.

DeepSWE sticht hervor, weil es sich auf originale Aufgaben, breitere Repository-Abdeckung und ergebnisbasierte Verifikation konzentriert. Zusammen machen diese Entscheidungen es zu einem stärkeren Proxy für praktische Coding-Agent-Arbeit als ein Benchmark, der vor allem Erinnerung oder winzige Edits misst.

113 originale Software-Engineering-Aufgaben
91 aktive Open-Source-Repositories
5 Sprachen: TypeScript, Go, Python, JavaScript, Rust
668 durchschnittlich hinzugefügte Zeilen in der Referenzlösung
1

Originale Aufgaben senken das Kontaminationsrisiko

DeepSWE-Aufgaben sind nicht aus öffentlichen Fixes abgeleitet. Dadurch ist der Score weniger wahrscheinlich ein Zeichen dafür, dass ein Modell die Antwort im Training gesehen hat.

2

Langfristige Aufgaben ähneln agentischer Entwicklung

Datacurve berichtet, dass DeepSWE-Prompts kürzer sind als SWE-Bench-Pro-Prompts, während Referenzlösungen deutlich mehr Code und mehr Dateien erfordern.

3

Breitere Repository-Abdeckung

Das Aufgabenset verteilt sich über viele aktive Repositories, statt sich auf wenige Flaggschiff-Projekte zu konzentrieren. Dadurch wird es zu einem breiteren Proxy für alltägliche Coding-Agent-Arbeit.

4

Verhaltens-Validatoren belohnen korrekte Ergebnisse

DeepSWE-Verifier testen beobachtbares Verhalten statt die interne Implementierungsform. So können verschiedene korrekte Lösungen bestehen.

Wie sehen die DeepSWE-Benchmark-Ergebnisse aus?

Die Hauptgeschichte ist nicht nur die Rangfolge, sondern der Abstand zwischen frontier-nahen Modellfamilien.

Rang Modell DeepSWE-Score Signal
1 GPT-5.5 [xhigh] 70% ± 4% Höchste veröffentlichte Erfolgsrate im offiziellen DeepSWE-Leaderboard.
2 Claude Opus 4.8 [max] 58% ± 5% Neuestes Opus-Ergebnis im offiziellen Leaderboard; über Opus 4.7 max, aber weiterhin unter GPT-5.5.
3 GPT-5.4 [xhigh] 56% ± 5% Nahe bei Opus 4.8 innerhalb der angegebenen Spanne und von Datacurve als kosteneffizient gemeldet.
4 Claude Opus 4.7 [max] 54% ± 5% Nahe bei GPT-5.4 innerhalb der angegebenen Spanne, aber jetzt unter Opus 4.8 in diesem Benchmark.
5 Claude Sonnet 4.6 [high] 32% ± 4% Niedrigere Erfolgsrate bei langfristigen DeepSWE-Aufgaben.

Die wichtigste Bedeutung des Ergebnisses ist die Trennung. Datacurve berichtet, dass DeepSWE-Scores zwischen denselben frontier-nahen Modellfamilien deutlich breiter streuen als bei SWE-bench Pro. Das deutet darauf hin, dass langfristige, originale Aufgaben Fähigkeitslücken sichtbar machen können, die kürzere oder gesättigtere öffentliche Benchmarks verdecken.

Was bedeutet das für Coding-Nutzer?

Nutzen Sie den Benchmark als Entscheidungssignal und prüfen Sie die Finalisten anschließend in Ihren eigenen Repositories.

Für Nutzer, die ein KI-Modell zum Programmieren auswählen, weist DeepSWE darauf hin, Modelle anhand der Arbeit zu bewerten, die tatsächlich erledigt werden soll. Wenn Ihre Aufgabe eine mehrdateige Änderung in einem unbekannten Repository ist, kann ein langfristiger Benchmark relevanter sein als ein kurzer Coding-Test oder ein gesättigtes Leaderboard.

Das Ergebnis legt außerdem nahe, dass die Erfolgsrate nicht das einzige praktische Signal ist. Datacurve misst Output-Tokens, Wall-Clock-Zeit und Kosten pro Trial und berichtet, dass mehr Tokens, mehr Zeit oder höhere Kosten nicht konsistent bessere Ergebnisse liefern. Entwickler sollten Zuverlässigkeit, Kosten, Latenz und die Häufigkeit ausgelassener Anforderungen vergleichen.

Ein sinnvoller Workflow ist, DeepSWE als benchmark-spezifischen Datenpunkt zu nutzen und die führenden Modelle anschließend in den eigenen Repositories, Sprachen und Review-Standards zu testen, bevor ein Coding-Assistent standardisiert wird.

Signal 01

Benchmark und Workflow abgleichen

Priorisieren Sie langfristige Evaluationen, wenn Ihre Entwickler vor allem Repository-Erkundung und mehrdateige Änderungen erledigen.

Signal 02

Zuverlässigkeit messen, nicht nur Geschwindigkeit

Verfolgen Sie ausgelassene Anforderungen, Nacharbeit, Kosten und Latenz neben der reinen Erfolgsrate, bevor Sie ein Standardmodell festlegen.

Signal 03

Eigenen Vergleichstest durchführen

Benchmarks grenzen das Feld ein, aber die finale Wahl sollte aus Tests in Ihrem eigenen Repository, mit Ihrem Review-Maßstab und Ihrer Risikotoleranz entstehen.

DeepSWE-Aufgaben und wie man den Benchmark ausführt

Der Benchmark deckt vielfältige Repository-Arbeit ab, und der Quickstart ist für reproduzierbare Agent-Läufe ausgelegt.

Aufgabenabdeckung

Welche Aufgaben sind in DeepSWE enthalten?

DeepSWE enthält 113 stabile Aufgaben über TypeScript-, Go-, Python-, JavaScript- und Rust-Repositories. Von Datacurve veröffentlichte Beispiele umfassen Arbeiten wie das Abbrechen ausstehender Body-Reads beim Shutdown, das Korrigieren der PromQL-Label-Sortierung, das Hinzufügen von Config-Datei-Parsing zu Kommandozeilentools, deterministische Konflikterkennung für Y.Map-Writes sowie XML-Diff-, Patch- und Merge-Operationen.

Laufzeitverhalten Shutdown-Handling, Cancellation, asynchroner Lebenszyklus und regressionssensibles Verhalten.
Datenstrukturen Sortierung, Paginierung, Maps, Snapshots, Schema-Komposition und deterministische Konfliktregeln.
Entwicklerwerkzeuge CLI-Config-Parsing, Manifeste, Linting, Profiling, Caches und generierte Reports.
Quickstart

Wie kann man DeepSWE ausführen?

Datacurve sagt, DeepSWE-Aufgaben seien Harbor-kompatibel und könnten mit Pier ausgeführt werden, einem Framework für sandboxed Coding-Agent-Evaluationen. Der offizielle Quickstart klont das DeepSWE-Repository, installiert Pier und führt dann einen ausgewählten Agenten und ein Modell gegen das Aufgabenverzeichnis aus. 

git clone https://github.com/datacurve-ai/deep-swe
uv tool install git+https://github.com/datacurve-ai/pier

# GPT-5.5 via Codex
export OPENAI_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model openai/gpt-5.5

# Claude Opus 4.7 via Claude Code
export ANTHROPIC_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model anthropic/claude-opus-4-7

Die praktische Schlussfolgerung: Nutzen Sie den veröffentlichten Benchmark, um Kandidaten einzugrenzen, und validieren Sie sie danach in Ihrer eigenen Codebasis, bevor Sie einen Tooling-Standard setzen.