Ich wollte keinen Coding-Agenten, der möglichst viel Code schreibt. Ich wollte einen, der versteht, warum meine Chatbot-Runtime nicht zuverlässig funktioniert — und das Problem sauber löst.
Genau daran habe ich OpenAI Codex mit GPT-6 Astra und GPT-6.1 Sol gemessen. Mein Ergebnis war ernüchternd: viel Aufwand, ein schnell schrumpfendes Nutzungskontingent und eine Architektur, die durch zusätzliche Reparaturversuche immer komplizierter wurde. Der Wechsel zu Claude Code brachte dagegen bereits beim ersten Refactoring eine spürbare Verbesserung.
Dieser Erfahrungsbericht über Claude Code vs. Codex verbindet meine Arbeit an einem echten Softwareprodukt mit aktuellen Herstellerdaten zu Preisen und Coding-Leistung. Er zeigt auch, warum ich inzwischen stärker auf die Kosten einer funktionierenden Lösung schaue als auf das Prestige eines Modells.
Stand der recherchierten Produktdaten: 2. Oktober 2026. Meine Aussagen über Geschwindigkeit, Codequalität und Quota sind persönliche Beobachtungen. Die Durchläufe waren kein kontrollierter Vergleich mit identischem Ausgangsstand.
Die Aufgabe: einen zuverlässigen Agent Loop bauen
Ich baue ein Softwareprodukt mit einer eigenen Chatbot-Runtime. Im Zentrum steht ein Agent Loop: Der Agent nimmt eine Nutzernachricht entgegen, entscheidet über den nächsten Schritt, bedient gegebenenfalls Tools und verarbeitet deren Ergebnisse, bevor er sinnvoll antwortet.
Eine hübsche Demo reicht dafür nicht. Menschen formulieren unvollständig, ändern ihre Meinung oder schreiben etwas, das im ersten Moment keinen Sinn ergibt. Die Runtime muss trotzdem nachvollziehbar reagieren. Ein Tool-Ergebnis darf nicht einfach verloren gehen, und ein Agent darf eine fehlerhafte Annahme nicht mit weiteren Aktionen immer tiefer in den Ablauf tragen.
Ich suchte deshalb Hilfe beim Zusammenspiel dieser Teile. Einzelne Funktionen zu ergänzen war nicht das Ziel. Ich brauchte jemanden, der Schwächen in der Softwarearchitektur erkennt und daraus eine wartbare Lösung ableitet.
Wer selbst an solchen Produkten arbeitet, kennt die größeren Betriebsfragen aus meinem Beitrag über Qualität, Kosten und Betrieb eines Laravel AI Support Bots. Bei meinem Refactoring ging es zunächst um die Grundlage: einen verlässlichen Ablauf innerhalb der Runtime.
Meine Erfahrung mit GPT-6 Astra: teuer und zu viel zusätzliche Komplexität
Ich setzte Astra überwiegend mit hohem Reasoning-Aufwand ein, teilweise auch auf Medium. Die Erwartung war entsprechend groß: Ein leistungsfähiges Modell sollte bei einer anspruchsvollen Architekturaufgabe helfen können.
In meinen Sitzungen passierte jedoch häufig etwas anderes. Astra schlug weitere Änderungen vor, fügte Code hinzu und machte die Lösung umfangreicher. Das grundlegende Problem blieb bestehen. Die Erklärung konnte überzeugend klingen, ohne dass das Verhalten der Runtime anschließend zuverlässig war.
Teilweise hatte ich den Eindruck, dass das Modell Zusammenhänge halluzinierte: Es argumentierte mit Annahmen über den Code und den Ablauf, die für mich nicht ausreichend belegt waren. Ich habe daraus keine gemessene Halluzinationsrate abgeleitet. Aber diese unbegründete Sicherheit machte die Zusammenarbeit an einem ohnehin komplexen System anstrengend.
Besonders enttäuschend war, dass Astra die entscheidenden Schwächen meines Agent Loops in diesen Versuchen nicht so erkannte und löste, wie ich es gebraucht hätte. Ich wollte weniger Unsicherheit im System. Stattdessen musste ich immer mehr vorgeschlagenen Code verstehen und prüfen.
Mein Problem mit Astra war die Kombination: hoher Verbrauch, zusätzliche Komplexität und am Ende trotzdem keine saubere Lösung.
Bei intensiver Arbeit hatte ich das Gefühl, das verfügbare Kontingent meines 100- beziehungsweise 200-Dollar-Plans in weniger als einem Tag weitgehend aufzubrauchen. Damit meine ich die nutzbare Abo-Kapazität — keine nachgewiesene API-Rechnung über 100 oder 200 Dollar an diesem Tag.
Mein Umweg: GitHub-Analyse, Research und ein Implementierungsplan in Slices
Weil die direkte Umsetzung zu teuer und zu wenig zielführend wurde, änderte ich meinen Workflow. Ich verband ChatGPT mit meinem Remote-Repository auf GitHub und ließ einen ausführlichen Research- und Review-Bericht erstellen.
Die Frage war konkreter als „Wie baue ich einen Agenten?“: Wie lösen Projekte wie Codex oder OpenCode vergleichbare Probleme? Wie gehen sie mit Nutzereingaben, Tool-Aufrufen und schwierigen Gesprächsverläufen um? Welche Architekturideen könnten für mein System relevant sein?
Den Bericht gab ich anschließend an Codex weiter. Astra sollte ihn auf High noch einmal gegen den Code prüfen und beurteilen, ob der vorgeschlagene Ansatz sinnvoll war. Manchmal kamen dabei Verbesserungen heraus. Dieser zusätzliche Review war mir wichtig, weil ich nicht sicher war, wie vollständig die Analyse über die GitHub-Anbindung meinen tatsächlichen Projektstand erfasste.
Danach ließ ich einen Implementierungsplan mit überschaubaren Slices erstellen. Jeder Slice sollte eine sinnvolle Einheit bilden und sich bei Bedarf in einem eigenen Thread umsetzen lassen. Ich wollte vermeiden, dass eine einzige Unterhaltung mit Analyse, alten Versuchen und neuen Änderungen immer weiter anwuchs.
Die Idee dahinter halte ich weiterhin für richtig. Ein guter Slice braucht einen klaren Zweck, überschaubare Änderungen und ein überprüfbares Ergebnis. Beim Wechsel in einen neuen Thread müssen außerdem die relevanten Entscheidungen und der aktuelle Codezustand mitkommen. Ein leerer Verlauf allein macht eine Aufgabe noch nicht günstiger oder einfacher.
GPT-6.1 Sol war günstiger — löste mein Problem aber nicht sauber
Die Umsetzung überließ ich meistens Sol: zunächst GPT-6 Sol, später GPT-6.1 Sol. Astra für Analyse und Review, Sol für die Implementierung — das erschien mir als vernünftige Aufteilung.
Bei den Kosten kann ich Sol tatsächlich mehr abgewinnen. Die Arbeit war in meinen damaligen Sitzungen allerdings sehr langsam. Dazu kamen weitere Probleme bei der Umsetzung. Trotz Research-Bericht, Review und aufgeteiltem Plan entstand noch nicht die saubere Runtime, die ich wollte.
Das ist die Grenze eines auf dem Papier guten Workflows: Ein Modell kann einen Plan schrittweise abarbeiten und trotzdem zu wenig zur Lösung beitragen, wenn der Plan oder die Umsetzung die Ursache des Problems nicht trifft.
Ob sich die Geschwindigkeit von GPT-6.1 Sol inzwischen verbessert hat, lasse ich offen. Meine Beobachtung beschreibt die Sitzungen, die ich durchgeführt habe. Einen aktuellen, vergleichbaren Geschwindigkeitstest habe ich daraus nicht gemacht. Auch meine Zweifel an seiner Eignung für diese Architekturarbeit sind ein Urteil aus meinem Projekt, keine allgemeine Aussage über sämtliche Aufgaben des Modells.
Der Wechsel zu Claude Code: schneller zum brauchbaren Refactoring
Irgendwann hatte ich genug von den langen Schleifen und wechselte zu Claude Code. Ich startete mit dem Pro-Plan für rund 20 US-Dollar im Monat. Schon dort überraschte mich, wie schnell die Arbeit vorankam und wie viel ich mit dem verfügbaren Kontingent umsetzen konnte.
Mein Engpass war zunächst weniger das Wochenlimit als das Fünf-Stunden-Fenster. Wenn ich konzentriert an einer größeren Änderung arbeitete, störte mich diese Unterbrechung. Deshalb wechselte ich auf den 100-Dollar-Plan.
Für meinen Arbeitsstil fühlte sich das Kontingent danach sehr großzügig an — sowohl über die Woche als auch innerhalb einer Sitzung. Noch wichtiger war das Ergebnis: Claude Code konnte meine Chatbot-Runtime refactoren und Teile neu aufbauen, sodass sie bereits beim ersten Versuch besser funktionierte als nach meinen vorherigen Versuchen mit Astra und Sol.
Das bedeutet nicht, dass damit jede mögliche Fehlerkonstellation ausgeschlossen war. Aber die Verbesserung war für mich direkt spürbar. Ich hatte endlich eine brauchbare Grundlage, mit der ich weiterarbeiten konnte.
Für dieses Refactoring beobachtete ich ungefähr fünf bis sechs Prozent Verbrauch in der Quota-Anzeige. Diese Zahl ist meine grobe Beobachtung, keine Tokenabrechnung. Ich ordne sie hier keinem nachträglich angenommenen Wochen- oder Sitzungsbudget zu. Ein Prozentpunkt bei Claude lässt sich außerdem nicht direkt mit einem Prozentpunkt bei Codex vergleichen.
Der Unterschied war trotzdem groß genug, um meine nächste Entscheidung zu verändern: Weil ich mit deutlich weniger Reibung zu einem besseren Ergebnis kam, traute ich mich an größere Refactorings in meinem Produkt. Ein Werkzeug, das mich beim Aufräumen unterstützt, ermöglicht andere Entscheidungen als eines, bei dem ich jeden weiteren Versuch gegen die verbleibende Quota abwäge.
Was die aktuellen Preise über Astra, Sol und Opus 5.5 sagen
Abo-Preis, enthaltenes Nutzungskontingent und API-Tokenpreis sind drei unterschiedliche Größen. Für die Einordnung lohnt sich deshalb ein getrennter Blick.
Abonnements und Nutzungsfenster
Claude Pro kostet bei monatlicher Abrechnung derzeit 20 US-Dollar. Max beginnt bei 100 US-Dollar; Anthropic bietet Varianten mit dem Fünf- beziehungsweise Zwanzigfachen der Pro-Nutzung pro Sitzung. Max hat weiterhin ein Fünf-Stunden-Fenster und ein Wochenlimit. Die Website nennt Preise ohne gegebenenfalls anfallende Steuern. Quellen: Claude-Preise und Max-Nutzungsgrenzen.
OpenAI führt aktuell Plus für 20 US-Dollar sowie Pro-Pläne für 100, 200 oder 500 US-Dollar im Monat. Laut aktueller Dokumentation haben Pro-Pläne kein Fünf-Stunden-Limit; weitere Nutzungsgrenzen können gelten. Die Dokumentation betont, dass Modellwahl, Kontext, Reasoning und Tool-Nutzung den Verbrauch beeinflussen. Quelle: Codex- und ChatGPT-Work-Preise.
API-Preise im direkten Vergleich
Die folgende Tabelle zeigt Standard-API-Listenpreise in US-Dollar pro Million Tokens, ohne zusätzliche Tools, Cache-Schreibkosten oder besondere Verarbeitungsmodi. Bei OpenAI gilt hier der kurze Kontext bis 272.000 Eingabetokens.
| Modell | Input | Gecachter Input | Output |
|---|---|---|---|
| GPT-6 Astra | 10,00 $ | 1,00 $ | 50,00 $ |
| GPT-6.1 Sol | 2,00 $ | 0,10 $ | 10,00 $ |
| Claude Opus 5.5 | 4,00 $ | 0,20 $ | 20,00 $ |
Quellen: OpenAI API Pricing und Claude Opus 5.5: Modell- und Preisdaten. Opus 5.5 ist ein Anthropic-Modell; OpenAIs GPT-5.5 ist ein anderes Modell.
Die Zahlen machen zwei Dinge sichtbar: Astra kostet bei diesen Ein- und Ausgaberaten das Fünffache von Sol. Opus 5.5 liegt preislich dazwischen und ist pro ungecachtem Token teurer als Sol. Meine positive Kostenerfahrung mit Claude Code lässt sich deshalb nicht einfach mit dem niedrigsten Tokenpreis erklären. Entscheidend war für mich, wie schnell ich eine brauchbare Lösung bekam.
Auch die offiziellen Codex-Creditraten zeigen den Abstand: Astra wird im Standardmodus mit 250 Credits pro Million Eingabetokens und 1.250 Credits pro Million Ausgabetokens geführt; GPT-6.1 Sol mit 50 und 250 Credits. Daraus lässt sich kein identischer Faktor für den Verbrauch des enthaltenen Abo-Kontingents ableiten. Quelle: Codex-Creditraten.
Wie intelligent sind die Modelle? Was Coding-Benchmarks zeigen
Mein Eindruck aus dem Projekt war, dass Claude Code die Aufgabe deutlich zielgerichteter löste. Für eine allgemeine Aussage wie „das intelligenteste Modell der Welt“ reicht diese Erfahrung aber nicht aus.
Als zusätzlichen Datenpunkt veröffentlicht Anthropic in der Ankündigung von Opus 5.5 folgende Ergebnisse. Es handelt sich um eine vom Hersteller zusammengestellte Vergleichstabelle.
| Benchmark | Opus 5.5 | GPT-6 Astra |
|---|---|---|
| Terminal-Bench 4.0 | 66,4 % | 57,9 % |
| FrontierCode v1.1 (Main) | 54,4 % | 53,3 % |
| AutomationBench | 40,0 % | 41,4 % |
Auf den beiden Coding-Benchmarks liegt Opus vorne; bei AutomationBench liegt Astra vorne. Die Bedingungen sind nicht durchgehend identisch: Terminal-Bench nennt für Opus xhigh und für Astra high; weitere Ergebnisse verwenden andere Einstellungen. Eine aktuelle GPT-6.1-Sol-Spalte enthält diese Tabelle nicht. Sie erlaubt deshalb keine vollständige Rangliste meiner eingesetzten Modelle. Quelle und Testbedingungen: Anthropic: Introducing Claude Opus 5.5.
Anthropic berichtet dort außerdem von mehr als 30 Prozent schnellerer Ausgabe gegenüber Opus 5 und rund 40 Prozent niedrigeren Kosten bei typischen Workloads in eigenen Tests. Das sind Herstellerangaben gegenüber dem Vorgänger — keine von mir gemessenen Geschwindigkeits- oder Kostenvorteile gegenüber Astra oder Sol.
Sol bleibt damit ebenfalls differenziert zu betrachten. OpenAI positioniert GPT-6.1 Sol als Modell für komplexe Arbeit mit niedrigerem Preis und einer Leistung nahe Astra. Mein enttäuschendes Ergebnis bei einer bestimmten Runtime widerlegt nicht jede andere Einsatzmöglichkeit. Es zeigt mir, dass ich diese Positionierung für mein Projekt selbst überprüfen muss.
Was ich daraus für komplexe Refactorings mitnehme
Die wichtigste Erkenntnis betrifft meine Bewertung von Coding-Agenten. Ich will früher sehen, ob der Agent die Ursache verstanden hat. Ein langer Plan und viele geänderte Dateien sind dafür kein ausreichender Beleg.
Bei einem Agent Loop würde ich einen Implementierungsplan heute vor allem an diesen Fragen messen:
- Ist der Fehler konkret beschrieben? Eine problematische Nutzereingabe oder Tool-Antwort sollte sich als nachvollziehbarer Ablauf formulieren lassen.
- Sind Zuständigkeiten klar? Es muss verständlich sein, welcher Teil den Laufzustand verwaltet, Tools ausführt und Antworten an den Nutzer weitergibt.
- Werden schwierige Abläufe geprüft? Dazu gehören neue Eingaben während eines laufenden Schritts, fehlgeschlagene Tools und wiederholte Aktionen.
- Bleibt die Änderung überschaubar? Ein Slice sollte einen erkennbaren Teil des Problems lösen und sich gezielt verifizieren lassen.
- Sinkt die Komplexität dort, wo sie das Problem verursacht? Weitere Sonderfälle brauchen eine nachvollziehbare Begründung.
Auch beim Modellvergleich möchte ich genauer werden: dieselbe Ausgangsversion, derselbe Fehlerfall, klare Akzeptanzkriterien und ein Protokoll von Laufzeit und Verbrauch. So lässt sich besser auseinanderhalten, welcher Anteil vom Modell, vom Coding-Werkzeug oder vom bereits erarbeiteten Wissen kommt. Claude Code hatte bei meinem Wechsel schließlich eine andere Ausgangslage als die ersten Astra-Versuche.
Mein Fazit: Die funktionierende Lösung entscheidet
Von Astra bin ich nach diesen Erfahrungen enttäuscht. Ich habe viel Kontingent und Zeit investiert, ohne die Architekturprobleme meines Agent Loops sauber gelöst zu bekommen. Sol war günstiger, brachte mich in den damaligen Sitzungen aber ebenfalls zu langsam und mit zu vielen Problemen voran.
Claude Code hat meine Erwartung dagegen deutlich übertroffen. Die Kombination aus Geschwindigkeit, dem für mich großzügigen Kontingent im 100-Dollar-Plan und dem direkt besseren Verhalten meiner Runtime war überzeugend. Sie hat mich motiviert, größere Teile meines Produkts zu refactoren.
Für mein Projekt war der Wechsel die richtige Entscheidung. Meine bevorzugte Messgröße ist seitdem sehr praktisch: Wie viel Zeit, Verbrauch und zusätzliche Komplexität kostet es mich, bis eine Änderung tatsächlich funktioniert?
Wer verstehen möchte, wofür ich diese Runtime baue, findet auf meiner Seite zum AI Agent Workflow Builder mehr zum Produkt. Genau solche echten Projekte entscheiden für mich, ob ein Coding-Agent seinen Preis wert ist.