Ich schwanke zwischen Claude und Codex

Ich schwanke zwischen Claude und Codex, weil jede Plattform einen anderen Teil meiner Arbeit besser löst. Codex gibt mir mehr nutzbare Zeit, eine angenehmere Bedienung, klarere Antworten und bessere Frontend-Ergebnisse. Claude setzt meine Multi-Agent-Pläne deutlich schneller in fertige Änderungen um. Das zählt am meisten, wenn ein Feature mehrere Systeme umfasst.

Teil der Arbeit	Claude	Codex
Überblick über die Architektur	Meine erste Wahl	Stark, verliert aber früher den Fokus
Orchestrierung großer Features	Erreicht meist zuerst das Ziel	Wird oft zu einem deutlich längeren Lauf
Frontend-Implementierung	Zuverlässig, aber oft vertraut	Passt besser zum Produkt, mit saubereren Abständen und besseren Designentscheidungen
Schriftliche Kommunikation	Fable sieht das System klar	Sol erklärt es meist verständlicher
Enthaltenes Kontingent	Fable stoppt bei der Hälfte des wöchentlichen Kontingents	Resets lassen das Kontingent deutlich größer wirken
Unterbrechungen durch Sicherheitsfilter	Mehr Fehlalarme bei meiner Arbeit	Nicht perfekt, aber für meine Aufgaben besser abgestimmt
Ablauf zwischen Telefon und Desktop	Leistungsfähig, aber auf mehrere Modi verteilt	Im Alltag einheitlicher

Die Tabelle zeigt, warum ich mich nicht entscheiden kann. In mehr Einzelbereichen ziehe ich Codex vor, doch Claude gewinnt bei großen Features, die die größten Blöcke meiner Zeit beanspruchen. In meiner Nutzung ist keines der Modelle eindeutig intelligenter. Die Systeme um sie herum bestimmen, welche Plattform ich öffne.

Warum bezahle ich für beide? Ich brauche die Stärken beider Plattformen

Ich bezahle für beide, weil Claude zu meinem Workflow für große Features passt, während ich Codex bei vielen kleineren Aufgaben lieber nutze. Ohne eines von beiden würde mir jede Woche etwas fehlen. Das ist eine lästige Antwort, denn beide zählen zu meinen größten laufenden Softwareausgaben.

Ich nutze Coding-Assistenten seit den frühen Tagen von GitHub Copilot. Dazu gehörte auch die Zeit, in der Code mit ChatGPT zu schreiben noch bedeutete, Snippets aus einem Browser-Chat zu kopieren. Jahrelang bestand meine feste Kombination aus Claude Max 20x fürs Coding und einem günstigeren ChatGPT-Abo für Recherche. Vor technischen wie persönlichen Entscheidungen recherchiere ich meist gründlich, und dafür passte OpenAI für mich durchgehend besser.

GPT-5.6 hat dieses Gleichgewicht verändert. Sol ist bei meiner Arbeit ungefähr so leistungsfähig wie Fable 5, deshalb wechselte ich zu OpenAIs Pro-20x-Abo und behielt Claude Max 20x. [4] [9] Meine Nutzung ist so hoch, dass ich zeitweise sogar ein zweites Claude-Max-Abo brauchte. Wenn ein Kontingent schneller aufgebraucht ist oder eine Plattform mich früher stoppt, entscheidet das darüber, wie viel Arbeit ich an diesem Tag abschließen kann.

OpenAIs Kontingent fühlt sich in der Praxis oft großzügiger an. Zwischen dem 26. August und dem 1. September 2026 habe ich drei weitere globale Resets beobachtet, zusätzlich zu der Reset-Aktion, über die ich im August geschrieben habe. Für mich wirken die kleinen Feiern rund um diese Resets auch wie Marketing für ein Modell, das sein Kontingent schnell verbrauchen kann. Für meine Arbeit zählt vor allem die praktische Folge: Die Resets haben mir mehr nutzbares Kontingent verschafft, und deshalb fällt es mir schwer, Codex aufzugeben.

Was macht Codex besser? Frontend-Arbeit und tägliche Nutzung

Codex ist bei den Teilen meiner täglichen Arbeit besser, die ich sofort bemerke: Frontend-Design beim ersten Versuch, schriftliche Erklärungen, Fernsteuerung und der Umgang mit Nutzungslimits während einer Aufgabe. Von einem klar begrenzten Auftrag zum nächsten lässt es sich angenehmer nutzen, auch wenn Sol nicht immer besseren Backend-Code schreibt.

Beim Frontend ist der Qualitätsunterschied am deutlichsten. GPT-5.6 erstellt beim ersten Versuch meist Layouts mit besseren Abständen, saubererer Ausrichtung und einer klareren visuellen Hierarchie. OpenAI selbst schreibt, dass das Modell Frontend-Ästhetik und Designentscheidungen verbessert. [1] Das ist kein unabhängiger Vergleich mit Fable 5, deshalb beruht mein weitergehendes Urteil auf eigener Erfahrung: Codex entwirft eher ein Design, das zum bestehenden Produkt passt. Claude liefert dagegen häufiger eine vertraute Vorlage, solange ich die visuelle Richtung nicht detailliert beschreibe.

Sol lässt sich für mich außerdem leichter lesen. Das Modell erklärt Entscheidungen normalerweise in alltäglicher Sprache, selbst wenn die eigentliche Arbeit technisch ist. Fable verschafft mir einen besseren Überblick über die Architektur, seine Texte sind aber mitunter schwerer verständlich. Das ist wichtig, weil der leitende Agent die meiste Zeit über Abwägungen spricht und Fortschritt meldet, statt nur Code zu schreiben.

Auch unterwegs bleibt Codex leichter zu bedienen. OpenAI dokumentiert einen Fernzugriff, mit dem ich vom Telefon aus eine Codex-Unterhaltung fortsetzen kann, die auf einem verbundenen Mac oder Windows-PC läuft. Dort kann ich die aktive Arbeit steuern sowie Freigaben, Diffs und Terminalausgaben prüfen. [7] Codex bietet außerdem isolierte Cloud-Aufgaben, wobei ich meist die Verbindung zu meinem eigenen Rechner nutze. [21]

Claude deckt dieselben Möglichkeiten über mehrere Modi ab: Es kann lokale Sessions auf einem Telefon fortsetzen, über Dispatch Arbeit auf dem Desktop starten und Cloud-Sessions weiterlaufen lassen, nachdem der Computer ausgeschaltet wurde. [17] [18] [22] Beide Plattformen decken die wichtigsten Anwendungsfälle ab, doch Codex präsentiert sie für mich übersichtlicher. Claude verteilt ähnliche Arbeit auf Remote Control, Dispatch, lokale Sessions und Cloud-Sessions.

Die Nutzungslimits verstärken den Unterschied. Laut aktueller Dokumentation von OpenAI teilen sich lokale Nachrichten und Cloud-Aufgaben im Pro-20x-Abo ein Fünf-Stunden-Fenster. Zusätzlich können wöchentliche Limits gelten, das Abo ist also nicht nur wöchentlich begrenzt. Eine bereits laufende Aufgabe kann nach Erreichen eines Limits unter Beachtung der Fair-Use-Regeln weiterlaufen. [4] Laut Claude Code Docs kann Claude inzwischen warten und eine unterbrochene Aufgabe nach dem Reset eines Session-Limits fortsetzen. [20] In meiner Nutzung fühlt sich das Limit dennoch eher wie ein harter Abbruch zum denkbar ungünstigsten Zeitpunkt an. Die genauen Regeln für Resets sind mir weniger wichtig als die Frage, ob die heutige Änderung einen sicheren Zwischenstand erreicht.

Warum ist Claude zuerst fertig? Sein Manager hält sich an den Plan

Claude beendet meine großen Features zuerst, weil seine Orchestrierung dazu passt, wie ich Softwarearbeit aufteile. Ein leistungsfähiges Modell behält den Plan, trifft Entscheidungen und spricht mit mir, während getrennte Agenten recherchieren, implementieren, testen und prüfen. In meinen Projekten beschränkt sich der leitende Agent bei Claude zuverlässiger auf die Koordination.

Anthropic nennt das allgemeine Muster Orchestrator-Worker: Ein zentrales Modell teilt eine Aufgabe auf, delegiert die Teile und führt die Ergebnisse zusammen. OpenAI dokumentiert dasselbe Grundprinzip als Manager-Orchestrierung. [14] [15] Der Name ist weniger wichtig als die Trennung: Der Manager behält Ziel und Entscheidungen im Blick, während die Arbeitsagenten klar begrenzte Aufgaben erhalten und Belege zurückliefern.

Die Dynamic Workflows von Claude Code machen diese Aufteilung ungewöhnlich deutlich. Claude schreibt ein Orchestrierungsskript, startet parallele Agenten und überlässt der Laufzeit Verzweigungen und Zwischenergebnisse. Laut Anthropic kann ein Lauf mit der Zeit Dutzende oder Hunderte Agenten starten. Wenn der Rechner genügend CPU-Kapazität bietet, können bis zu 16 gleichzeitig arbeiten. [11] [12] Ich brauche keine Hunderte, aber mir ist wichtig, dass das Gespräch mit dem leitenden Agenten nicht jeden Dateizugriff, jede Befehlsausgabe und jeden Umweg bei der Fehlersuche aufnehmen muss.

In meinem Aufbau übernimmt Fable 5 die Leitung. Es klärt mit mir die Architektur und schreibt den Plan. Anschließend implementieren Opus-Agenten klar begrenzte Teile, während andere Agenten testen und die Änderungen prüfen. Fable entscheidet, welche Findings bearbeitet werden müssen, und fragt mich, wenn eine Änderung vom Plan abweichen würde. In meinem planbasierten Workflow mit Opus 5 beschreibe ich die Details der Umsetzung. Hier zählt vor allem, dass Fable für das gesamte Ergebnis verantwortlich bleibt.

Manager

• Fable 5 behält Ziel, Plan, Entscheidungen und Gespräch mit dem Nutzer im Blick

delegiert begrenzte Arbeit

Arbeitsagenten

• Rechercheagenten erfassen das Repository und offene Fragen
• Opus-Agenten implementieren klar begrenzte Teile
• Test- und Audit-Agenten liefern Belege und Findings zurück

liefert Belege zurück

Entscheidung

• Prüfung durch den Manager annehmen, ablehnen, neu ausrichten oder den Nutzer fragen
• fertiges Feature Plan erfüllt und Prüfungen bestanden

In Claude Code unterstützen Fable und Opus ein Kontextfenster mit einer Million Tokens. Wichtiger ist aber, dass Details aus den Arbeitsagenten außerhalb des Gesprächs mit dem Manager bleiben. [13] Auch ein großes Fenster wird voll, wenn jeder Dateizugriff, jedes Agentenprotokoll und jedes Testergebnis darin landet. Dynamic Workflows halten diese Details getrennt, sodass im Kontext des Managers mehr Platz für Entscheidungen bleibt.

OpenAI beschreibt für Codex dieselbe Trennung: Der Haupt-Thread soll Anforderungen und Entscheidungen behalten, während Arbeitsagenten Erkundung, Tests und Protokolle übernehmen. [5] Deshalb erwartete ich, meinen Workflow übertragen zu können. In meinen Läufen hält sich der Hauptagent von Codex jedoch weniger zuverlässig an die reine Managerrolle als der leitende Agent bei Claude.

Warum ist Sol trotz höherer Geschwindigkeit später fertig? Codex schafft mehr Arbeit

Sol kann Text schneller erzeugen und trotzdem später mit einem großen Feature fertig werden, weil die Ausgabegeschwindigkeit nur einen Teil eines Agentenlaufs misst. Die meiste Zeit geht für nächste Schritte, Tool-Aufrufe, erneut aufgerollte Fragen und die Koordination der Arbeitsagenten drauf. Eine schnellere Textausgabe hilft nicht, wenn der Agent zusätzliche Arbeit schafft oder bereits getroffene Entscheidungen wieder infrage stellt.

Artificial Analysis maß am 1. September 2026 bei den verglichenen Konfigurationen mit maximalem Effort 77,1 Output-Tokens pro Sekunde für GPT-5.6 Sol und 66,9 für Fable 5. [3] Der Vorsprung von rund 15 % entspricht dem Eindruck, wenn ich Sol beim Antworten zusehe. Über die gesamte Laufzeit zeigt sich dieser Vorteil in meinen Projekten jedoch nicht, weil Codex oft zusätzliche Arbeit erzeugt, obwohl die ursprüngliche Implementierung schon fast fertig ist.

Zusätzlicher Umfang frisst Sols Geschwindigkeitsvorteil

Ein großer Teil der zusätzlichen Zeit entsteht durch Overengineering. Ich muss Codex sehr deutlich anweisen, die vorhandene Architektur zu erhalten, nicht zum Auftrag gehörende Findings zu melden statt zu beheben und aufzuhören, sobald die Akzeptanzkriterien erfüllt sind. Andernfalls ergänzt Sol womöglich zusätzliche Absicherungen, neue Hilfsfunktionen oder ein Subsystem für ein Problem, das nur eine gezielte Änderung brauchte. Bei Audits habe ich dieselbe Neigung gemessen: Sol fand deutlich mehr mögliche Probleme als Fable, doch die meisten überstanden die Triage nicht.

Auch die Koordination kostet Zeit. In meinen Läufen mit Codex Ultra fiel es dem Hauptagenten schwer, sich auf die Managerrolle zu beschränken. Er delegierte zwar Arbeit, prüfte aber weiterhin selbst Dateien, nahm Änderungen vor oder kam auf bereits getroffene Entscheidungen zurück, während seine Agenten ihre eigenen Aufgaben erledigten. OpenAI beschreibt Ultra als maximale Denkleistung mit automatischer Delegation und schreibt, dass der Haupt-Thread die Ergebnisse der Arbeitsagenten sammelt. [5] [19] Die Dokumentation verspricht nicht, dass er selbst nichts implementiert. Meine Anweisungen zu dieser Grenze haben das Problem verringert, aber nicht beseitigt.

Mehr Kontext und weniger Effort beheben die Verzögerung nicht

Lange Läufe belasten das Kontextfenster stärker, doch ein größeres Fenster hat die Verzögerung nicht behoben. Mein Codex-Status zeigte anfangs 272K Tokens, daher setzte ich model_context_window in der Konfiguration auf eine Million. OpenAI dokumentiert diese Einstellung, und Sol selbst unterstützt bis zu 1,05 Millionen Tokens. [6] [2] Die Angabe 272K beschreibt die Anzeige meiner Konfiguration, keinen von OpenAI dokumentierten allgemeinen Standard. Das größere Fenster hilft, Codex füllt es während eines langen Multi-Agent-Laufs aber weiterhin schnell. Sobald die Komprimierung beginnt, bin ich weniger sicher, ob eine frühe Vorgabe sechs Stunden später noch dasselbe Gewicht hat.

Ein langes Kontextfenster ist außerdem nicht kostenlos. Bei API-Anfragen über 272K berechnet OpenAI für den gesamten Request den doppelten Preis für Input und das 1,5-Fache für Output. [2] OpenAI sagt nicht, dass ein ChatGPT-Pro-Kontingent genau dieselben Multiplikatoren verwendet. Deshalb übertrage ich diese Formel nicht auf die Anzeige meines Abos. Sie zeigt aber, warum ein größeres Fenster lange Aufgaben nicht automatisch effizienter macht.

Eine niedrigere Effort-Einstellung für Sol hat das Problem bei mir nicht gelöst. Codex wird etwas schneller, doch die Qualität von Planung und Prüfung sinkt deutlich stärker, als die Laufzeit abnimmt. Auch ein Goal behebt es nicht. OpenAI beschreibt Goals als eine Möglichkeit, über mehrere Turns hinweg auf eine überprüfbare Abschlussbedingung hinzuarbeiten. Genau das möchte ich. [8] In meinen langen Läufen hält das Goal Codex aktiv, ohne ihm zu helfen, früher fertig zu werden.

Was erschwert die Nutzung von Claude? Limits und Sicherheitsfilter

Claudes Vorteil bei der Orchestrierung geht mit strengeren Limits und mehr Fehlalarmen bei Sicherheitsprüfungen einher. Der Workflow für große Features passt besser zu mir, aber ich muss häufiger prüfen, welches Modell noch verfügbar ist, und nach einer Unterbrechung durch einen Sicherheitsfilter wieder in die Arbeit finden.

Das Fable-Limit ärgert mich am unmittelbarsten. Ich bezahle für Max 20x, doch Fable darf nur die Hälfte des enthaltenen wöchentlichen Kontingents nutzen. [10] Ich verstehe, dass ein Anbieter mit weniger Rechenkapazität sein teuerstes Modell vielleicht strenger begrenzen muss. Das erklärt die Grenze, macht die Unterbrechung aber nicht weniger störend. Ein großes Feature verliert nicht an Bedeutung, wenn dieses kleinere Kontingent aufgebraucht ist.

Unterbrechungen durch Sicherheitsfilter sind noch störender, weil sie die Konzentration brechen, ohne die Arbeit voranzubringen. Anthropic räumte ein, dass Fable 5 nach seinem Release und der vorübergehenden Rücknahme im Juni 2026 harmlose Anfragen beim normalen Coding und Debugging als problematisch markierte. [16] Inzwischen erlebe ich weniger Unterbrechungen als am Anfang. Bei harmloser Arbeit schlagen die Filter aber noch immer häufiger an, als ich erwarte.

Auch OpenAI weist darauf hin, dass die Schutzmechanismen von GPT-5.6 bei legitimen Anfragen eingreifen können. [1] Codex ist also nicht frei von Fehlalarmen. In meinen Projekten sind seine Klassifikatoren besser abgestimmt: Bei einer Anfrage, die auch missbraucht werden könnte, verstehe ich meist, weshalb sie pausiert wurde, und normale Entwicklungsarbeit löst seltener eine solche Pause aus. Dieser Vergleich beruht auf meinen Projekten, nicht auf veröffentlichten Fehlerraten der Filter.

Diese Beschwerden wiegen den Vorteil bei der Orchestrierung nicht auf. Sie erklären aber, warum ich weiter zu Codex hinüberschaue, obwohl Claude wieder eine große Implementierung schneller abgeschlossen hat.

Claude oder Codex: Meine Wahl hängt vom Umfang ab

Ich wähle Claude, wenn ein Feature Repository-Recherche, eine Architekturentscheidung, mehrere Agenten für die Implementierung und ein unabhängiges Audit braucht. Codex nutze ich für klar begrenzte Änderungen, Frontend-Arbeit und Sessions, in denen mir die bessere Oberfläche und das in der Praxis größere Kontingent wichtig sind. Bei umfangreicher Recherche beginne ich weiterhin in ChatGPT statt in einem der beiden Coding-Harnesses.

Diese Aufteilung beruht auf dem Workflow und nicht auf der Behauptung, Fable 5 sei intelligenter als Sol. Würde ich beiden Modellen dieselbe kleine und eindeutige Aufgabe geben, würde ich beiden starken Code zutrauen. Der Unterschied zeigt sich, wenn ein Feature in mehrere voneinander abhängige Aufgaben aufgeteilt werden muss und der leitende Agent im Gedächtnis behalten soll, warum die einzelnen Entscheidungen gefallen sind.

Codex würde zu meinem Standard, wenn sein Manager die Implementierung den Arbeitsagenten überließe, den Umfang zuverlässiger kontrollierte, langen Kontext effizienter nutzte und einen großen Lauf zu einem geprüften Abschluss brächte. Claude wäre leichter als einziges Abo zu wählen, wenn Fables enthaltenes Kontingent weniger streng wäre und normale Coding-Arbeit seltener auf Sicherheitsfilter träfe.

Vorerst bezahle ich weiterhin für beide. Große Features beginne ich in Claude, weil seine Orchestrierung zuverlässig den Abschluss erreicht, um den ich gebeten habe. Zu Codex möchte ich trotzdem immer wieder greifen, weil sich der Rest des Produkts leichter nutzen lässt. Keine Plattform vereint derzeit Claudes Orchestrierung mit dem Produkterlebnis von Codex in einem Workflow.