Coding-Agent-Benchmark: Wie stark das Runtime-System die Laufzeit verändert

Vier Coding-Agent-Sitzungen erhielten dasselbe Repository und dieselbe übergeordnete Aufgabe. Jede Sitzung lieferte eine Änderung und bestand ihre gezielt ausgeführten Tests. Die beobachtete Gesamtdauer lag trotzdem zwischen 6:04 und 13:57 Minuten.

Codex mit Luna Max war der kürzeste beobachtete Lauf. DSH mit Qwen 3.8 27B war der kürzeste lokale Lauf. Beide OpenCode-Konfigurationen benötigten mehr Zeit, obwohl OpenCode Qwen das niedrigste gemeldete Gesamt-Tokenvolumen hatte.

Die zentrale Erkenntnis ist deshalb keine allgemeine Modellrangliste. Ein Coding-Agent besteht aus mehr als dem Modell: Systemanweisungen, Skills, Memory, Kontextverwaltung, Cache, Werkzeuge, Nutzereingriffe, Review-Regeln und Tests wirken gemeinsam auf das sichtbare Ergebnis.

Was der Benchmark misst

Die vier Sitzungen starteten mit demselben Repository und derselben abstrakten Aufgabe, mussten aber nicht denselben konkreten Defekt auswählen. Die Luna-Läufe landeten im selben Flashcard-Bereich, wählten jedoch einen unterschiedlichen Patch-Umfang. Die beiden Qwen-Läufe bearbeiteten andere Fehlerbereiche.

Damit vergleicht der Test vollständige Runtime-Profile, nicht vier Modelle unter einer kontrollierten Same-Patch-Bedingung. Diese Unterscheidung ist wichtig: Eine Sitzung kann wegen langsamer Modellgenerierung, zusätzlicher Tool-Arbeit, Review, Kontextkompaktierung oder Wartezeiten länger dauern.

Laufzeit und Tokenvolumen

• Codex · Luna Max: 363,696 Sekunden, 2,031 Millionen gemeldete Tokens, 11/11 Zieltests.
• DSH · Qwen 3.8 27B: 483,641 Sekunden, 1,984 Millionen Tokens, 57 Tool-Aufrufe, 14/14 Tests.
• OpenCode · Luna Max: 773,632 Sekunden, 2,683 Millionen Tokens, 67 Tool-Aufrufe, 11/11 Tests.
• OpenCode · Qwen 100K: 836,954 Sekunden, 1,687 Millionen Tokens, 39 Tool-Aufrufe, 17/17 Tests.

OpenCode Luna benötigte 2,13-mal so lange wie Codex Luna. OpenCode Qwen benötigte 1,73-mal so lange wie DSH Qwen. Gleichzeitig war OpenCode Qwen trotz des kleinsten Gesamt-Tokenvolumens der längste Lauf. Ein niedriger Tokenwert ist daher weder automatisch ein Geschwindigkeits- noch ein Qualitätswert.

Auch die Tokenfelder sind nicht identisch. Codex führt Reasoning als Teil des Outputs. OpenCode trennt Reasoning und kombiniert frische Eingabe mit Cache-Lesen im Promptvolumen. DSH liefert Prompt- und Output-Summen. Die normalisierten Werte beschreiben Arbeitsvolumen, nicht unmittelbar Rechnung, Energiebedarf oder Abonnementlimit.

Cache, Orchestrierung und Review

In beiden OpenCode-Läufen stammten mehr als 91 Prozent des Promptvolumens aus Cache-Lesevorgängen. OpenCode Luna meldete 220.630 frische Input-Tokens und 2.451.456 Cache-Tokens; OpenCode Qwen 145.146 beziehungsweise 1.514.973.

DSH Qwen nutzte 36 Assistentenrunden und 57 Tool-Aufrufe. OpenCode Luna nutzte 32 Runden und 67 Aufrufe, OpenCode Qwen 31 Runden und 39 Aufrufe. Für Codex standen keine direkt vergleichbaren Exportzähler zur Verfügung; deshalb wird Codex in dieser Teilgrafik nicht fälschlich mit null dargestellt.

OpenCode Luna aktivierte Brainstorming, Planerstellung, testgetriebene Entwicklung, Code-Review und Abschlussverifikation. Allein der Reviewer beanspruchte ungefähr 299 Sekunden, also 38,6 Prozent der Gesamtdauer. Dieser Prozess kann bei großen oder riskanten Änderungen wertvoll sein. Bei einem kleinen Fix wurde sein fixer Aufwand jedoch zu einem bedeutenden Teil der Sitzung.

Codex Luna verwendete Karpathy-Guidelines und vorhandenes Working Memory. Diese Eingaben könnten einen kleinen Patch, explizite Annahmen und direkte Verifikation gefördert haben. Ein einzelner Lauf kann ihren isolierten Effekt jedoch nicht messen. Dafür wäre ein eigener Skills-an/Skills-aus-Versuchsarm erforderlich.

Welche Runtime passt zu welcher Aufgabe?

• Für einen kleinen, klar begrenzten Cloud-Modell-Fix war Codex Luna Max der kürzeste beobachtete Pfad.
• Für lokale Qwen-Ausführung war DSH Qwen in diesem Test der schnellere Runtime-Stack.
• OpenCode bleibt sinnvoll, wenn Provider-Portabilität, sichtbare Planung und ein einheitliches Modell-Interface wichtiger sind als minimale Laufzeit.
• Für große Refactorings oder Änderungen mit hohem Regressionsrisiko kann eine explizite Planungs- und Review-Kette ihren Zeitaufschlag rechtfertigen.
• Für Mikroaufgaben sollte ein leichteres Agentenprofil feste Prozesskosten vermeiden, sofern die Risikolage keine zusätzlichen Gates verlangt.

Grenzen und nächster Test

Jede Bedingung lief nur einmal; es gibt keine Varianz oder Konfidenzintervalle. Die Agenten implementierten nicht denselben Patch, die Tokenexporte verwenden unterschiedliche Semantik, und Qwen lief lokal, während Luna Cloud-Infrastruktur nutzte. Auch Testanzahlen sind wegen unterschiedlicher Patch-Umfänge kein Qualitätsranking.

Ein stärkerer Folgetest sollte einen einzigen Defekt, dieselben Akzeptanzkriterien, identische Tools, gleiche Systemanweisungen sowie gleiche Kontext- und Timeout-Grenzen verwenden. Jede Bedingung sollte mindestens dreimal laufen. Für Qwen müssen Hardware, Quantisierung, Kontextlimit, KV-Cache-Format und Generationsdurchsatz dokumentiert werden. Pro-Schritt-Zeitstempel würden Modelllatenz, Toolzeit und Review erstmals sauber trennen.

Evidenz und Markenquellen

Die Messwerte wurden aus vier aufbewahrten Sitzungsexporten rekonstruiert: `lunamax-session.jsonl`, `session.jsonl`, `session-ses_fdda.md` und `session-ses_fdd8.md`.

• OpenAI – offizielle GitHub-Organisation
• DeepSeek – offizielles Logo im DeepSeek-VL-Repository
• Qwen – offizielle GitHub-Organisation
• OpenCode – offizielles Repository