Die Codex-Agentenschleife aufdröseln

• Codex CLI ist als Agent konzipiert, der in lokalen Umgebungen sicher und effizient hochwertige Softwareänderungen ausführt
• Die zentrale Struktur, die Agentenschleife (agent loop), verknüpft Benutzereingaben, Modellinferenz und Tool-Aufrufe zyklisch, um sinnvolle Aufgaben auszuführen
• Während der Schleife entstehende Prompt-Zusammenstellung, Verwaltung des Kontextfensters und Prompt-Caching sind zentrale Faktoren für Leistung und Stabilität
• Codex kommuniziert über die Responses API mit dem Modell; jede Anfrage besteht aus einer vollständigen JSON-Payload und bleibt dadurch zustandslos (stateless)
• Diese Struktur ermöglicht fortgeschrittene Funktionen wie Zero Data Retention (ZDR), Prompt-Caching und automatische Verdichtung (compaction) und bildet die Grundlage für das Design großer Agentensysteme

---

Überblick über die Codex-Agentenschleife

• Codex CLI arbeitet im Kern mit einer Schleifenstruktur, die die Interaktion zwischen Benutzer, Modell und Tools koordiniert
  • Es übernimmt die Benutzereingabe und erstellt den Prompt, der an das Modell gesendet wird
  • Wenn das Modell eine Antwort erzeugt oder einen Tool-Aufruf (tool call) anfordert, führt der Agent diesen aus und fügt das Ergebnis wieder dem Prompt hinzu
  • Sobald das Modell keine weiteren Tool-Aufrufe mehr macht und eine assistant-Nachricht erzeugt, endet ein Turn
• Jeder Turn ist Teil einer Konversation; frühere Nachrichten und Tool-Aufrufe werden vollständig in den Prompt der nächsten Anfrage aufgenommen
• Da die Prompt-Länge durch das Kontextfenster (context window) des Modells begrenzt ist, muss Codex dieses aktiv verwalten

Responses API und die Kommunikationsstruktur von Codex

• Codex CLI sendet für die Modellinferenz HTTP-Anfragen an die Responses API
  • Der API-Endpunkt variiert je nach Konfiguration und kann in OpenAI-, ChatGPT-, Azure- oder lokalen Umgebungen wie LM Studio und Ollama genutzt werden
• API-Anfragen bestehen aus einer JSON-Payload mit folgenden Hauptfeldern
  • System-/Developer-Nachrichten: legen den grundlegenden Kontext des Modells fest
  • instructions: Liste der Tools, die das Modell aufrufen kann
  • tools: Tool-Definitionen, die von Codex CLI, der Responses API oder dem Benutzer bereitgestellt werden, etwa über einen MCP-Server
  • input: Nachrichtenliste mit Konversationsverlauf und Umgebungsinformationen
• Codex liest Konfigurationen aus ~/.codex/config.toml sowie AGENTS.md und skills-Dateien im Projekt und fügt Benutzeranweisungen und Umgebungsinformationen automatisch ein

Prompt-Zusammenstellung und Ereignisverarbeitung

• Codex sendet jede Nachricht als JSON-Objekt (type, role, content) an die Responses API
• Der Server erzeugt daraus den Modell-Prompt und gibt die Antwort als SSE-Stream (Server-Sent Events) zurück
  • Das Ereignis response.output_text.delta wird für Streaming-Ausgaben verwendet
  • Das Ereignis response.output_item.added wird dem input der nächsten Anfrage hinzugefügt und setzt so die Schleife fort
• Das System ist so ausgelegt, dass ein früherer Prompt ein exakter Präfix des neuen Prompts bleibt, sodass Prompt-Caching genutzt werden kann

Leistungsoptimierung: Caching und zustandsloses Design

• Codex verwendet previous_response_id nicht und behält dadurch eine vollständig zustandslose (stateless) Anfragestruktur bei
  • Das ermöglicht Unterstützung für Zero Data Retention (ZDR)-Kunden und minimiert die Datenspeicherung
• Prompt-Caching nutzt identische Präfixe erneut und linearisiert die Sampling-Kosten
  • Ein Cache-Treffer tritt nur bei exakter Präfix-Übereinstimmung auf
  • Änderungen an Tool-Listen, Modell, Sandbox-Einstellungen oder Arbeitsverzeichnis führen zu Cache-Misses
• Dynamische Änderungen an MCP-Tools können Cache-Verluste verursachen; daher spiegelt Codex solche Änderungen durch das Einfügen neuer Nachrichten wider

Verwaltung des Kontextfensters und automatische Verdichtung (compaction)

• Wenn eine Konversation länger wird, führt Codex zur Vermeidung einer Überschreitung des Kontextfensters eine Konversationsverdichtung (compaction) durch
  • Anfangs geschah dies manuell über den Befehl /compact, inzwischen nutzt Codex automatisch den /responses/compact-Endpunkt der Responses API
  • Dieser Endpunkt gibt ein Element vom Typ type=compaction sowie verschlüsselten encrypted_content zurück, um das Modellverständnis zu erhalten
• Überschreitet Codex den auto_compact_limit, wird automatisch eine Verdichtung ausgeführt, um die Kontinuität der Konversation zu sichern

Fazit und Ausblick

• Die Agentenschleife von Codex ist eine Kernstruktur, die Modellinferenz, Tool-Aufrufe, Caching und Kontextverwaltung integriert
• Diese Struktur ermöglicht ein leistungsstarkes, zustandsloses und sicherheitsorientiertes Agentendesign
• In späteren Beiträgen sollen weitere interne Strukturen von Codex behandelt werden, darunter CLI-Architektur, Implementierung der Tool-Nutzung und Sandbox-Modelle

[GN⁺]

Hacker-News-Kommentare

• Das Beste an diesem Blogpost ist, dass daran überhaupt nichts überraschend ist. Die Codex CLI ist Open Source, sodass man ohne Reverse Engineering ins Innere schauen kann
  Auch die Kommunikation von Eric Traut, einem für Pyright bekannten Entwickler, ist hervorragend. Er beteiligt sich aktiv an Issues und PRs
  GitHub-Repository

  • Als die Codex CLI letztes Jahr als Open Source veröffentlicht wurde, war ich wirklich überrascht. Enthalten ist auch codex-rs, ein Port von TypeScript nach Rust, was für alle sehr nützlich ist, die verstehen wollen, wie Coding-Agenten funktionieren
    Ich selbst habe auch einige Verbesserungen zur CLI beigetragen und erweitere mein Wissen, indem ich Releases und PRs kontinuierlich verfolge
  • Vielen scheint nicht klar zu sein, dass Claude Code proprietäre Software ist
  • Ehrlich gesagt denke ich, dass Claude Code nicht Open Source ist, weil die Codequalität so miserabel ist, dass es peinlich wäre. Ich nutze ein 200-Dollar-Abo pro Monat, aber die CLI ist langsam und bricht oft kaputt, sodass ich bald kündigen werde
  • Ich frage mich, ob die Codex CLI einfach ein Frontend ist, das entfernte Logik aufruft, oder ob sie auch offline vollständig funktionieren kann. Ich würde auch gern wissen, ob Gewichte unter der FLOW-Lizenz bereitgestellt werden und ob der Build-Prozess dokumentiert ist

• Interessant ist, dass die Komprimierung als „verschlüsselte Nachricht zur Bewahrung des latenten Verständnisses des Modells“ erfolgt
  Codex verwendet diesen Endpoint automatisch, um den Gesprächskontext effizient zu verkleinern, sobald auto_compact_limit überschritten wird

  • Der Compaction-Endpoint von Codex ist branchenweit Spitzenklasse. Der von Claude kommt dem Schlechtesten sehr nahe
  • Ich frage mich, ob man den Compactor-Endpoint unabhängig nutzen kann. Wir haben unsere eigene domänenspezifische Agenten-Loop, und ich vermute, dass die Lösung von Codex besser performt als unser eigenes Komprimierungssystem
  • Ich würde gern wissen, ob diese Funktion auch mit anderen Modellen als OpenAI-Modellen funktioniert

• Was mich beim Blick ins Innere von Codex überrascht hat, ist, dass Reasoning-Tokens in der Agenten-Tool-Call-Loop erhalten bleiben, aber bei jedem Wechsel des User-Turns gelöscht werden
  Dadurch kann der Kontext zwar über mehrere Turns hinweg erhalten bleiben, aber zwischen zusammenhängenden User-Anfragen kann ein Teil des Kontexts verloren gehen
  Ich lasse das Modell deshalb Fortschritt, Pläne und Debug-Infos in einer Markdown-Datei festhalten, damit diese über mehrere Kontextfenster hinweg wie eine Art Snapshot funktioniert

  • Das hängt vom API-Pfad ab. Bei Chat completions ist es so, wie du sagst, aber bei der Responses-v1-API ist es umgekehrt. Dort bleiben die Reasoning-Tokens auch beim Senden der nächsten Nachricht erhalten. Allerdings verbraucht der xhigh-Modus den Kontext deutlich schneller
  • Dass Reasoning-Tokens nicht erhalten bleiben, könnte sogar die bessere Entscheidung sein. Sonst sammelt sich fortlaufend Kontext an, den der User nicht sieht, und es besteht die Gefahr einer Diskrepanz zwischen Modell- und Nutzerverständnis
  • Ich habe einen Codex Reflect Skill gebaut, der frühere Gespräche berücksichtigt und den Kontext über parallele Sessions aufbaut
    GitHub-Repository
  • Protokolle zusammen mit dem Code zu speichern ist praktisch, verursacht aber Probleme in Teamumgebungen oder wenn mehrere Branches gleichzeitig bearbeitet werden. Als nächsten Versuch werde ich diese Daten in einen Daemon mit externem Storage auslagern und per CLI-Client darauf zugreifen
  • Ich nutze oft agent-shell in emacs; das speichert den kompletten Gesprächsverlauf. Dadurch kann ich leicht sagen: „Bezieh dich bitte auf das vorherige Gespräch.“ Da die Logs nicht vom Agenten, sondern von emacs geschrieben werden, muss ich mir keine Sorgen über Auslassungen machen

• Was ich mir in Codex wirklich wünsche, ist eine Checkpoint-Funktion im Copilot-Stil. Es gibt dazu einige Issues auf GitHub (#2788, #3585), aber es scheint keine Priorität für das Team zu sein

  • In Gemini CLI gibt es diese Funktion bereits
  • Das Codex-Team sagt, dass Prioritäten auf GitHub nach der Anzahl der Emoji-Upvotes gesetzt werden. Wenn es also eine Funktion gibt, die du willst, solltest du sie unbedingt upvoten

• Ich frage mich, wie beim Aggregieren von Benutzeranweisungen in einer Agenten-Loop die Kontextbewahrung in Multi-Turn-Gesprächen gehandhabt wird. Mich würde auch interessieren, ob schon Techniken ausprobiert wurden, die sich dynamisch anpassen, wenn sich User-Anforderungen ändern

• Ich mag Codex, aber im Vergleich zur ChatGPT-Weboberfläche fühlt es sich langsamer an. Wenn man Ideen schnell hin- und herschieben will, ist Copy-and-Paste im Web für mich immer noch produktiver
  Codex fängt oft an, den falschen Code zu ändern, wodurch die Feedback-Loop langsam und frustrierend wird. Wenn es aber gut funktioniert, ist es großartig. Hoffentlich erreicht es irgendwann ein Niveau, das so schnell wie das Web ist und zugleich lokales Arbeiten ermöglicht

  • In der ChatGPT-Plus-Weboberfläche wird der Modus xhigh reasoning effort des 5.2-Modells nicht angeboten

• Nichts wirklich Neues, aber trotzdem ein lesenswerter Beitrag. Es wäre gut, wenn man in agentischen Coding-CLIs Loops oder die Historie leichter reflektieren könnte. Ich habe versucht, den Chatverlauf über MCP abzufragen, aber das ist unpraktisch, weil man es explizit angeben muss. Kontinuierliches Lernen könnte solche Probleme lösen

• Dieses Verhalten lässt sich auch über OTEL-Telemetrie beobachten. Ich verwende oft headless codex exec, aber wegen der schwachen eingebauten Telemetrie-Unterstützung ist Debugging schwierig
  Deshalb habe ich mir selbst codex-plus gebaut. Es bildet das codex exec-Interface direkt nach, ist auf dem TypeScript-SDK aufgebaut und exportiert nach der Ausführung Session-Logs an einen entfernten OpenTelemetry-Collector, damit sie mit codex-plus-log-viewer analysiert werden können

• Der Abschnitt zur Beschreibung von Skills wirkte seltsam
  Link zum entsprechenden Code
  Ich frage mich, warum man nicht einfach Dateien direkt offenlegt, sondern das Modell sie wie normale Dateien anfordern lässt

  • Genau das ist der Kern von Skills. Die Struktur sorgt dafür, dass nur relevante Dateien geöffnet werden, wodurch weniger Kontextfenster verbraucht werden

• Ich hatte mich gefragt, ob irgendjemand die Codex CLI wirklich ernsthaft benutzt. Ich habe die VSCode-Codex-Erweiterung, Gemini CLI und Claude Code CLI ausprobiert, und alle waren leistungstechnisch katastrophal.
  Aber die neu in Rust geschriebene Codex CLI ist absurd schnell. Auch die UX ist perfekt, und sogar kleine Dinge wie Tastenkürzel sind gut umgesetzt. Theo meinte, man hätte sich eher auf Modellverbesserungen als auf CLI-Optimierung konzentrieren sollen, aber nach der Nutzung kann ich dem überhaupt nicht zustimmen

  • Für mich ist die Codex CLI deutlich besser als Claude Code. Sie folgt Anweisungen präzise und macht nichts, was man nicht will. Mit dem 20-Dollar-Monatsabo kann man das 5.2 codex high-Modell großzügig nutzen. Ich arbeite mit SSL-Bioakustikmodellen
  • OpenCode ist ebenfalls schneller und stabiler als andere CLIs. In letzter Zeit nutze ich Codex häufiger und werde mein Claude-Pro-Abo wahrscheinlich kündigen. Dass OpenAI OpenCode offiziell unterstützt, ist attraktiv. Es ist gut, dass es jetzt mehrere konkurrierende Optionen gibt
  • Codex liefert bei den meisten Coding-Aufgaben in über 95 % der Fälle konsistente Ergebnisse. Bei unstrukturierten Aufgaben wie Gesprächen oder Story-Schreiben produziert es aber manchmal seltsame Ausgaben. Ich bin auch schon einmal während eines git rebase in einer Loop hängen geblieben. Aider habe ich ausprobiert, fand es aber fast nutzlos
  • Die Speicher- und CPU-Effizienz der Codex CLI ist sehr gut. Außerdem ist sie Open Source, sodass man ihre Funktionsweise direkt nachvollziehen kann. Über Theos Aussage bin ich immer noch verärgert
  • Das Problem von Codex ist, dass es noch keine Hook-Unterstützung gibt. Ich habe mit Hooks ein Tool gebaut, das den Token-Verbrauch von Agenten um 30 % senkt. Über Hooks kann man ineffizientes Verhalten eines Agenten in Echtzeit korrigieren
    Zugehöriger Artikel: Scribe Swebench Benchmark