Update vom 30 September: Opus 5.5
Wir haben dieselben 89 Tasks mit Claude Opus 5.5 auf demselben Harness laufen lassen wie den Sol-Lauf ohne Review: bash, read und web fetch, eine isolierte Single-Machine-Bridge, kein Review-Sub-Agent. Das Hauptergebnis ist 95.1% (77/81).
Warum 81, nicht 89. Acht Tasks sind nie gelaufen. Anthropics Safety-Classifier markiert sie gleich zu Beginn (drei Biologie-Tasks: dna-assembly, dna-insert, protein-assembly; fünf Security-Tasks: break-filter-js-from-html, filter-js-from-html, crack-7z-hash, password-recovery, vulnerable-secret), das Todo stoppt nach ein oder zwei Aufrufen, und Harbor protokolliert einen ApiError. Das Modell hat sie nicht versucht. In diesem Score zählen sie deshalb weder als bestanden noch als durchgefallen und bleiben aus dem Nenner draußen. Wiederholungen werden meist wieder abgelehnt (bei einem Retry von vier dieser Tasks wurden drei abgelehnt), deshalb wiederholen wir sie nicht. Zählt man sie als Fehlschläge, ergibt das 86.5% (77/89). Beide Zahlen stehen im Ergebnisblatt.
| Opus 5.5 | GPT-5.6 Sol, Review aus | |
|---|---|---|
| Dieselben 81 Tasks (Abgelehnte ausgenommen) | 95.1% (77/81) | 82.7% (67/81) |
| Wilson-95%-Intervall, 81 Tasks | [88.0%, 98.1%] | [73.1%, 89.4%] |
| Alle 89 Tasks | 86.5% (77/89) | 82.0% (73/89) |
| Reasoning | xhigh-Sweep; high bei 6 Reruns | xhigh |
| Zeitraum | 26–30 September 2026 | 2–4 September 2026 |
Die Sol-Spalte nutzt Sols finales Ergebnis ohne Review (73/89, nachdem ein späterer Rerun einen Token-Ablauf-Bug behoben hat; die 79.8% weiter unten sind der frühere Stand mit 71/89). Sol versucht die acht Tasks und hat sechs davon bestanden. Der Ausschluss begünstigt also Opus: Er hebt Opus um 8.5 Punkte und Sol um 0.7. Zählt man alle 89 Tasks, liegt Opus weiterhin vorn, 86.5% zu 82.0%, aber mit kleinerem Abstand. Die Intervalle überlappen sich. Auf 81 Tasks ist der Abstand also ein Hinweis, kein Beweis.
Kosten. $76.75 zum Listenpreis für den Sweep plus die Reruns für Timeouts und polyglot. Die zwei qemu-/video-Reruns vom 30 September sind noch nicht bepreist, die Zahl ist also eine Untergrenze. Sie ist nicht direkt mit Sols $61.87 vergleichbar; dort wird nur der letzte Versuch pro Task gezählt.
Reruns, und einer, der uns begünstigt. Neun Tasks werden mit einem späteren Lauf gewertet. Der letzte Lauf zählt, egal ob bestanden oder durchgefallen:
- Harness- oder Verifier-Fixes, 4 Tasks.
polyglot-c-pyhing pro Versuch ~300 s an einer interaktiventzdata-Abfrage, bis der HarnessDEBIAN_FRONTEND=noninteractivegesetzt hat.qemu-startupundqemu-alpine-sshwurden vom Agenten gelöst, aber der Verifier des Tasks (aufdebian:bullseye) konntecurl/sshpassnicht installieren, weil der End-of-Life-Security-Mirror 404 liefert. Jeder Lauf bekam deshalb 0. Der Harness entfernt diesen Mirror jetzt vor dem Verifier.extract-moves-from-videowurde nach einem CPU-Limit-Fix wiederholt und ist trotzdem durchgefallen. - Timeouts, 6 Tasks, Rerun mit
highReasoning:adaptive-rejection-sampler,cobol-modernization,extract-moves-from-video,make-doom-for-mips,query-optimize,schemelike-metacircular-eval. Das waren Agent-Timeouts, keine Infrastrukturschäden. Der Rerun ist also ein zweiter Versuch. Bei zwei Tasks änderte sich das Ergebnis zu „bestanden“ (adaptive-rejection-sampler,cobol-modernization), vier sind weiter durchgefallen. Ohne diese zwei liegt der Score bei 92.6% (75/81).
Jedes Feld ist ein versuchter Task; die 8 abgelehnten Tasks sind nicht gezeigt. Schraffierte Felder wurden mit einem späteren Lauf gewertet. Beim Darüberfahren wird die Task-ID angezeigt.
All task IDs and outcomes
bn-fit-modify— passedbuild-cython-ext— passedbuild-pmars— passedbuild-pov-ray— passedcaffe-cifar-10— passedcancel-async-tasks— passedchess-best-move— passedcircuit-fibsqrt— passedcode-from-image— passedcompile-compcert— passedconfigure-git-webserver— passedconstraints-scheduling— passedcount-dataset-tokens— passedcustom-memory-heap-crash— passeddb-wal-recovery— passeddistribution-search— passedextract-elf— passedfeal-differential-cryptanalysis— passedfeal-linear-cryptanalysis— passedfinancial-document-processor— passedfix-code-vulnerability— passedfix-git— passedfix-ocaml-gc— passedgcode-to-text— passedgit-leak-recovery— passedgit-multibranch— passedgpt2-codegolf— passedheadless-terminal— passedhf-model-inference— passedinstall-windows-3.11— passedkv-store-grpc— passedlarge-scale-text-editing— passedlargest-eigenval— passedllm-inference-batching-scheduler— passedlog-summary-date-ranges— passedmailman— passedmake-mips-interpreter— passedmcmc-sampling-stan— passedmerge-diff-arc-agi-task— passedmodel-extraction-relu-logits— passedmodernize-scientific-stack— passedmteb-leaderboard— passedmteb-retrieve— passedmulti-source-data-merger— passednginx-request-logging— passedopenssl-selfsigned-cert— passedoverfull-hbox— passedpath-tracing— passedpath-tracing-reverse— passedpolyglot-rust-c— passedportfolio-optimization— passedprove-plus-comm— passedpypi-server— passedpytorch-model-cli— passedpytorch-model-recovery— passedraman-fitting— passedregex-chess— passedregex-log— passedreshard-c4-data— passedrstan-to-pystan— passedsam-cell-seg— passedsanitize-git-repo— passedsparql-university— passedsqlite-db-truncate— passedsqlite-with-gcov— passedtorch-pipeline-parallelism— passedtorch-tensor-parallelism— passedtrain-fasttext— passedtune-mjcf— passedvideo-processing— passedwinning-avg-corewars— passedwrite-compressor— passedadaptive-rejection-sampler— passed, replacement runcobol-modernization— passed, replacement runpolyglot-c-py— passed, replacement runqemu-alpine-ssh— passed, replacement runqemu-startup— passed, replacement runextract-moves-from-video— failed, replacement runmake-doom-for-mips— failed, replacement runquery-optimize— failed, replacement runschemelike-metacircular-eval— failed, replacement run
Die vier Fehlschläge: schemelike-metacircular-eval (Timeout, lange Thinking-Turns), make-doom-for-mips (Timeout), extract-moves-from-video (Timeout: OCR von 951 Frames auf einer CPU) und query-optimize (falsche Antwort).
Vergleich. Die 78.9% (Claude Code, Opus 4.8) und 78.4% (Codex, GPT-5.6 Terra) auf unserer Seite sind Einträge im tbench.ai-Leaderboard über alle 89 Tasks mit mehreren Trials je Task. Es gelten dieselben Einschränkungen der Vergleichbarkeit wie unten, und Ablehnungen zählen dort als Fehlschläge. Der Abstand ist nur ein Anhaltspunkt.
Der Rest dieses Beitrags dokumentiert die früheren GPT-5.6 Sol-Läufe.
Frühere Läufe: GPT-5.6 Sol
Vor Opus 5.5 haben wir Terminal-Bench 2.1 zweimal auf denselben 89 Tasks mit GPT-5.6 Sol laufen lassen. Das Hauptergebnis war damals der Single-Model-Lauf: 79.8% (71/89), GPT-5.6 Sol auf xhigh, mit gesperrtem Review-Tool. Web fetch lässt das Lesen der Seiten weiterhin von Claude Haiku 4.5 erledigen ($4.17 der $46.87). Nichts in diesem Lauf prüft oder kontrolliert die Arbeit des Hauptmodells.
Der frühere Lauf vom 25–26 August hatte einen Review-Sub-Agent auf Claude Opus 5 eingeschaltet und kam auf 82.0% (73/89). Der Unterschied beträgt zwei Tasks bei 2.9× den Kosten, und die Tasks, die durch das Review hinzugewonnen wurden, waren die „Fast-geschafft“-Fälle: 1 von 2 Schachzügen, 3 von 4 Tests. Der größte Teil dieses Beitrags dokumentiert den früheren Lauf, weil nur er eine Ergebnistabelle pro Task hat. Der Lauf ohne Review nutzt denselben Harness, dieselbe Wertungsregel und dasselbe gepinnte Repository. Sein Ergebnisblatt listet jede Änderung und jeden Fehlschlag auf.
| Review aus (Hauptergebnis) | Review an | |
|---|---|---|
| Pass-Rate | 79.8% (71/89) | 82.0% (73/89) |
| Wilson-95%-Intervall | [70.3%, 86.8%] | [72.8%, 88.6%] |
| Modelle | GPT-5.6 Sol; Haiku 4.5 für web fetch | + Claude Opus 5 Review |
| Kosten, Promo / Liste | $46.87 / ~$89.6 | $134.51 / $188.33 |
| Zeitraum | 2–3 September 2026 | 25–26 August 2026 |
Die folgenden Abschnitte dokumentieren den Lauf mit Review von Terminal-Bench 2.1 vom 25–26 August 2026. Dieser Beitrag zeigt, wie die Zahl entstanden ist, damit man sie richtig lesen kann: Sie ist ein Systemergebnis unter einer genannten Rerun-Regel, keine offizielle Leaderboard-Einreichung und kein Score eines einzelnen Modells.
Alle Zahlen unten stammen aus dem gepinnten Ergebnisblatt im öffentlichen Benchmark-Repository. Die Links pinnen einen Commit, spätere Änderungen können also nicht unbemerkt ändern, was dieser Artikel beschreibt.
Das getestete System
Terminal-Bench gibt einem Agenten einen Task in einem isolierten Container — ein Projekt kompilieren, eine Datenbank wiederherstellen, einen Dienst konfigurieren, Code reparieren — und ein Verifier prüft den entstandenen Zustand. Was der Agent selbst als Erfolg meldet, spielt keine Rolle. Nur das Ergebnis des Verifiers zählt.
- 89 Task-IDs
- isolierte Docker-Umgebung
- sendet die Anweisung
- Edge führt im Container aus
- ausgeliefertes Modell in den Message-Metadaten geprüft
- review → Claude Opus 5
- explore, webfetch → Haiku 4.5
- ein finales Ergebnis pro Task
Zwei Details dieser Konfiguration sind für die Deutung wichtig.
Die 82.0% gehören zur ganzen Pipeline. Review und Exploration liefen innerhalb desselben Trials auf Anthropic-Modellen. Die Zahl lässt sich also nicht allein GPT-5.6 Sol zuschreiben. Der Lauf ohne Review oben isoliert diesen Effekt: 79.8%.
Das ausgelieferte Modell wurde geprüft, nicht angenommen. Der CLI-Header gibt nur das angeforderte Modell wieder. Die Lauf-Notizen verifizieren gpt-5.6-sol auf xhigh anhand der Provider-Metadaten, die an jeder Assistant-Message hängen.
Wertungsregel und die Ersatzläufe
Das Ergebnisblatt hält ein finales Ergebnis pro Task fest. Sechzehn Tasks wurden am 26 August wiederholt, nachdem ihr erster Versuch als durch Infrastrukturprobleme beeinträchtigt eingestuft wurde. Bei diesen Tasks ersetzt das Rerun-Ergebnis das ursprüngliche.
Jedes Feld ist ein Task. Schraffierte Felder wurden mit ihrem Ersatzlauf gewertet. Beim Darüberfahren wird die Task-ID angezeigt.
All task IDs and outcomes
bn-fit-modify— passedbuild-pmars— passedcancel-async-tasks— passedchess-best-move— passedcode-from-image— passedconfigure-git-webserver— passedconstraints-scheduling— passedcount-dataset-tokens— passedcrack-7z-hash— passeddb-wal-recovery— passeddistribution-search— passedextract-elf— passedfeal-differential-cryptanalysis— passedfeal-linear-cryptanalysis— passedfinancial-document-processor— passedfix-code-vulnerability— passedfix-git— passedfix-ocaml-gc— passedgcode-to-text— passedgit-leak-recovery— passedgit-multibranch— passedheadless-terminal— passedhf-model-inference— passedinstall-windows-3.11— passedkv-store-grpc— passedlarge-scale-text-editing— passedlargest-eigenval— passedllm-inference-batching-scheduler— passedlog-summary-date-ranges— passedmerge-diff-arc-agi-task— passedmodel-extraction-relu-logits— passedmodernize-scientific-stack— passedmteb-leaderboard— passedmteb-retrieve— passedmulti-source-data-merger— passednginx-request-logging— passedopenssl-selfsigned-cert— passedoverfull-hbox— passedpassword-recovery— passedpath-tracing— passedpath-tracing-reverse— passedpolyglot-c-py— passedpolyglot-rust-c— passedportfolio-optimization— passedprotein-assembly— passedprove-plus-comm— passedpypi-server— passedpytorch-model-cli— passedqemu-alpine-ssh— passedraman-fitting— passedregex-log— passedrstan-to-pystan— passedsanitize-git-repo— passedschemelike-metacircular-eval— passedsparql-university— passedsqlite-db-truncate— passedsqlite-with-gcov— passedtorch-tensor-parallelism— passedtune-mjcf— passedvulnerable-secret— passedwinning-avg-corewars— passedwrite-compressor— passedbreak-filter-js-from-html— passed, replacement runbuild-cython-ext— passed, replacement runbuild-pov-ray— passed, replacement runcaffe-cifar-10— passed, replacement runcobol-modernization— passed, replacement runcompile-compcert— passed, replacement runcustom-memory-heap-crash— passed, replacement rundna-insert— passed, replacement runmailman— passed, replacement runmake-mips-interpreter— passed, replacement runmcmc-sampling-stan— passed, replacement runfilter-js-from-html— failedgpt2-codegolf— failedmake-doom-for-mips— failedpytorch-model-recovery— failedqemu-startup— failedquery-optimize— failedregex-chess— failedreshard-c4-data— failedsam-cell-seg— failedtrain-fasttext— failedvideo-processing— failedadaptive-rejection-sampler— failed, replacement runcircuit-fibsqrt— failed, replacement rundna-assembly— failed, replacement runextract-moves-from-video— failed, replacement runtorch-pipeline-parallelism— failed, replacement run
Das ist weder All-Attempt-Genauigkeit noch Best-of-N. Der Ersatz gilt überall, wo ein Rerun existiert, unabhängig davon, welches Ergebnis besser war. 11 der 16 Ersatzläufe haben bestanden, 5 sind durchgefallen. Die Regel begünstigt das System trotzdem: Nur Tasks, deren erster Versuch als durch Infrastrukturprobleme beeinträchtigt eingestuft wurde, wurden wiederholt, und das Blatt hält deren ursprüngliche Ergebnisse nicht fest. Das Blatt zählt außerdem insgesamt 102 Trials bei 16 als Reruns markierten Tasks, eine Abweichung, die es nicht auflöst. Jeder Vergleich mit einem Protokoll, das alle Trials mittelt, muss beide Punkte berücksichtigen.
Die 16 Tasks, die mit einem Ersatzlauf gewertet wurden, sind: adaptive-rejection-sampler, break-filter-js-from-html, build-cython-ext, build-pov-ray, caffe-cifar-10, circuit-fibsqrt, cobol-modernization, compile-compcert, custom-memory-heap-crash, dna-assembly, dna-insert, extract-moves-from-video, mailman, make-mips-interpreter, mcmc-sampling-stan, torch-pipeline-parallelism. Fünf davon gehören zu den sechzehn finalen Fehlschlägen.
Statistische Präzision
Es wurde kein wiederholter voller Sweep gefahren, deshalb nennt das Blatt kein Intervall. Für einen einzelnen binomialen Anteil zeigt das Wilson-95%-Intervall, wie stark sich ein Ergebnis bei dieser Task-Anzahl bewegen kann:
mit , , .
Das Intervall ist illustrativ. Es setzt unabhängige Trials mit fester Erfolgswahrscheinlichkeit pro Task voraus und bildet weder die Ersatzregel noch die unterschiedliche Schwierigkeit der Tasks ab. Es zeigt aber die Größenordnung: Ein Abstand von ein paar Punkten zwischen zwei Einzel-Sweeps auf 89 Tasks liegt locker in diesem Bereich und ist für sich allein kein Beleg, dass ein System besser ist.
Womit sich die Zahl vergleichen lässt
Unsere Seite zeigt Claude Code mit 78.9% und Codex mit 78.4% neben unserem eigenen Ergebnis (79.8% mit Sol zum Zeitpunkt dieses Abschnitts, jetzt 95.1% mit Opus 5.5). Die Tabelle beschreibt die Sol-Läufe. Die Unterschiede bei Opus 5.5 (Ablehnungen ausgenommen, neun Tasks mit späterem Lauf) stehen im Update oben. Diese Werte sind aus dem öffentlichen tbench.ai-2.1-Leaderboard übernommen und wurden in diesem Lauf nicht reproduziert. Vier Unterschiede machen die Spalten nicht gleichwertig:
| Dimension | tbench.ai-Leaderboard | Dieser Lauf |
|---|---|---|
| Genauigkeit | Erfolge ÷ alle Trials; Reruns eingemittelt | ein finales Ergebnis pro Task; das Rerun-Ergebnis ersetzt den ursprünglichen Versuch |
| Trials pro Task | ≥ 5 bei gelisteten Einträgen | 1, mit 16 Tasks, die mit einem Ersatzlauf gewertet wurden |
| Kosten | Summe aller Trials | nur der letzte Versuch pro Task |
| Token-Zahl | input + output; Cache-Tokens ausgenommen | alle vier Klassen, Cache-Reads eingeschlossen |
| Modell | wie eingereicht, ein Eintrag pro Modell | 79.8%: GPT-5.6 Sol, Haiku für web fetch · 82.0%: + Opus-Review |
Nach der Regel des Leaderboards — alle Versuche eingemittelt, statt das Rerun-Ergebnis als Ersatz einzusetzen — würden beide Läufe niedriger abschneiden (unter 79.8% bzw. 82.0%), wenn die ersetzten Versuche als Fehlschläge zählen, und die Kosten würden mit der Trial-Anzahl skaliert. Die Vergleichbarkeits-Notizen im Repository rechnen die Anpassungen durch.
Ein Terminal-Benchmark misst außerdem nur einen schmalen Ausschnitt dessen, was ein Agent-Produkt tut. Er sagt nichts über E-Mail, CRM-Arbeit, Browser-Tasks, Berechtigungen oder Team-Workflows. Dazu siehe TODO for AI vs Claude Code, vs Codex oder die Vergleichsübersicht.
Kosten des Laufs mit Review: drei Modelle, vier Token-Klassen
Die Kosten werden aus den Usage-Reports der Provider für den letzten Versuch jedes Tasks berechnet, einschließlich der Sub-Agent-Todos, die von jedem Trial verlinkt sind. Verworfene, durch Infrastrukturprobleme beeinträchtigte Versuche werden nicht bepreist.
| Modell | Rolle | Input | Output | Cache Read | Cache Write |
|---|---|---|---|---|---|
| GPT-5.6 Sol | Hauptschleife | 7.65M | 0.95M | 144.94M | 0 |
| Claude Opus 5 | Review | ~0 | 1.74M | 24.31M | 2.68M |
| Claude Haiku 4.5 | explore, webfetch | 0.24M | 0.50M | 18.98M | 2.96M |
| Modell | $/Mtok — in / out / cache read / cache write | Kosten | Pro Task |
|---|---|---|---|
| GPT-5.6 Sol | 2 / 10 / 0.2 / 2.5 (Promo) | $53.82 | $0.60 |
| Claude Opus 5 | 5 / 25 / 0.5 / 6.25 | $72.37 | $0.81 |
| Claude Haiku 4.5 | 1 / 5 / 0.1 / 1.25 | $8.32 | $0.09 |
| Summe | $134.51 | $1.51 |
Drei Beobachtungen ergeben sich direkt aus der Tabelle.
- Der Review-Sub-Agent kostet mehr als das Modell, das getestet wird — $72.37 gegen $53.82, aus etwa 50 Review-Aufrufen, fast ausschließlich Opus-Output und Cache-Writes. Mit ausgeschaltetem Review (der 79.8%-Lauf) sank die Summe auf $46.87.
- Cache-Reads machen 93% aller gesendeten Tokens aus. Eine Agent-Schleife schickt ihren Kontext in jedem Turn erneut mit. Eine Token-Zahl, die nur
input + outputmeldet — wie die Token-Spalte des Leaderboards — beschreibt einen kleinen Teil des Traffics, den Provider abrechnen. - Der Preis ist ein Parameter, die Tokens sind die Messung. Zum vollen Listenpreis von GPT-5.6 Sol (4 / 20 / 0.4 / 5) wird die Summe zu $188.33, also $2.12 pro Task statt $1.51. Unser eigenes Billing-Ledger ist bewusst nicht die Kernzahl: Es enthält Promo-Rabatte, die außerhalb niemand reproduzieren kann.
Die sechzehn Fehlschläge
adaptive-rejection-sampler, circuit-fibsqrt, dna-assembly, extract-moves-from-video, filter-js-from-html, gpt2-codegolf, make-doom-for-mips, pytorch-model-recovery, qemu-startup, query-optimize, regex-chess, reshard-c4-data, sam-cell-seg, torch-pipeline-parallelism, train-fasttext, video-processing.
Elf sind im ursprünglichen Sweep durchgefallen, fünf in einem Ersatzlauf. Das Blatt hält Ergebnisse fest, keine Ursachen, und dieser Beitrag stuft keinen davon nachträglich als Infrastrukturproblem ein.
Die Konfiguration reproduzieren
Öffentliche Inputs:
- Ergebnisblatt — alle 89 Ergebnisse, Token- und Preistabellen
- Task-Liste
- Harbor-Adapter
- Skript zur Token-Abrechnung
Der Adapter ruft ein gehostetes Backend auf und nutzt einen im Account konfigurierten Agenten namens app. Modellzugang, Reasoning-Einstellung, Sub-Agent-Modelle und Tool-Berechtigungen liegen in diesem Account, nicht im Repository. Ein Clone ist also ein Startpunkt, keine hermetisch reproduzierbare Ausführung. Nimm einen dedizierten Benchmark-Account und einen Docker-Host ohne andere, nicht benötigte Zugangsdaten. Ein Aufruf für einen einzelnen Task:
git clone https://github.com/todoforai/benchmarks.git
cd benchmarks && git checkout 4d37742c540801d0b2e10305446b02555a9fd2f1
cd terminal-bench
python3 -m venv .venv && . .venv/bin/activate && pip install -e .
: "${TODOFORAI_API_KEY:?Set a dedicated benchmark API key first}"
export TODOFORAI_API_KEY
harbor run \
-d "terminal-bench/terminal-bench-2-1" \
--agent-import-path "todoforai_tbench:TODOforAIHarborAgent" \
-m "openai:openai/gpt-5.6-sol" \
-i "terminal-bench/openssl-selfsigned-cert" \
--job-name "tb21-single-task" \
--max-retries 0 \
--yes -n 1Das Flag -m wählt das Hauptmodell. Es setzt weder xhigh noch konfiguriert es die Sub-Agents. Prüfe beides in den zurückgegebenen Message-Metadaten, bevor du einem Sweep traust.
Für einen Lauf, der mit dem Leaderboard verglichen werden soll: Dependency-Versionen und Agent-Einstellungen vor dem Start festlegen, jeden Versuch behalten, die Retry-Regel vorab erklären und die All-Trial-Genauigkeit getrennt von jeder Ersatzlauf-Diagnose berichten.