KI-Agenten mit zwei Gehirnen: ChatGPT denkt, Codex baut

Ein Repository auf GitHub hat in wenigen Tagen über zweitausend Sterne gesammelt, und sein Name ist Programm: codex-with-chatgpt. Die Arbeitsteilung lautet ChatGPT denkt, Codex baut. Die eigentliche Frage ist nicht, ob das funktioniert, sondern warum, und was ein Betrieb wie mein auf einem 45-Euro-Handy damit zu tun hat. Die Antwort lautet Kontext-Hygiene. Meine Version dieses Musters hat zwei Projekte hervorgebracht, deren Testsuiten komplett bestanden: 36 von 36. Die Zahl zeigt funktionierende, geprüfte Ergebnisse des Workflows; dass gerade die Rollentrennung deren Ursache ist, bleibt ohne Gegenversuch offen. Für KI-Agenten ist dieser Beitrag die Mechanik-Erklärung, präzisiert, was lokal dabei eigentlich heißt, rechnet die Kosten nach und zeigt ein vollständiges Übergabebeispiel, wie ich es zwischen den Rollen laufen lasse. Eine Grenze gehört dazu: Diese Tests belegen die geprüften Funktionen dieser Fassung. Dass gerade die Rollentrennung der Grund für den Erfolg war, ist plausibel, aber ohne Gegenversuch nicht bewiesen.

XiaoDuoYa/codex-with-chatgpt trennt zwei Rollen, die sonst in einem Agenten kollidieren. Der Planer bekommt die Aufgabe, zerlegt sie und gibt Anweisungen weiter. Der Builder führt sie aus, schreibt Code und läuft Tests. Die Beschreibung im Repo bringt es auf den Punkt: ChatGPT denkt, Codex baut. Die Mechanik dahinter ist unspektakulär und genau deshalb wirksam: Ein Modell, das plant und gleichzeitig baut, füllt seinen eigenen Kontext mit Fehlermeldungen, Stacktraces und gelesenen Dateien, und irgendwann verdrängt das den ursprünglichen Plan. Wer die Rollen trennt, hält zwei Kontexte getrennt, und beide bleiben klein genug, um arbeitsfähig zu bleiben. Kein neues Wunder, sondern sauberes Handwerk, das aktuell genug Menschen neu lernen, dass es auf GitHub gefeiert wird.

Ein präziser Blick auf die Rollenverteilung lohnt sich, weil der Name des Repos vielversprechender klingt als die Technik. Codex ist OpenAIs Coding-Agent und läuft nach eigener Hersteller-Dokumentation über mehrere Oberflächen: als Kommandozeilen-Werkzeug, als IDE-Erweiterung, im Web und in der Desktop-Anwendung. In allen Varianten ist das Programm die Werkzeugseite, die im Auftrag arbeitet. Das Planungshirn im Repo ist ein Cloud-Modell mit eigenem Kontextfenster, das Aufträge formuliert und Ergebnisse bewertet. Genau diese zweistufige Architektur ist der Inhalt des Trends, nicht die Marke eines der beiden Werkzeuge.

Ich muss hier nichts spekulieren, ich kann es vorzeigen. In meinem Stack plant Hermes die Aufgaben, der pi-Agent baut, Hermes verifiziert. Zwei Projekte sind damit entstanden und beide haben ihre Tests komplett bestanden. Der Network Obfuscation Layer, ein Python-Proxy-Rotationssystem, kam auf 29 von 29 bestandene Tests, der Preiskompass, ein Reselling-Monitor mit SEO-Blog, auf 7 von 7, zusammen also 36 von 36. Die 36 beziehen sich auf die jeweiligen Testsuiten der beiden Projekte in den Versionen vom 30.08.2026, sie sind kein generelles Gütesiegel für jede künftige Fassung. Ich habe dabei keine Zeile Code selbst geschrieben, ich habe orchestriert: Aufgabe zerlegt, Übergaben formuliert, Ergebnisse gegen die Akzeptanzkriterien geprüft.

Zur Präzision eines Begriffs, den ich in der vorherigen Fassung dieses Beitrags zu großzügig verwendet habe: Der Stack läuft nicht komplett lokal. Der Host läuft lokal, ein gebrauchter Google Pixel 6a als Rechen- und Steuergerät, und die Planung läuft in der Cloud über ein angemietetes Modell. Wer solche Stacks vergleicht, sollte diese Grenze sauber ziehen, denn sie entscheidet über Kosten, Datenschutz und Ausfallverhalten. Das Trend-Repo hat dieselbe Eigenschaft, auch dort denkt ein Cloud-Modell und baut ein lokales Werkzeug. Der Unterschied zwischen beiden Varianten ist nicht die Architektur, sondern die Bauteile in den Rollen.

Dass der Trend nicht isoliert dasteht, zeigt die Umgebung: Ein De-AI-Schreibskill namens sepia bekam in derselben Zeitspanne 1.912 Sterne, und eine Messung über 17.000 Agenten-Läufe zeigt, dass die großen Coding-Agenten weiterhin einfache Werkzeuge wie grep wählen, wenn sie die Wahl haben. Der Markt sortiert sich Richtung einfacher, bewährter Bausteine, nicht Richtung mehr Magie. Diese Beobachtung ist eine Einordnung aus zweiter Hand, der Armature-Bericht ist im Quellenblock verlinkt, ich habe die 17.000 Läufe nicht selbst ausgewertet.

Weil Abstraktionen nützen, sobald man sie konkret sieht, hier die Struktur einer echten Übergabe aus dem Preiskompass-Bau, nachgebaut an den Originalaufzeichnungen. Der Planer bekommt die Aufgabe in drei Teilen. Erster Teil das Ziel: ein Skript, das Preisdaten einer Produktseite abfragt, normalisiert und in eine Tabelle schreibt. Zweiter Teil die Grenzen: keine Änderungen an Dateien außerhalb des Projekts, keine neuen Abhängigkeiten ohne Begründung, keine Netzaufrufe außerhalb der vorgegebenen Domäne. Dritter Teil die Akzeptanzkriterien: Das Skript muss mit einer Beispieldatei laufen, muss drei definierte Sonderfälle behandeln, und die Testsuite muss bestehen.

Der Builder erhält genau diese Notiz und liefert drei Dinge zurück: die geänderten Dateien mit kurzer Begründung je Änderung, die Ausgabe der Testsuite als Text, und eine Liste der Fälle, die er nicht bearbeitet hat. Diese dritte Rückgabe ist der unterschätzte Teil, weil sie dem Planer die Verifikation erlaubt, ohne den Bau zu wiederholen. Die Verifikation läuft als eigene Prüfung gegen die Akzeptanzkriterien, nicht als Zusammenfassung des Builders in dessen eigenen Worten. Erst wenn diese Prüfung bestanden ist, gilt der Auftrag als erledigt. In meinem Workflow passiert das über ein festes Protokoll, bei dem Trend-Repo über die Beschreibungen der Beteiligten. Das Muster ist gleich: Wer prüft, sieht die Aufgabe, nicht die Selbstauskunft.

Über Intelligenz wird viel geschrieben, über Rechnungen selten. Meine echten Zahlen aus dem Live-Dashboard, Stand 04.09.2026: 1.200 Requests verbraucht, 41,2 Prozent des Wochenlimits, das 5-Stunden-Fenster zu 45 Prozent. Mein Altvertrag zählt Requests und nicht Tokens, und genau deshalb ist die klare Rollenverteilung hier keine Designfrage, sondern eine Budgetfrage. Skripte erledigen die Mechanik ohne jeden Aufruf, Requests kaufe ich nur für Urteile. Die dokumentierte Einzelmessung: Ein 54-Minuten-Video komplett holen und verarbeiten kostet so 0,5 Prozent des Fensters, weil der Skript-Anteil das Model gar nicht sieht.

Wer stattdessen oder zusätzlich nach Token abrechnet, braucht die Vergleichszahlen der Anbieter, und dafür gilt dieselbe Trennung wie bei den Rollen: Dashboard-Werte und offizielle Preislisten sind verschiedene Quellen. Die offiziellen Listen für die beteiligten Modelle liegen im Quellenblock, und meine Auswahlentscheidung für ein Primärmodell ist daraus plus dem eigenen Verbrauchsmuster abgeleitet, nicht aus einer allgemeinen Überlegenheitsbehauptung. Welches Modell in welchem Preis-Leistungs-Fenster passt, hängt vom eigenen Requestmuster ab, und genau dieses Muster sollte man kennen, bevor man vergleicht.

Der Stack läuft auf einem gebrauchten Google Pixel 6a für 45 Euro. Die Härtung vom 28. August hielt zuletzt am 04.09.2026: 88 Stunden am Stück ohne Unterbrechung, null Out-of-Memory-Kills seit der Härtung, 99 Prozent Lebendrate über sieben Tage, gemessen mit 170 von 171 Checks im Snapshot-Log. Diese Zahlen belegen, dass der Host die Arbeitslast trägt, nicht dass die Architektur überall funktioniert. Genau deshalb ist die Aussage des Abschnitts eng formuliert: Es geht um die Beobachtung, dass Orchestrierung mit getrennten Kontexten auf einem kleinen Gerät funktioniert, und nicht um eine allgemeine Überlegenheit gegenüber anderen Setups. Ein Vergleich mit einem Laptop- oder Desktop-Stack wäre ein anderer Test, den ich so nicht gefahren bin.

Vier Dinge muss ich klar sagen. Erstens: Das Repo ist zehn Tage alt und ich habe es nicht auditiert. Ich habe Sternzahl, Erstellungsdatum und Beschreibung über die GitHub API geprüft, mehr nicht. Wer es einsetzt, liest den Code selbst. Zweitens: Der Erfolg mit 36 von 36 Tests ist ein Beleg für meinen Stack in dieser Fassung, keine allgemeine Marktbehauptung über Multi-Agent-Architekturen. Drittens: Die 2.422 Sterne zeigen Interesse, keine Qualität, und die 1.912 Sterne von sepia dieselbe Einordnung. Viertens: Die Messwerte zur Stabilität stammen aus dem eigenen Snapshot-Log und sind auf dieses Gerät und diesen Zeitraum bezogen. Wer die Zahl anderer nachbauen will, findet die Methode im Stack-Beitrag, nicht in diesem.

Ich bin Marcel, Grafikdesigner und Betreiber der d4sn3st-Seiten. Ich baue seit 2026 mit KI-Agenten, orchestriere statt zu tippen und dokumentiere meine Messwerte offen im Blog. Diesem Beitrag liegen die Stability-Snapshots und Tagesnotizen vom 28.08. bis 04.09.2026 zugrunde, die GitHub-Prüfungen habe ich über die öffentliche API geführt. Zuletzt fachlich geprüft am 05.09.2026.