Claude Code und Codex, nebeneinander

Die meisten Diskussionen über KI-Coding-Agenten setzen voraus, dass man sich für einen entscheidet. In der Praxis tut man das nicht, wenn man den ganzen Tag mit Agenten arbeitet — man greift zu dem, der zur Aufgabe vor einem passt, und zunehmend lässt man sie gleichzeitig am selben Projekt laufen. So sieht das wirklich aus.

Du wettest nicht auf einen Anbieter, du wählst ein Werkzeug

„Claude Code gegen Codex“ als Treuefrage zu behandeln, ist ein Kategorienfehler. Es sind Werkzeuge mit unterschiedlichem Griff, und die interessante Frage ist nicht, welches gewinnt. Sie lautet: Zu welchem greifst du wann? Nach genug Sitzungen bekommst du dafür ein Gefühl — so wie für die Frage, wann sich ein Skript lohnt und wann man es von Hand macht.

Grob läuft es so: Der eine Agent bekommt den Zuschlag für Aufgaben, die du klar beschreiben kannst und ausgeführt haben willst, der andere für Arbeit, bei der er länger mit der Unklarheit sitzen soll, bevor er irgendetwas anfasst. Welcher welcher ist, hängt vom Tag ab, von den Modellversionen und von deinem eigenen Geschmack. Es verschiebt sich, während sich beide Werkzeuge ändern.

Es geht nicht um eine feste Rangfolge. Es geht darum, dass du mit beiden zur Hand nie das falsche Werkzeug auf eine Aufgabe zwingst, nur weil es das einzige ist, das gerade offen ist.

Beide auf einer Codebasis fahren

Der wirklich nützliche Schritt ist Parallelität über Anbieter hinweg. Setz einen Agenten auf die API-Schicht und einen anderen auf die Tests. Lass einen eine Migration entwerfen, während der andere die davon abhängigen UI-Änderungen durcharbeitet. Fahr zwei vom einen Anbieter und einen vom anderen und hör auf, sie als „meine Claude-Sessions“ und „meine Codex-Sessions“ zu denken. Es sind einfach deine Agenten bei der Arbeit.

Genau hier beißt die Anbieterbindung wirklich — und zwar anders, als man üblicherweise meint. Das Problem ist nicht, später nicht wechseln zu können. Es ist, dass ein Ein-Anbieter-Werkzeug dir immer nur die Hälfte deiner Flotte zeigen kann. Wenn deine Statusübersicht nur Claude versteht, sind die beiden laufenden Codex-Sessions für sie unsichtbar — und du klickst dich wieder durch, um nach ihnen zu sehen. Eine einheitliche Ansicht funktioniert nur, wenn sie von Grund auf anbieterunabhängig ist, mit einem Detektor je CLI, die alle in ein Raster melden.

So ist vord gebaut. Es fährt fünf Agenten-CLIs im selben Cockpit: Claude Code, Codex, Kimi, OpenCode und Grok. Du installierst und startest sie selbst, vord betreibt die Sessions und liest ihren Status. Dieser Artikel bleibt bei den beiden, nach denen am häufigsten gefragt wird — aber nichts hier ist auf sie beschränkt.

Das Koordinationsproblem, vor dem dich niemand warnt

Zwei Agenten im selben Repo können sich in die Quere kommen. Beide beschließen, dieselbe Datei anzufassen. Beide nehmen an, sie seien die Einzigen. Am Ende schlichtest du einen Merge zwischen zwei deiner eigenen Agenten — eine wirklich merkwürdige Art, einen Nachmittag zu verbringen.

Ein Zaubermittel gibt es nicht, aber eine echte Linderung: Sag jedem Agenten in seinem Prompt, dass er nicht allein ist. Ein Satz wie „zwei weitere Agenten arbeiten gerade in diesem Projekt“ ändert, wie ein Agent über den Umfang nachdenkt. Er wird vorsichtiger bei großräumigen Änderungen und bleibt eher in seiner Spur. Konflikte verschwinden dadurch nicht, aber die selbstgewissen, ahnungslosen werden weniger — die, bei denen ein Agent einem anderen eine Datei unter den Händen umschreibt, weil er von ihm nichts wusste.

Die andere Hälfte liegt bei dir: Gib ihnen getrennte Arbeit. Parallelität ist sicher, wenn die Agenten getrennte Dateien oder getrennte Belange besitzen. In dem Moment, in dem zwei Agenten denselben Bereich bearbeiten, hast du aus paralleler Arbeit wieder sequentielle gemacht — mit zusätzlichem Konflikt obendrauf. Schneide die Aufgabe so, dass die Nähte zwischen den Agenten auf echte Grenzen fallen.

Der Arbeitsablauf, konkret

So sieht das in einem Werkzeug aus, das es unterstützt:

• Ein Raster, beide Anbieter. Claude-Code- und Codex-Sessions in derselben Ansicht, mit denselben Statuszuständen, Wartende zuerst. Du wechselst nicht zwischen zwei Apps, um zwei Hälften deiner Arbeit zu sehen.

• MCP für beide verwaltet. Die MCP-Server, die deine Agenten nutzen, werden an einer Stelle verwaltet, für Claude wie für Codex, über deren offizielle CLIs — damit die Fähigkeiten einheitlich sind statt zweimal konfiguriert.

• Ein Status, der den Unterschied kennt. Jede CLI hat darunter ihren eigenen Detektor, hook-basiert, wo die CLI Hooks unterstützt, und bildschirmlesend, wo nicht. Alle lösen zu denselben Zuständen auf, damit sich das Raster einheitlich liest, egal wer gerade läuft.

• Prüfen an einer Stelle. Wenn einer der beiden fertig ist, zeigt dir derselbe Git-Inspektor den Diff. Du prüfst Claudes Arbeit und Codex' Arbeit auf dieselbe Weise.

Die ehrliche Grenze

Beide zu fahren verdoppelt nicht deinen Ausstoss, und umsonst ist es auch nicht. Es verdoppelt die Entscheidungen und die zu lesenden Diffs, und es bringt die Chance mit, dass zwei Agenten kollidieren. Es zahlt sich aus, wenn die Arbeit sich wirklich in unabhängige Teile schneiden lässt und du eine Ansicht hast, die beide Anbieter als eine Flotte zeigt.

Wenn du Parallelität auf Arbeit zwingst, die eigentlich sequentiell ist, spürst du das als Reibung, nicht als Tempo.

Aber wenn sich die Arbeit teilen lässt — und vieles lässt sich teilen — dann ist Claude Code und Codex nebeneinander in einem Raster, beobachtet von einer Status-Engine, ein spürbar besserer Tag als das Hin- und Herspringen zwischen zwei Werkzeugen, die jeweils nur ihre eigene Hälfte sehen.