Pi gegen Codex: Sieg mit 21 zu 20, bezahlt in Tokens

OpenAI Codex und pi sind dasselbe Experiment mit gegensätzlichen Rezepten, und am 20.09.2026 hat ein kontrollierter Vergleich beide an derselben Wand gemessen. Composio ließ fünf Agent-Harnesses mit exakt demselben Modell über dieselben 30 hart konfigurierten Tool-Use-Aufgaben laufen. Das Ergebnis: pi gewinnt mit 21 von 30 Aufgaben, Codex liegt mit 20 dahinter, OpenCode und Claude Code landen je bei 19. Die eigentliche Überraschung steht in der Token-Spalte. Codex brauchte im Schnitt 383.722 Tokens je Aufgabe, pi 924.990. Der Sieger zahlt also rund 2,4 Mal so viel für seinen einzigen Punkt Vorsprung. Ich gehe hier die Zahlen durch, erkläre, warum das Ergebnis plausibel ist, und stelle es neben meine eigenen Messwerte aus dem laufenden Betrieb auf dem Pixel-Cyberdeck.

Ein paar Fakten, damit klar ist, worüber wir reden. pi ist das Agent-Toolkit von Mario Zechner, inzwischen unter dem Dach von Earendil geführt, MIT-Lizenz, und konzentriert sich auf vier Kernwerkzeuge: read, write, edit und bash. Der System-Prompt samt Werkzeugdefinitionen bleibt unter etwa 1.000 Tokens, der Kontext bleibt sichtbar und austauschbar, und wer will, wechselt das Modell, ohne die Hälfte des Stacks umzubauen. Codex ist die gegenteilige Wette: eine komplette Plattform mit Sandbox, Cloud-Aufträgen, Subagenten, Hooks, Skills und eigener Patch-Pipeline. Live-Schnappschuss vom 25.09.2026: pi v0.87.1 vom 22.09. mit 109.347 Sternen auf GitHub, Codex v0.157.0, heute veröffentlicht, bereits Release Nummer 1.145, über 126.000 Sterne, Rust-Anteil 97,1 Prozent. Beide Projekte atmen täglich, das ist beim Lesen jeder Zahl hier wichtig.

Die Methodik ist der Teil, der mir Vertrauen gibt. Alle Harnesses bekamen dasselbe Modell, DeepSeek V4 Pro (0813) auf Max-Reasoning, durch denselben gehosteten MCP-Router, dieselben 30 Aufgaben gegen echte Anwendungen und dieselben Verifizierungsprüfungen. Schwankt etwas im Ergebnis, kann der einzige freie Faktor nur der Harness sein, nicht das Modell. Genau das isoliert die Frage, die zählt, wenn man Agenten baut: wie viel Software darf zwischen Modell und Aufgabe liegen, bevor sie mehr kostet als sie bringt? Die meisten Vergleiche mischen Modellqualität und Werkzeugumgebung in einer Messung, dieser Aufbau hält den Faktor sauber getrennt. Testdatum 20.09.2026, Aufbau und kompletter Bericht stehen im Quellenblock.

Die Tabelle von oben nach unten gelesen: pi 21 von 30, Codex 20, der hauseigene DeepSeek-Harness ebenfalls 20, OpenCode 19, Claude Code 19. Bei den Aufgaben, die beide Spitzenreiter gelöst haben, lag der Preis gleichauf bei 0,031 Dollar je geteiltem Erfolg. In der Token-Bilanz trennen sich die Wege deutlich: OpenCode verbrannte 710.140 Tokens je Aufgabe, Claude Code 649.900 bei gleichzeitig dem teuersten Wert im Feld mit 0,074 Dollar je geteiltem Erfolg. Der DeepSeek-Harness war mit 88.562 Tokens der sparsamste im Feld, verfehlte aber dieselben zwei Aufgaben wie Codex. Wer nur die Aufgabenspalte liest, verpasst also die halbe Geschichte; die spannende Achse läuft zwischen Aufgabenquote und Token-Rechnung.

Warum verliert der kleinere Harness den Token-Vergleich so deutlich? Die Erklärung aus dem Bericht passt zu dem, was ich am eigenen Stack sehe. pi steuert kaum etwas: unter 1.000 Tokens Basis-Kontext, sonst erkundet das Modell selbst, welche Dateien, Tests und Befehle ein Problem voranbringen. Diese Freiheit kostet Turns, und Turns kosten Tokens, besonders bei Aufgaben mit hohem Setup-Aufwand. Codex kontrolliert Kontext, Sandbox und Patch-Workflow zentral und trainiert seine Modelle genau auf diesen Ablauf; weniger Umwege, weniger Tokens. Der Preis dafür ist Sichtbarkeit: verwaltet die Plattform den Kontext, sieht man nicht mehr, was sie dem Modell vorenthalten hat, außer man fragt nach. Für den Benchmark heißt das, pi kauft sich Sieg und Transparenz mit dem teureren Konto.

Hinter den Zahlen stehen zwei Antworten auf dieselbe Frage. OpenAI hat Codex als Produkt gebaut: Aufgaben übergeben, Sandbox, Cloud-Läufe, Team-Workflows und Sicherheitsdefaults erhalten, ohne selbst zu bauen. Mario Zechner hat pi als Werkzeugkasten gebaut: klein genug, um ihn umzubauen, ohne gegen eine Plattformwand zu laufen, und die TypeScript-Erweiterungen dürfen das Laufzeitverhalten selbst verändern. Nach dem Modell-Wechsel-Zyklus, den ich in einem eigenen Beitrag aufgearbeitet habe (https://hunter-cyberdeck.d4sn3st.dev/post.html?slug=pi-0871-modellwechsel), ist genau diese Umbaubarkeit für mich das Kaufargument. Ein Agent, dessen Kontext ich jederzeit ersetzen kann, überlebt einen Modellwechsel besser als einer, dessen Kontext jemand anderes verwaltet.

Jetzt der Gegencheck aus dem eigenen Betrieb, mit Zahlen, die ich selbst gemessen habe. Auf dem Pixel-Cyberdeck ist pi der ausführende Agent in der Agentenfamilie, angebunden über herdr, während Hermes Agent die Schaltzentrale bleibt. Die Lektion des Benchmarks gilt dort im Kleinen: ein schlanker Harness gewinnt nichts von allein, er braucht Wachhunde, Wiederanlaufwege und eine ehrliche Buchhaltung über Ressourcen. Die folgenden Werte stammen aus dem laufenden Betrieb auf dem Telefon, die Stichtage stehen mit dabei.

Warum ich mein Betriebslog neben einen Benchmark lege, hat einen Grund: beide zeichnen dieselbe Schere. Klein und sichtbar ist reparierbar, groß und unsichtbar ist bequem, bis der Ausfall kommt. Der Gateway lief die Woche davor mit 306 Checks in Folge fehlerfrei, dann starb das Telefon unter vollem Swap, und der Watchdog, der es hätte melden sollen, war selbst tot wegen eines fehlenden coreutils-Pakets ohne nohup. So läuft Agentenbetrieb: keine Siegesreden, nur Zustände. Wie meine Agenten im Alltag zusammenlaufen, habe ich in einem früheren Beitrag dokumentiert (https://hunter-cyberdeck.d4sn3st.dev/post.html?slug=mein-agent-zog-in-eine-agenten-community-ein). Der Benchmark misst den Harness, mein Log misst das Leben drumherum, und beide Seiten sagen dasselbe: Kontrollieren kostet Aufmerksamkeit, Abgeben spart Tokens und nimmt Sichtbarkeit.

Die Entscheidungshilfe fällt aus den Daten heraus. Wer einen Agenten selbst bauen, Modelle frei tauschen, lokale Modelle anbinden oder auf einem älteren Android wie einem Pixel 6a leben will, fährt mit pi besser; das 21 zu 20 ist das Argument, die 2,4-fache Token-Rechnung ist der Preis. Wer echte Ingenieursaufgaben übergibt, im Team arbeitet und Sicherheitsdefaults kaufen will, ohne sie selbst zu bauen, nimmt Codex und spart dabei rund die Hälfte an Tokens. Was das Nutzungs-Limit-Modell von Codex im Alltag wert ist, habe ich an anderer Stelle ausgehandelt (https://hunter-cyberdeck.d4sn3st.dev/post.html?slug=codex-nutzungslimits-8-millionen). Die ehrliche Faustregel lautet: bauen oder bedienen, beides geht, aber beides gleichzeitig kostet doppelt.

Ein Wort zur Ehrlichkeit: ein Benchmark ist eine Momentaufnahme. Ein Modell, DeepSeek V4 Pro (0813), ein Router, 30 Aufgaben, ein Datum, der 20.09.2026. Nichts davon ist eine allgemeine Marktbehauptung, und beide Projekte bewegen sich täglich. Codex hat heute die Release-Nummer 1.145 gesetzt und einen MCP-Fix zu Credential-Grenzen eingebaut, pi hat heute Commits zur RPC-Disposition geliefert. Wer die Zahlen in drei Wochen zitiert, sollte beide Repos erneut öffnen. Meine eigenen Messwerte stammen aus dem stability-snapshots.log und den Tagesnotizen vom 25.09.2026, mit Stichtag angegeben, nicht als Dauerzustand verkauft.

Was ich weiter beobachte: ob pi die Token-Lücke schließen kann, ohne seine Philosophie aufzugeben, und ob Codex den fehlenden Punkt mit Modellen schließt, die auf seinen Harness trainiert sind. Nächste Kontrolltermine sind pi v0.88 und Codex Release 1.146. Bis dahin gilt die ehrliche Tabelle: pi einen Punkt vorn, Codex mit halbem Token-Konto, und die Wahl hängt daran, ob ihr einen Agenten bauen wollt oder nur bedienen. Beides ist legitim, aber nur eines ist meins.

Ich bin Marcel, Grafikdesigner und Betreiber des HUNTER-Cyberdecks auf einem gebrauchten Google Pixel 6a. Für diesen Beitrag habe ich die Benchmark-Daten von Composio mit dem Live-Stand beider Repos am 25.09.2026 abgeglichen und meine eigenen Betriebszahlen aus stability-snapshots.log und den Tagesnotizen vom selben Tag daneben gelegt. Die Messwerte stammen aus dem Alltagsbetrieb der Agentenfamilie auf diesem Telefon. Zuletzt fachlich geprüft am 25.09.2026.

Composio: Pi Agent vs OpenAI Codex, 20.09.2026, abgerufen am 25.09.2026. https://composio.dev/content/pi-agent-vs-codex

GitHub: earendil-works/pi (Releases, Sternzahl), abgerufen am 25.09.2026. https://github.com/earendil-works/pi

GitHub: openai/codex, Release v0.157.0 vom 25.09.2026, abgerufen am 25.09.2026. https://github.com/openai/codex/releases

Augmentcode: OpenAI releases Codex CLI, Repo-Daten Stand April 2026, abgerufen am 25.09.2026. https://www.augmentcode.com/learn/openai-codex-cli-terminal-agent

Eigene Messung: stability-snapshots.log (Stichtage 21.09. und 25.09.2026) und Tagesnotizen 2026-09-25, Pixel-Cyberdeck.