Ein Kern, viele Schalen: Warum Coding-Agenten zu Engines werden
Cline legt einen Agent-Kern auf drei Oberflächen, Hermes rollt rund 1.800 Pull Requests in einen stabilen Tag und macht laut Berichterstattung Codex zur Engine, Codex CLI steht bei 125.962 Sternen. Was Kern und Schale für den Agenten-Betrieb bedeuten, mit eigenen Messwerten.
Kein fertiges Produkt und keine Hochglanz-Rückschau: Dieser Eintrag hält fest, was gebaut, getestet, verworfen und als Nächstes überprüft wird.
Coding-Agenten trennen sich gerade in zwei Hälften: der Kern, der die Arbeit macht, und die Schale, die du anfassen kannst. Das ist keine Theorie von mir, das lese ich aus vier Spuren der letzten zwei Wochen heraus. Cline hat mit v4.1.19 einen Agent-Kern auf drei Oberflächen gelegt, Kommandozeile, SDK und Desktop. Hermes Agent hat mit v0.21.4 rund 1.800 gemergte Pull Requests in einen stabilen Tag gerollt und mit der Plugin-Welle vom 23. September anderen Engines den Platz an seiner Seite eröffnet, AlphaSignal verdichtet diesen Wechsel zu einem Satz: Hermes macht Codex zur Engine und sich selbst zur Schale. Auf der Leaderboard-Seite stehen Codex CLI mit 125.962 Sternen und Gemini CLI mit 107.130 Sternen, beide unter Apache-2.0. Für meinen Betrieb auf dem 45-Euro-Handy ist daraus ein Satz geworden, den ich in diesem Beitrag mit Zahlen belege: Engines pinnen, Schalen updaten, und die Gates hängen an meinem Betrieb, nicht an der Engine.
Vier Spuren bei den Coding-Agenten, ein Muster
Die Cline-Spur ist die am klarsten geschnittene. Mit v4.1.19 vom 17. September liegt der Agent-Kern unter drei Oberflächen, der Kommandozeile, dem SDK und dem Desktop. Ein Kern, drei Anfassstellen, derselbe Agent darunter. Für Teams heißt das, dass sie den Kern tauschen können, ohne die Frontends neu zu bauen, für Solobetreiber heißt das, dass sich Anzeige und Motor trennen. Die Hermes-Spur ist die größte Zahl des Monats: v0.21.4 hat laut Release-Notiz rund 1.800 Pull Requests seit v0.21.3 in einen stabilen Tag gerollt, mit Blick auf Downstream-Nutzer wie Docker-Images, Hermes Cloud und gehostete Deployments. v0.21.5 legte am 24. September rund 460 weitere nach, bewusst als Patch-Tag, kuratierte Notizen sollen erst mit v0.22.0 folgen. Davor, am 23. September, rollte die Plugin-Welle: vier offizielle Plugins und 96 Community-Plugins, und die Berichterstattung liest das als Wechsel im Bauplan, nicht als Sammlung von Gimmicks.
Die Berichterstattung von AlphaSignal bringt den Hermes-Wechsel auf die Formel 'Hermes just made Codex the engine and itself the shell' und zeigt als Einstieg den Plug-in-Marktplatz: 'codex plugin marketplace add openai-curated', danach 'codex plugin install' für Linear, GitHub, Gmail und Calendar. Ich zähle diesen Artikel bewusst zur Berichterstattung, nicht zur offiziellen Dokumentation. Die Zahlen, die ich in diesem Beitrag verwende, stammen deshalb aus drei Sorten von Quellen: Release-Zeilen aus dem offiziellen Releases-Feed von Hermes Agent, Leaderboard-Werte von Morphllm, Stand September 2026, und meine eigenen Messtermine aus dem Vault. Die Zuordnung ein Kern, drei Oberflächen für Cline stammt aus einer Sekundärübersicht mit Changelog-Verweis, und ich markiere die Grenze später im eigenen Grenzen-Abschnitt.
27.09.2026: Der Liga-Beitrag misst das Release-Tempo der Coding-Agenten: 1.158 Releases, 134 in 30 Tagen, 271 in 90 Tagen.
29.09.2026, 06:59 Uhr CEST: Eigene Sternen-Messung: Hermes 249.852, OpenCode 210.679, Codex 127.009, pi 110.166, herdr 41.300.
30.09.2026: Radar nimmt die Hermes-Release-Spur auf: rund 1.800 Pull Requests in v0.21.4, rund 460 in v0.21.5.
01.10.2026: Die Berichterstattung liest Hermes als Schale über einer fremden Engine, dieser Beitrag legt die Messwerte dagegen.
Diese Stichtage liest man am besten als Spur, nicht als Urteil. Der Abstand zwischen 1.158 Releases in 90 Tagen auf der einen Seite und einem einzigen gepinnten Kern in meinem Betrieb auf der anderen ist genau der Punkt, um den es in diesem Beitrag geht. Das Tempo oben bleibt hoch, und ich halte unten einen Stand, der nachprüfbar bleibt.
Was Sterne wirklich messen
Ein Leaderboard zählt Aufmerksamkeit, keine Qualität. Ich benutze die Zahlen trotzdem, aber mit einer klaren Lesart: Ein Stern sagt, dass jemand das Projekt benutzt hat und es auffällig genug war, dass ein Stern gesetzt wurde. Er sagt nichts über Stabilität über 88 Stunden, nichts über Update-Risiken auf einem Android-Handy und nichts darüber, welche Engine in welcher Schale läuft. Interessant ist der Vergleich der Messpunkte: Codex CLI stand am 22. September bei 125.962 Sternen, meine eigene Messung vom 29. September ergab 127.009, innerhalb einer Woche also ein Zugewinn von rund tausend Sternen. Gemini CLI lag am 15. September bei 107.130. Meine eigene Tabelle aus dem Vault sortiert die Reihe anders als die allgemeine Wahrnehmung: Hermes mit 249.852 vor OpenCode mit 210.679, Codex mit 127.009, pi mit 110.166, herdr mit 41.300. Drei der fünf Projekte betreibe ich aktiv oder werte ich aus, und gerade der Abstand zwischen Hermes und herdr zeigt, wie weit Aufmerksamkeit und tatsächlicher Betrieb auseinanderliegen können.
Warum meine Engine bei 0.87.1 eingefroren bleibt
Mein Ausführungs-Kern ist pi, gepinnt auf Version 0.87.1, angebunden über herdr, orchestriert von Hermes. Der Pin ist keine Bequemlichkeit, er ist eine Konsequenz aus der Betriebsgeschichte dieses Decks. Am 28. August habe ich den OOM-Sturm erlebt: fünf Gateway-Tode und ein Kill durch Android, Chromium als Beweis, dass das Betriebssystem bei Speicherdruck gewinnt. Der Weg hinaus lief über einen externen Cron-Tick und einen semantischen Watchdog, und der 88-Stunden-Rekord danach, vom 28. August um 19:40 Uhr bis zum 1. September um 12:18 Uhr, zeigt nicht, dass nichts passiert, sondern dass der Stack Kills übersteht, weil er genau dafür gebaut wurde. Jeder Update-Zyklus auf Android trägt dieses Risiko: Das Handy verwaltet Speicher aggressiv, ein Update zur falschen Zeit kann genau den Kill erzeugen, den die Härtung abfedern soll. Deshalb bleibt die Engine stehen, bis ein Update einen Prüfplan hat, und die Schale darf sich bewegen, weil sie gegen die gepinnte Engine nichts verschiebt.
Der Kern-Schalen-Wechsel macht diese Trennung erst richtig nützlich. Schienen-Gate, Wortziel-Gate und der Zwillings-Beitrag hängen in meinem Betrieb an der Pipeline, nicht an der Engine dahinter: Vor jedem Draft läuft das Schienen-Gate, das Wort-Gate zählt den Haupttext an der gespeicherten Fassung, und der EN-Zwilling wird im selben Lauf angelegt. Wenn die Schale morgen eine andere Engine lädt, bleiben meine Gates dieselben, und die Messtermine im Vault bleiben vergleichbar. Wichtig für die Richtigkeit meiner Geschichte: Die zwei verifizierten Projekte mit 36 von 36 bestandenen Tests sind im lokalen pi-Workflow entstanden, Hermes plant, pi führt aus, Hermes prüft. Der Weg über ChatGPT und Codex auf dem MacBook ist bei mir geplant und nicht im Einsatz, und solange nichts anderes belegt ist, schreibe ich ihn auch nicht als gelebt. Wenn ich irgendwann die Codex-Engine-Schiene hinter Hermes teste, steht das hier mit Datum, Prüfplan und Messwerten.
Was ich an einem Kern-Tausch prüfen würde
Falls eine Schelle die Engine tauscht, zum Beispiel Hermes mit Codex dahinter, wäre mein Prüfplan klar. Erst ein Trockenlauf ohne Rechte: dieselbe kleine Aufgabe zweimal gestellt, die gepinnte pi-Schiene gegen die neue Schiene, Ergebnisse nebeneinander, Protokolle an. Dann die Fehlverhaltensfälle: Was passiert, wenn ein Weg blockiert ist, genau die Frage, die der Transluce-Report vom 23. September belegt hat, mit Agenten, die bei banalen Datenaufgaben Umwege über fremde Dienste gebaut haben. Dann die Kosten-Ziffern: Tokens, Laufzeit, Requests, weil mein Betrieb unter einem 5-Stunden-Fenster und einem Wochenlimit läuft und Zahlen nur aus dem eigenen Dashboard belegt werden. Dann die Gates: Bleibt das Schienen-Gate vor dem Draft, bleibt die Wort-Zählung an der gespeicherten Fassung, bleibt der Zwilling im selben Lauf. Erst wenn alle vier Stationen belegt sind, wandert ein Engine-Tausch vom Test in den Betrieb, und die Entscheidung trägt ein Datum im Vault, kein Bauchgefühl.
Grenzen dieses Beitrags
Offen benannt: Ich habe die Kombination aus Hermes mit Codex als Engine nicht selbst betrieben, meine Aussagen dazu stammen aus dem Release-Feed und aus der Berichterstattung, nicht aus einer eigenen Testreihe. Die Zuordnung ein Kern, drei Oberflächen für Cline stammt aus einer Sekundärübersicht mit Changelog-Verweis, die GitHub-Releases-Seite von Cline habe ich für diesen Beitrag nicht vollständig geöffnet. Das Leaderboard ist der Snapshot eines einzigen Anbieters, Morphllm, Stand September 2026, und Sternenzahlen sind Stichtage, die sich täglich bewegen. Die Pull-Request-Rollup-Zahlen von Hermes sind Rundungsangaben aus den Release-Notizen, keine exakten Zählungen von mir. Meine eigenen Messwerte kommen aus einem einzelnen Gerät und einem einzelnen Vault, daraus folgt eine dokumentierte Praxis, keine Marktbehauptung. Und die Frage, welche Engine morgen in welcher Schale steckt, entscheidet sich in den kommenden Wochen, dieser Beitrag ist ein Stichtag am 1. Oktober 2026, keine Prognose.
Weiter im Blog
Agenten brechen aus der Sandbox aus: OpenAI stoppt zum zweiten Mal das Training ↗
Die Liga der Coding-Agenten: Was die GitHub-Sterne im September zeigen ↗
Agenten greifen Datenquellen an: Was der Transluce-Report belegt ↗
Die Tamagotchi-Betriebsanleitung: So hältst du einen Agenten am Leben ↗
Quellen (Abruf 30.09. und 01.10.2026)
Externe Quellen mit Abrufdatum:
- Hermes Agent, offizielles Releases-Feed auf GitHub, abgerufen am 30.09.2026: https://github.com/NousResearch/hermes-agent/releases
- Morphllm, Best AI Coding Agents 2026, Leaderboard-Stand September 2026, abgerufen am 30.09.2026: https://www.morphllm.com/best-ai-coding-agents-2026
- Cline, GitHub-Releases-Seite, abgerufen am 30.09.2026: https://github.com/cline/cline/releases
- AlphaSignal, 'Hermes Just Made Codex the Engine and Itself the Shell', abgerufen am 01.10.2026: https://alphasignalai.substack.com/p/hermes-just-made-codex-the-engine
Eigene Messwerte: Sternen-Snapshot vom 29.09.2026, 06:59 Uhr CEST, Tempo-Spur vom 27.09.2026, pi-Pin 0.87.1, alle aus dem Vault mit Stichtag und Grenze im Text.
Was heißt Kern und Schale bei Coding-Agenten?
Der Kern ist die Agent-Engine, die Aufgaben ausführt, die Schale ist die Oberfläche, mit der du arbeitest, Kommandozeile, SDK oder Desktop. Die Trennung erlaubt, beide Seiten in getrennten Takten zu bewegen, eine Seite gepinnt, die andere upgedatet.
Steht Codex jetzt fest in Hermes eingebaut?
Die Berichterstattung beschreibt Codex als Engine hinter der Hermes-Oberfläche plus einen Plug-in-Marktplatz. Ich fahre diese Kombination selbst nicht, mein Ausführungs-Kern bleibt pi in Version 0.87.1, und meine verifizierten Ergebnisse stammen aus dem lokalen Workflow.
Warum ist pi eingepinnt?
Weil jeder Update-Zyklus auf Android ein Speicherdruck-Risiko ist, der OOM-Sturm vom 28. August mit fünf Gateway-Toden der belegte Grund ist und 88 Stunden saubere Laufzeit nach der Härtung der belegte Effekt. Ein Update bekommt erst dann Zugriff auf dieses Deck, wenn ein Prüfplan dazu existiert.
Was sagen die GitHub-Sterne aus?
Einen Aufmerksamkeits-Snapshot an einem Messdatum, kein Qualitätsurteil. Nutze datierte Messpunkte, führe den eigenen Snapshot und behandle Zahlen nur dann als vergleichbar, wenn das Messdatum daneben steht.
Was soll ein Solobetreiber daraus tun?
Engine pinnen, Schale updaten, die Gates an die eigene Pipeline hängen und jeden Tausch mit Datum und Prüfplan im Log halten. Genau diese Reihenfolge dokumentiert dieser Beitrag mit meinen eigenen Betriebs-Zahlen.
Über den Autor
Über den Autor: Ich bin Marcel, Grafikdesigner und Betreiber des HUNTER-Cyberdecks, eines Agenten-Setups auf einem gebrauchten Google Pixel 6a. Dieser Beitrag stützt sich auf öffentliche Release-Zeilen, einen Leaderboard-Snapshot und meine eigenen Betriebs- und Mess-Zahlen aus dem Vault, Stichtage 27.09., 29.09. und 01.10.2026. Zuletzt fachlich geprüft am 01.10.2026.
Nachgebaut oder getestet?
Teile deine Erfahrung mit genau diesem Build-Log. Reviews werden vor der Veröffentlichung moderiert.
Noch keine Reviews für diesen Eintrag.
Fragen, Reaktionen und Verbesserungen werden direkt über GitHub Discussions eingebettet.
GitHub-Bereich öffnen ↗