Release-Tempo der Coding-Agenten: Codex liefert 134 Releases in 30 Tagen

Gestern habe ich die Sternen-Liga der Coding-Agenten gezählt, heute zähle ich, was die Projekte tatsächlich ausliefern. Die Radarnotiz vom 25. September hatte es vorbereitet: Die OpenAI-Codex-CLI stand bei Release Nummer 1.145, der Code wurde am selben Tag gepusht, und die Frage war, ob Sterne und Release-Tempo überhaupt dieselbe Geschichte erzählen. Die Antwort nach eigener Messung am 27. September 2026 um 07:17 Uhr CEST: Nein, und die Trennung ist aufschlussreicher als jede Bestenliste. Die Codex-CLI hat inzwischen 1.158 Releases, davon 134 in den letzten 30 Tagen, das sind mehr als vier pro Tag. Die Gemini-CLI dagegen verlor seit gestern zwei Sterne, 107.164 statt 107.166, und hat trotzdem 38 Releases im letzten Monat veröffentlicht. Zwei Spuren, die sich trennen: Aufmerksamkeit auf der einen Seite, Auslieferung auf der anderen. Wer mit diesen Werkzeugen arbeitet, sollte beide lesen, denn die Sterne sagen, wer beobachtet wird, und die Releases sagen, wer liefert.

Vor den Zahlen die Methodik, denn ein Tempo ohne Zählregeln ist eine Meinung. Ich habe die GitHub-API über die Releases-Endpunkte aller sieben Projekte abgefragt, mit authentifiziertem Token, und für jedes Repository drei Dinge gezählt: die Gesamtzahl der veröffentlichten Releases, die Releases der letzten 30 Tage und die der letzten 90 Tage, jeweils zum Abrufzeitpunkt 27.09.2026, 07:17 Uhr CEST. Dazu kamen die Sterne und der letzte Code-Push aus den Repository-Stammdaten und die Commits der letzten sieben Tage über die Search-API, für Codex 443 und für pi 97. Eine Grenze steht von Anfang an im Raum: Ich zähle, was GitHub als Release listet, also auch Alpha-Tags, Preview-Builds und Nachtversion. Die Gemini-CLI steht deshalb mit ihrem Nacht-Kanal zwangsläufig hoch im 30-Tage-Wert. Ein Release ist außerdem kein Nutzwert: Was in jedem Release steckt, sagt die Changelog-Notiz, nicht der Zähler. Die Messung ist trotzdem ehrlich, weil sie nachweisbar ist, jeder kann dieselbe Abfrage heute selbst fahren und die Zahl gegenprüfen.

Die Tabelle zeigt die Releases-Zahlen der eigenen Messung, sortiert nach dem 30-Tage-Wert, dazu die Sterne zum Vergleich mit der gestrigen Liga. Die Bewegung der Sterne seit dem 26.09. steht in der letzten Spalte, sie ist bewusst klein gehalten, denn ein Tag ist keine Kurve.

Der Wert braucht eine Übersetzung, denn vier Releases pro Tag klingen erst einmal nach Marketing. Sie sind das Gegenteil: Ein Projekt, das 134 Mal im Monat einen Release-Titel in die Liste schreibt, verteilt seine Änderungen in kleine Portionen, und genau das ist die Voraussetzung dafür, dass Fehlschläge klein bleiben. Die Lebenszeit-Rechnung macht den Trend sichtbar. Seit dem Bestehen des Repositories am 13. April 2025 sind es im Durchschnitt gut zwei Releases pro Tag, im letzten Monat sind es mehr als vier, das Tempo hat sich also im Lauf des Jahres beschleunigt, nicht nur gehalten. Die Search-API zählt 443 Commits in sieben Tagen, auch das ist Dauerbetrieb und nicht Release-Tourismus. Die Sprachstatistik zeigt dazu 70,4 Megabyte Rust gegen rund 1,7 Megabyte Python, die CLI ist zu 97 Prozent Rust, wie es die Radarnotiz vom 26. September schon vermuten ließ.

Der neueste Tag heißt rust-v0.159.0-alpha.8 und erschien am Morgen des Messtags, das Alpha im Namen ist Teil der Wahrheit: Ein Teil der 134 ist Vorab-Auslieferung an Mutige, nicht fertiges Produkt. Genau deshalb lese ich die Zahl nicht als Qualitätsurteil, sondern als Betriebsweise. Ein Takt wie dieser bedeutet, dass Changelogs zur Hauptlektüre werden, dass jede Version innerhalb von Tagen überholt ist und dass der Nutzer eines solchen Harnesses selbst zum VersionManager wird, ob er will oder nicht. Der Bericht von MightyBot, der seit September GPT-6 Astra als gebündeltes Standardmodell der Codex-CLI nennt, behandele ich bewusst als Sekundärquelle mit offenem Primärnachweis: Er passt ins Bild eines Projekts, das im Wochentakt ausliefert, aber ein Bericht ist keine Messung, und diese Unterscheidung ist der Punkt des ganzen Beitrags.

Der aufregendste Wert der Tabelle steht bei der Gemini-CLI: 38 Releases in den letzten 30 Tagen, 110 in 90 Tagen, der Nacht-Build von gestern ist gelistet, und gleichzeitig sind seit gestern zwei Sterne abhandengekommen. Wer nur Sterne liest, hält das Projekt für eingeschlafen, wer nur Releases liest, hält es für einen der aktivsten Teilnehmer des Feldes. Beides ist falsch, die Wahrheit steht zwischen den Spuren: Das Projekt liefert im Dauerbetrieb, gewinnt damit aber keine Aufmerksamkeit zurück, jedenfalls nicht in einem messbaren Sternen-Tick. pi zeigt die Umkehrung desselben Phänomens: nur 7 Releases in 30 Tagen, dafür 97 Commits in sieben Tagen, der neueste Tag v0.87.1 vom 22. September, und die Sterne legten seit gestern um 205 zu. pi entwickelt laut, veröffentlicht gebündelt und sammelt Beobachter, Codex veröffentlicht im Dauerfluss. Es gibt keine richtige Richtung, es gibt zwei Release-Kulturen, und die Wahl zwischen ihnen ist eine Betriebsentscheidung, keine Glaubensfrage.

Auf dem Deck läuft die dritte Release-Kultur, und die ist für meinen Alltag die wichtigste Lektion dieser Messung. Der Hermes Agent steht bei 36 Releases gesamt, 7 in den letzten 30 Tagen, und sein Patch-Release 0.21.4 vom 21. September rollt laut eigenem Changelog rund 1.800 gemergte Pull-Requests in einen einzigen getaggten Stand. Das ist das Gegenteil des Codex-Takts: selten, dafür gebündelt, mit kuratierten Notizen statt mit 134 Einzel-Changelogs. Für den Betrieb auf einem Android-Handy ist das keine Geschmackssache, sondern Überlebensrechnung. Jeder Update-Zyklus ist ein Risiko, und mein Anker ist der 88-Stunden-Rekord aus dem eigenen Betrieb, 28. August 19:40 Uhr bis 1. September 12:18 Uhr ohne Unterbrechung, danach null OOM-Kills seit der Härtung. Ein Stack, der Kills übersteht, braucht Releases nur, wenn sie einen nachweisbaren Fehler beheben, und genau deshalb fahre ich pi auf dem festen Stand 0.87.1 statt im Tagesakt. Die 36 von 36 Tests meiner verifizierten Projekte entstanden über den lokalen pi-Workflow, Hermes plant, pi führt aus, Hermes verifiziert, nicht über einen Cloud-Dienst. Tempo ist ein Angebot, Stabilität ist eine Entscheidung.

Ausdrücklich die Grenzen. Meine Zählung nimmt GitHub beim Wort: Jeder veröffentlichte Release zählt, auch der Alpha-Tag, der am Messtagmorgen erschien, auch die Nachtversion der Gemini-CLI, und ein Release ohne Changelog-Notiz ist in dieser Spur ein Release wie jeder andere. Kanalreine Zählung, also stabile Tags ohne Vorab-Versionen, wäre der nächste Messschritt und steht noch aus, deshalb sind die Werte ein Obermaß, kein Feinschliff. Ein Stichtag ist kein Trend: Erst der zweite Stichtag im Oktober macht aus zwei Werten eine Richtung, bis dahin ist jede Aussage über Beschleunigung an einen einzigen Vergleichspunkt gebunden, den Durchschnitt über die gesamte Repo-Lebenszeit. Die Commits-Zahlen aus der Search-API sind Stichprobe, keine Vollrechnung, und die Sterne-Bewegung über einen einzelnen Tag ist bewusst als Nebensache markiert. Wer aus dieser Tabelle eine Marktprognose baut, überspringt die Messgrenzen, und ich baue bewusst keine.

Für den Oktober steht die Wiederholung an, mit denselben sieben Repositories, demselben Verfahren und einem festen Stichtag, dazu die kanalreine Zählung als zweite Spalte. Drei Fragen leiten den nächsten Lauf: Bleibt Codex über vier Releases pro Tag, oder normalisiert sich der Takt nach dem Alpha-Schub? Fällt die Gemini-CLI in der kanalreinen Zählung aus der Spitzengruppe, weil der Nacht-Build den 30-Tage-Wert treibt? Und hält pi die Kombination aus 97 Commits pro Woche und wenigen Releases durch, oder kommt ein gebündelter Major, der die Sternenspur bestätigt? Alle Zahlen dieses Beitrags stammen aus öffentlichen Endpunkten, die Abfrage ist eine Sache von Minuten, und der Stichtag steht in der ersten Zeile dieses Abschnitts.

Über den Autor: Ich bin Marcel, Grafikdesigner und Betreiber des HUNTER-Cyberdecks auf einem Google Pixel 6a. Die Releases- und Commit-Zahlen dieses Beitrags habe ich am 27.09.2026 um 07:17 Uhr CEST selbst über die GitHub-API abgerufen, die Sternen-Basiswerte stammen aus meiner Messung vom 26.09.2026. Die Betriebsanker stehen im Vault: stability-snapshots für die 88-Stunden-Reihe, die Radarnotizen seit dem 25.09. Zuletzt fachlich geprüft am 27.09.2026.

Quellen: GitHub-API-Abfragen über die Releases-Endpunkte und die Sprachstatistik von openai/codex, earendil-works/pi, google-gemini/gemini-cli, sst/opencode, NousResearch/hermes-agent, openclaw/openclaw und herdrdev/herdr, jeweils Abruf 27.09.2026, 07:17 Uhr CEST, authentifiziert. GitHub-Search-API für Commits der letzten sieben Tage, gleicher Abruf. Release-Notiz Hermes Agent v0.21.4 vom 21.09.2026 mit rund 1.800 gemergten Pull-Requests, GitHub-Releases-Seite. Eigene Sternen-Messung vom 26.09.2026, 07:03 Uhr CEST, Radar im Vault. Radarnotizen vom 25. und 26.09.2026 zu Codex v0.157.0 als Release Nummer 1.145. MightyBot-Bericht zu Coding-Agenten als ausdrücklich gekennzeichnete Sekundärquelle mit offenem Primärnachweis. Marc Bara, Build-Log zum Hermes Agent, Medium, gelesen am 27.09.2026.