AIM-Code Bench: Agentischer Coding-Benchmark
Die Evaluierung von LLMs ohne ihre Coding-Agent-Testgerüste spiegelt nicht vollständig wider, wie sie in der Praxis eingesetzt werden. Echte Entwicklung umfasst auch das Erweitern bestehender Arbeit, das Übernehmen von unbekanntem Code und das Hinterlassen von Implementierungen, auf denen andere aufbauen können. Wir stellen AIM-Code Bench vor, um Modelle zusammen mit ihren Coding-Agent-Testgerüste über sich weiterentwickelnde Software-Aufgaben zu evaluieren. Über die Korrektheit hinaus misst der Benchmark die Laufzeitleistung, die Anpassung an sich ändernde Anforderungen und die Ergebnisse, wenn Agenten auf dem Code anderer aufbauen.
Ergebnisse
Fable 5.1 wies in den Phasen 1 und 2 die niedrigste beobachtete Latenz auf; Opus 5 führte in den Phasen 3 und 4.
Modell | Coding-Produkt | S1: Initial | S2: Kapazität | S3: Ablauf | S4: HTTP |
|---|---|---|---|---|---|
Fable 5.1 | Claude Code | 6.523 | 7.293 | 11.079 | 2.897 |
Opus 5 | Claude Code | 6.732 | 7.491 | 9.557 | 2.648 |
Opus 5.5 | Claude Code | 6.703 | 7.464 | 10.502 | 2.799 |
Sonnet 5 | Claude Code | 11.156 | 12.011 | 14.188 | 3.512 |
GPT-6 Astra | Codex | 10.957 | 12.114 | 13.214 | 3.292 |
GPT-5.6 Sol | Codex | 11.208 | 11.709 | 13.390 | 3.296 |
GPT-5.6 Luna | Codex | 10.841 | 12.091 | 13.995 | 3.483 |
SWE-2 | Devin CLI | 9.192 | 9.702 | 12.484 | 3.147 |
Grok 4.6 | Grok Build | 7.395 | 8.149 | 12.798 | 3.348 |
GLM 5.3 | OpenCode | 11.006 | 11.730 | 12.915 | 3.445 |
Die Tabelle zeigt die p95-Latenz (das 95th Perzentil) in Millisekunden; niedriger ist besser. Jeder Wert ist der Median von zehn Replay-Messungen des gespeicherten Programms. Die Ränge verwenden in jeder Phase volle Präzision. Dieselben Phase-4-Messungen dienen im Handover-Vergleich als Own-Code-Kontrollen. Nahe beieinanderliegende numerische Ränge weisen nicht zwangsläufig auf unterscheidbare Leistung hin.
Teil 1: Entwicklung und Verbesserung ihrer eigenen Implementierungen
Jeder Agent behielt seinen Code und seine Konversation über die Phasen hinweg. Wir aktualisierten die Aufgabenspezifikation, sobald neue Anforderungen eintrafen, und gaben ihr bis zu 20 Minuten für jede Phase. Die Prompts beschrieben gewöhnliche Entwicklungsarbeit und forderten die Agenten auf, die beste erreichbare Leistung anzustreben, während das geforderte Verhalten erhalten blieb.
Das Experiment umfasste dreizehn Modell-und-Produkt-Konfigurationen: vier in Claude Code, drei in Codex, vier in OpenCode, eine in Grok Build und eine in Devin CLI. Der Aufwand war mittel, wo unterstützt, hoch für Kimi K3 und GLM 5.3, und der Anbieter-Standard für MiniMax M3. Jedes Ergebnis gehört daher zum Modell und zum Coding-Produkt zusammen.
Wir haben versucht, so genau wie möglich widerzuspiegeln, wie Menschen KI-Coding-Produkte in realen Szenarien tatsächlich verwenden. Viele Menschen verwenden Modelle innerhalb ihrer eigenen Testgerüste; daher haben wir, während wir die verfügbaren Modelle innerhalb ihrer jeweiligen Testgerüste nutzten, Open-Weight-Modelle über opencode verwendet.
Vier Phasen des Projekts
Die Phasen 1–3 verwendeten 5.000 Operationen pro Batch. Phase 4 verwendete unabhängige HTTP-Requests mit jeweils 1.000 Operationen, mit einer CPU und 128 MiB Arbeitsspeicher, die dem Kandidatendienst zugewiesen wurden.
Die gemessene Batch-Latenz von MiniMax M3 ging von 37.833 ms in der Anfangsphase auf 12.254 ms in der Kapazitätsphase zurück. Dies ist eine beobachtete Reduktion von 67,6 %, als sich die Implementierung änderte und Eviction zu einer Anforderung wurde. Ihre ursprüngliche Phase-4-HTTP-Implementierung erreichte später den 4th Rang, bei 3.009 ms.
Die gemessene Batch-Latenz von Qwen 3.8 Max bewegte sich zwischen den ersten beiden Phasen von 11.638 auf 8.023 ms, eine beobachtete Reduktion von 31,1 %. Ihr Phase-3-Ergebnis erreichte den 4th Rang. Diese Verläufe zeigen, warum ein einzelnes anfängliches Ergebnis Änderungen übersieht, die auftreten, wenn ein Agent ein Projekt weiterentwickelt.
Diese Prozentsätze beschreiben die aufgezeichneten Verläufe, nicht kontrollierte Optimierungsbeschleunigungen. Jede Phase ändert das geforderte Verhalten oder die Arbeitslast. Insbesondere kann die Latenz der Phase 4 nicht von der Latenz der Phase 3 abgezogen werden: Die Schnittstelle und die Operationen pro Request unterscheiden sich. Eine direkte Vorher-/Nachher-Optimierungsaussage würde erfordern, beide Versionen unter derselben anwendbaren Arbeitslast erneut abzuspielen.
Wie viel Code hat sich im Verlauf geändert?
Die vier Phasen umfassen 52 verifizierte Original-Phasen-Diffs über die dreizehn Konfigurationen. Phase 4 veranschaulicht die Variation bei Implementierungsumfang und Bearbeitungsstil:
Diese Zählungen umfassen von Agenten geschriebene Quelltests und -werkzeuge, Kommentare und Leerzeilen; bereitgestellte Aufgaben-/Test-Updates und JSON-Diagnosen sind ausgeschlossen. Sie messen den endgültigen Unterschied zum Ausgangs-Snapshot jeder Phase. Größere Änderungen können nützliche Tests oder Optimierungen enthalten; kleinere Änderungen sind nicht automatisch besser. Der verlinkte Diff-Bericht enthält die Quelländerungen pro Phase.
Teil 2: Übernahme der Implementierung eines anderen Agenten
Nach der Messung der ursprünglichen Verläufe stellten wir zwei verschiedene Fragen: Wessen Code bietet anderen Agenten einen nützlichen Ausgangspunkt, und welcher Agent schneidet am besten ab, wenn er den Code eines anderen erweitert?
Wir verzweigten von den gespeicherten Phase-3-Implementierungen und baten die Empfänger, Phase 4 durchzuführen. Jede der dreizehn Konfigurationen erhielt den Code der zwölf anderen Konfigurationen, was 156 geordnete Spender-Empfänger-Paare ergab. Es gab keine neuen Selbstübernahmen. Jeder Empfänger startete eine frische, isolierte Session mit dem Spender-Code und denselben Phase-4-Anforderungen; er konnte den Harness nicht sehen und auch nicht die Sessions anderer Agenten.
Die ursprünglichen Phase-4-Einreichungen dienen als Own-Code-Kontrollen und verwenden dieselben Messungen wie Teil 1. Diese Kontrollen waren mit der ursprünglichen Konversationshistorie entwickelt worden, während die Übernahmen neu begannen. Der Vergleich kombiniert daher Effekte des Ausgangscodes und der Konversation. Dieser Übergang verlangt von Nachfolgern, einen bestehenden Cache zu einem HTTP-Dienst zu erweitern und dabei die Request-Latenz zu optimieren.
Sicht A: Nutzen, den der Code eines Spenders liefert
Für jedes Paar vergleichen wir die HTTP-Latenz des Nachfolgers mit der eigenen ursprünglichen Phase-4-Latenz desselben Nachfolgers:
successor benefit = (recipient own latency − inherited-code latency) / recipient own latency
Der Score eines Spenders ist der Median dieser zwölf prozentualen Vorteile. Positiv bedeutet, dass seine Nachfolger typischerweise eine niedrigere Latenz erzielten als ihre eigenen ursprünglichen Fortsetzungen. Dies ist eine leistungsbasierte Sicht darauf, wie nützlich eine Ausgangsimplementierung war; sie misst nicht direkt die Dokumentationsqualität oder die Verständlichkeit.
Opus 5 lieferte den größten medianen Nachfolger-Nutzen mit +17,30 %, gefolgt von Opus 5.5 mit +15,70 % und Fable 5.1 mit +11,34 %. Diese Ergebnisse können sowohl die Leistung der geerbten Implementierung als auch die Leichtigkeit widerspiegeln, mit der Nachfolger sie erweitern konnten. Prozentsätze normalisieren die Skala, beseitigen aber nicht Unterschiede in der Ausgangsqualität oder im Optimierungsspielraum.
Sicht B: Leistung als Nachfolger
Für jeden Spender berechnen wir die mediane Latenz, die seine zwölf Empfänger erreicht haben. Jeder Empfänger dieses Spenders wird dann mit dieser gemeinsamen Referenz verglichen:
successor advantage = (same-donor median latency − recipient latency) / same-donor median latency
Der Score eines Empfängers ist sein medianer Vorteil über zwölf Spender hinweg. Positiv bedeutet, dass er typischerweise schneller war als der mediane Empfänger desselben Ausgangscodes. Dadurch wird vermieden, einen Empfänger nur deshalb zu belohnen, weil seine eigene ursprüngliche Implementierung langsam war.
GPT-6 Astra führte diese explorative Nachfolger-Zusammenfassung mit +2,68 % an, gefolgt von Opus 5 mit +2,33 % und Grok 4.6 mit +0,88 %. Astras Vorsprung vor Opus 5 war innerhalb der gemessenen Unsicherheit nicht unterscheidbar. Der stärkste Spender und der stärkste Nachfolger zu sein, sind in diesem Experiment unterschiedliche Ergebnisse.
Haben die Nachfolger auf dem geerbten Quellcode aufgebaut?
Wir berichten den Quellcode-Churn getrennt von der Leistung: (added lines + deleted lines) / inherited source lines. Wir zählen auch Übergaben, die mehr als 50 % des geerbten Quellcodes löschen. Dies ist eine Rate großer Löschungen, kein Beweis für ein Neuschreiben von Grund auf: Umbenennungen, Neuformatierungen und das Entfernen von Hilfscode können die Schwelle überschreiten.
Keiner der ausgewählten Nachfolger löschte mehr als die Hälfte des gesamten geerbten Quellcodes von GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, Claude Opus 5.5 oder Qwen 3.8 Max. Alle zwölf überschritten diese Schwelle bei Kimi K3, GPT-5.6 Luna, MiniMax M3 und Claude Sonnet 5. Dies sind Beobachtungen zu physischen Zeilenänderungen, keine Bewertung der Wartbarkeit. Spenderprogramme enthielten nur 75–668 Quellzeilen einschließlich Hilfscode, und die Entscheidung, Tests/Tools einzubeziehen, beeinflusst die Löschprozentsätze.
Messmethode, Wiederholungen und Umfang
Jeder berichtete Leistungswert verwendet zehn Replays desselben gespeicherten Programms. Die Phasen 1–3 verwendeten 40 gemessene Batches pro Replay. Phase 4 und das Handover-Timing verwendeten 1.200 HTTP-Requests pro Replay bei 20 Requests pro Sekunde über 60 Sekunden, mit einer CPU, 128 MiB Arbeitsspeicher und einem 64-Prozess-/Thread-Limit für jeden Kandidaten.
Wir haben die Programme seriell auf einem dedizierten Intel i7-7700 Linux-Server gemessen. Der Treiber und der Kandidat liefen auf getrennten physischen Kernen mit ungenutzten Geschwister-Threads, einer festen 2-GHz-CPU-Richtlinie und deaktiviertem Turbo.
Alle 156 ausgewählten Handover-Einreichungen und alle 52 Original-Phasen-Builds bestanden jedes Replay. Die vollständige Evaluierung enthält 2.080 Messungen, einschließlich aller dreizehn Own-Code-Kontrollen. Wir prüften die Rohantworten, berechneten die p95-Latenz neu, verifizierten Quell-Hashes und Ressourcenlimits und behielten jede geplante Messung bei.
Wir berechnen 95 %-Intervalle aus 10.000 Resamplings der zehn Messrunden, wobei dieselben Stichprobenrunden über alle Programme hinweg verwendet werden. Ein Vergleich ist ungeklärt, wenn sein Differenzintervall null enthält. Diese explorativen Intervalle sind nicht für multiple Vergleiche adjustiert. Die Zählungen schnellerer Nachfolger vergleichen gemessene Werte und implizieren keine statistisch unterscheidbaren Unterschiede.
Über 13 ursprüngliche Phase-4-Builds und 156 Handover hinweg waren alle 2.028.000 gemessenen HTTP-Antworten korrekt. Die maximale Dispatch-Verzögerung betrug 0.607 ms. Jedes Replay erfüllte die Treibergrenzen von p95-Dispatch-Verzögerung unter 0.05 ms und maximaler Verzögerung unter 1 ms. Die Verzögerung bleibt in der Latenz enthalten.
Die veröffentlichte Auswahl umfasst zusätzliche Versuche. GLM 5.3 und Qwen 3.8 Max verwenden ihre zweiten vollständigen ursprünglichen Verläufe nach anfänglichen Phase-3-Fehlschlägen. Vier abgeschlossene Handover-Pilot-Builds wurden wiederverwendet, fünfzehn Claude-Paare erhielten Infrastruktur-Wiederherstellungsversuche, und sieben fehlgeschlagene Handover erhielten einen frischen Coding-Versuch von ihren ursprünglichen Spendern. Alle sieben Coding-Wiederholungen bestanden. Neue Versuche wurden unabhängig vom Ergebnis ausgewählt; frühere Versuche bleiben archiviert. Diese Ergebnisse vergleichen ausgewählte Builds und nicht die Zuverlässigkeit des ersten Versuchs.
Der Evaluator unterscheidet Kandidatenfehler von infrastrukturbedingt ungültigen Messungen. Die HTTP-Korrektheit erfordert mindestens 99 % bediente Requests, korrekte Warmups und keine fehlerhaften Antworten. Jeder gerankte Build muss zehn gültige Replays haben. Während der Timing-Evaluierung wurde kein Code geändert.
Dies ist ein Projekt und ein ausgewählter Verlauf pro Konfiguration. Die vier Phasen sind miteinander verbunden, und die 156 Handover-Paare teilen sich Spender und Empfänger. Die Intervalle beschreiben die Replay-Variation auf diesem Host; sie decken keine anderen Aufgaben, Maschinen oder unabhängigen Coding-Läufe ab. Die Ergebnisse beschreiben diese Artefakte unter diesen Arbeitslasten und nicht ein allgemeines Ranking der Coding-Fähigkeit, des Code-Verständnisses oder der Produktions-Wartbarkeit.
Als bevorzugte Quelle hinzufügenWas kommt als Nächstes?
Die nächsten Experimente werden mehr Projekte und unabhängige Coding-Verläufe hinzufügen, den Schwierigkeitsgrad von Phasen erhöhen, die Obergrenze der angebotenen Last erreichen, und anwendbare Vorher-/Nachher-Versionen unter derselben Arbeitslast messen. Kontrollen mit frischer Session und Selbstfortsetzung würden helfen, die Effekte der Konversationshistorie vom Start mit dem Code eines anderen Agenten zu trennen.
Zitieren Sie diesen Benchmark
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{alper2026,
author = {Alper, Şevval},
title = {{AIM-Code Bench: Agentischer Coding-Benchmark}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Abgerufen am 22. September 2026}
}Ergebnisse und Zeitstempel von 485 Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 7 CSV-Dateien und eine README enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
13 AktualisierungenKimi K3- und Inkling-Modellergebnisse zur Benchmark-Rangliste hinzugefügt.
Kimi K3 und Inkling wurden zum agentischen Coding-Benchmark hinzugefügt.
Grok 4.5 und die GPT-5.6-Modellfamilie zum Coding-Benchmark-Vergleich hinzugefügt.
Sieben Modelle zum Benchmark hinzugefügt: Grok 4.5 und die GPT-5.6-Familie (Sol, Terra, Luna).
Hinzugefügt: Vergleich der Code-Spezialmodelle GPT 5.3 Codex und Kimi K2.7 Code im Backend-Bewertungsabschnitt.
Claude Sonnet 5 mit einer Gesamtpunktzahl von 0,772 zur Benchmark-Rangliste hinzugefügt.
Kimi K2.7 Code und Claude Fable 5 zu den Benchmark-Ergebnissen und Kostenvergleichsabschnitten hinzugefügt.
Aktualisiert die Harness-Methodik: Claude Fable 5 lief auf dem Claude Code CLI-Abo statt auf Opencode über OpenRouter.
Claude Opus 4.8, Gemini 3.5 Flash und MiniMax M3 zur Benchmark-Rangliste und zu den Kostenvergleichen hinzugefügt.
Ersetzte die getestete Modellauswahl und alle Erfolgs-, Kosten- und Latenzergebnisse durch neue Werte.
Aider durch opencode als Agenten-Harness ersetzt und drei Durchläufe pro Zelle zur Varianzmessung hinzugefügt.
Gemini 3 Pro in der Zusammenfassung der Benchmark-Ergebnisse durch Gemini 3.1 Pro Preview ersetzt.
Gemini 3.1 Pro Preview zu den Agentic LLM Benchmark-Ergebnissen hinzugefügt.
Şevval konzentriert sich auf KI-Programmierwerkzeuge, KI-Agenten und Quantentechnologien.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.