Oktober-Stichtag: das Release-Tempo der Coding-Agenten nach drei Wochen

Vor drei Wochen habe ich das Release-Tempo der Coding-Agenten gezählt und am Ende drei offene Fragen stehen lassen. Am 27. September 2026 stand die Codex-CLI bei 134 Releases in 30 Tagen, mehr als vier pro Tag, und ich versprach einen zweiten Stichtag mit identischem Verfahren und der kanalreinen Zählung als zweite Spalte. Heute ist dieser Stichtag fällig: 19. Oktober 2026, dieselben sieben Repositories, diesmal mit der Auszählung, die ich damals offen schuldig blieb. Die Kurzfassung vor allen Zahlen: Der Codex-Takt hält auf dem Papier, aber die Kanal-Rechnung zeigt, dass rund neun Zehntel davon aus dem Vorab-Kanal kommen. Die Gemini-CLI fällt kanalrein aus der Spitzengruppe, weil ihr Nacht-Build den Wert treibt. Und pi hat den gebündelten Major geliefert, den ich nachgefragt hatte. Ein Stichtag war nie die Pointe, die Richtung ist es.

Damit die zwei Stichtage vergleichbar bleiben, habe ich an der Zählweise nichts geändert. Die GitHub-API fragt dieselben sieben Repositories ab wie am 27. September: Codex CLI, Gemini CLI, OpenClaw, OpenCode, pi, Hermes Agent und herdr. Das Fenster ist auch heute ein rollender 30-Tage-Zeitraum bis zum Abruf, die Baseline steht im Septemberbeitrag vom 27.09.2026, 07:17 Uhr CEST. Neu ist die Kanal-Spalte: Jeder Release wird als stabil oder Vorab klassifiziert, abgeleitet aus dem Tag-String und dem Prerelease-Flag von GitHub, Alpha-, Beta- und Kandidaten-Tags zählen damit nicht mehr stillschweigend als fertige Versionen. Die Commits der letzten sieben Tage kommen erneut über die Search-API, dieselbe Methode wie im September, mit derselben Grenze: Die Suche läuft über alle Branches und liefert eine Stichprobe, keine Vollrechnung. Mein Abruf lief am 19.10.2026 über die öffentlichen Endpunkte, das Skript liegt im Vault, jeder kann dieselbe Abfrage heute selbst fahren. Die Gesamtzahl aller Releases seit Repo-Start habe ich heute bewusst nicht neu gezählt, für die Fenster-Vergleiche genügen die ersten Seiten der Releases-Liste, das ist die ehrliche Abgrenzung.

Alle Werte sind eigene Messungen vom 19.10.2026, gegen die Basiswerte vom ersten Stichtag. Sortiert nach Releases in den letzten 30 Tagen, die neue Spalte trennt den stabilen Kanal vom Vorab-Kanal. Die Commits-Zahlen aus der Search-API mit Vorsicht lesen, sie durchsuchen alle Branches des Repositorys und sind deshalb eine Stichprobe.

Die Antwort ist ein Ja mit Fußnote. In dem rollenden Fenster der letzten 30 Tage stehen für Codex 129 Releases, am ersten Stichtag waren es 134. Das Release-Tempo bleibt also mit grob vier pro Tag in derselben Liga, der Takt hat sich nach dem Alpha-Schub des Septembers nicht abgeflaut. Die Fußnote steht in der Kanal-Spalte: Nur 15 der 129 Releases kommen aus dem stabilen Kanal, 114 sind Alpha- und Vorab-Tags. Genau diese Lücke hatte ich im September markiert, die kanalreine Zählung würde zeigen, ob der Dauerfluss aus fertigen Versionen besteht oder aus einem Versuchsfeld. Jetzt liegt sie vor, und sie zeigt Letzteres. Im stabilen Kanal liefert Codex grob alle zwei Tage einen fertigen Tag, dazwischen läuft das Alpha-Band im Dauerfluss. Der neueste Eintrag im Fenster heißt rust-v0.164.0-alpha.3 vom 17. Oktober, der stabile Tag rust-v0.163.0 erschien am 15. Oktober. Wer dieses Tempo als Qualitätsurteil liest, macht denselben Fehler wie im September: Tempo misst Auslieferung, nicht Nutzwert.

Ja, und zwar deutlich. In der ungefilterten Liste steht die Gemini-CLI mit 36 Releases in 30 Tagen weiterhin weit oben, nur knapp unter dem Wert von 38 vom ersten Stichtag. Kanalrein bleiben davon 4 stabile Releases, die übrigen 32 sind Nacht-Builds. Die Frage vom September war, ob der Nacht-Kanal den 30-Tage-Wert treibt, und die Antwort ist ein klares Ja, fast vollständig sogar. Die Spur der Sterne ändert sich kaum: 277 Sterne Zuwachs seit dem 27. September, bei einer Basis von 107.164 der kleinste Zuwachs im Feld. Wer nur die ungefilterte Liste liest, hält das Projekt für einen der aktivsten Teilnehmer, wer nur die Kanal-Spalte liest, hält es für beinahe still. Beides ist zugleich wahr, und genau deshalb ist die ungefilterte Zahl nicht falsch, aber sie verschweigt die Release-Kultur.

pi hat geliefert, und zwar mit Kalender. Die Version 1.0.0 erschien am 1. Oktober, v1.1.0 folgte am 7., v1.2.0 am 12., v1.3.0 am 15. Oktober. Vier gebündelte Stände in zwei Wochen, vom 1. bis zum 15. Oktober, alle aus dem stabilen Kanal, dazu 131 Commits in den letzten sieben Tagen nach 97 im September. Die Kombination aus lautem Entwickeln und wenigen Releases hat sich nicht aufgelöst, sie hat sich professionalisiert: pi veröffentlicht jetzt häufiger, aber weiterhin gebündelt und ohne Vorab-Kanal. Die Sternenspur bestätigt die Erzählung: 6.615 Sterne Zuwachs seit dem 27. September, der stärkste Zuwachs im Feld, knapp vor OpenCode mit 6.551. Die Frage vom Septembertext lautete, ob die Kombination aus Commits pro Woche und wenigen Releases hält oder ob ein gebündelter Major kommt. Beides ist eingetroffen, der Major kam, und die Commit-Spur läuft weiter.

OpenCode bleibt bei seinem Rhythmus: 8 Releases in 30 Tagen, alle aus dem stabilen Kanal, als neuester Tag v1.19.3 vom 16. Oktober. Nach den Patch-Tagen vom 15. und 16. Oktober sitzt das Projekt im ruhigen Patchmodus, und die Sterne legen trotzdem um 6.551 zu. OpenClaw beschleunigt sichtbar: 23 Releases in 30 Tagen nach 12 im September, davon 15 stabil, dazu laut Search-API 6.208 Commits in sieben Tagen, die dichteste Aktivität im Feld, mit dem Vorbehalt der Branch-Zählung. Der Hermes Agent hält die dritte Release-Kultur durch: 7 Releases in 30 Tagen, alle stabil, der neueste Tag v0.22.2 vom 15. Oktober, bei 3.240 Commits in sieben Tagen, gebündelt und kuratiert statt im Dauerfluss. herdr schließlich zeigt, wie ein kleines Werkzeug mit zwei Kanälen arbeitet: 10 Releases in 30 Tagen, 4 stabil, 6 Vorab, der neueste stabile Tag v0.9.5 vom 14. Oktober, dazu 3.766 Sterne Zuwachs in drei Wochen.

Meine Lektion aus dem zweiten Stichtag ist eine Betriebsentscheidung, keine Prognose. Auf dem Deck läuft ein Stack, der auf Android Kills überstehen muss, nicht verhindern kann, und deshalb zieht pi als Worker unter herdr nur nach Prüfung auf einen neuen Stand, nicht am Veröffentlichungstag. Der Snapshot vom Morgen des Messtags zeigt die Betriebsrechnung: 306 von 306 Gateway-Checks alive in sieben Tagen, 2 OOM-Kills, 1.069 MiB freier Arbeitsspeicher, 13 Jobs, das System war gesund. Tempo ist ein Angebot, Stabilität ist eine Entscheidung, und die Gates zwischen Draft und Veröffentlichung bleiben genau deshalb Teil meines Stacks. In der Tabelle liest sich der stärkste Sternen-Zuwachs bei pi, der zweitstärkste bei OpenCode, und die Commits-Spuren zeigen überall Dauerbetrieb. Für meinen Alltag zählt eine andere Spalte: Wie viel neue Stabilität und wie viel neues Risiko steckt in jedem Stand, den ich nachziehe. Genau diese Frage kann kein Release-Zähler beantworten, sie beantwortet der Betrieb selbst.

Ausdrücklich die Grenzen. Die Kanal-Klassifikation kommt aus dem Tag-String und dem Prerelease-Flag, nicht aus der Absicht des Projekts, ein Nacht-Build ohne Flag fiele in meiner Spur fälschlich unter die stabilen Releases. Die Commits-Zahlen der Search-API laufen über alle Branches, ein Vergleich zwischen zwei Stichtagen kann deshalb aus einer veränderten Branch-Struktur stammen, die Werte bleiben eine Stichprobe. Die Gesamtzahl aller Releases seit Repo-Start habe ich heute nicht neu abgerufen, die Fenster-Vergleiche stammen aus den ersten Seiten der Releases-Liste, was für Werte seit dem 26. September genügt. Ein Abruf ohne Token trifft Ratenlimits, mein Skript legte deshalb Pausen zwischen den Abfragen ein. Sterne über einen einzelnen Tag wären Nebensache, deshalb stehen hier Fenster über drei Wochen, bei allen sieben Repositories dieselbe Basis vom ersten Stichtag. Und zwei Stichtage machen aus zwei Werten eine Richtung, keine Linie: Der dritte Stichtag wäre der nächste Messpunkt, nicht der Beweis eines Trends.

Ich bin Marcel, Grafikdesigner und Betreiber des HUNTER-Cyberdecks auf einem gebrauchten Google Pixel 6a. Die Releases-, Commit- und Sterne-Zahlen dieses Beitrags habe ich am 19.10.2026 selbst über die GitHub-API abgerufen, die Basiswerte stammen aus meiner Messung vom 27.09.2026, 07:17 Uhr CEST. Der Betriebs-Snapshot vom Messtag um 07:00 Uhr steht im Vault unter stability-snapshots. Redaktionelle Verantwortung: Marcel. Zuletzt fachlich geprüft am 19.10.2026.