Zum Inhalt springen

← Blog

Claude CodeOpenAI CodexCursor & Grok6.8.2026

Claude Code vs. Codex vs. Cursor

Drei AI-Coding-Agenten, eine Spezifikation, dieselbe Website: Claude Code mit Opus 5, OpenAI Codex mit GPT-5.6 Sol und Cursor mit Grok 4.5 im direkten Vergleich.

Einführung

Seit meinem Vergleich OpenAI Codex vs. Claude Code im April 2026 hat sich der Markt für AI-Coding-Agenten erneut deutlich weitergedreht: Anthropic hat Ende Juli Opus 5 veröffentlicht, OpenAI Anfang Juli die GPT-5.6-Familie in Codex ausgerollt, und mit Grok 4.5 ist ein neuer, ernstzunehmender Konkurrent im Coding-Segment angetreten. Zeit also für einen aktualisierten Vergleich. Einige Aussagen aus meinen früheren Beiträgen muss ich dabei korrigieren oder zumindest ergänzen.

Die Kandidaten

Claude Code mit Opus 5

Claude Code habe ich im April-Beitrag ausführlich vorgestellt. Seitdem hat Anthropic mit dem Ende Juli 2026 veröffentlichten Opus 5 die Coding-Leistung nochmals gesteigert. Das Kontextfenster liegt bei 1.000.000 Tokens, und Claude Code kann mittlerweile von Haus aus mit einem Browser arbeiten, also implementierte Features selbstständig starten, bedienen und visuell überprüfen.

OpenAI Codex mit GPT-5.6

Auch Codex ist von den früheren Beiträgen bekannt. Neu ist die GPT-5.6-Modellfamilie, die OpenAI Anfang Juli 2026 in Codex ausgerollt hat. Sie umfasst die Varianten Sol, Terra und Luna sowie das Flaggschiff Sol Ultra. Für den Test verwendete ich GPT-5.6 Sol mit der Reasoning-Stufe “High”. Auch Codex kann automatisch mit einem eingebauten Browser arbeiten und die Ergebnisse visuell überprüfen.

Cursor mit Grok 4.5

Cursor habe ich in meinen Beiträgen bisher nicht vorgestellt, daher folgt hier eine etwas ausführlichere Einführung. Cursor ist eine auf Visual Studio Code basierende Entwicklungsumgebung des 2022 gegründeten Start-ups Anysphere und gehört zu den kommerziell erfolgreichsten AI-Development-Tools überhaupt. Ähnlich wie Amazon Kiro oder Google Antigravity ist Cursor keine klassische IDE mit AI-Plugin, sondern von Grund auf um AI-Agenten herum gebaut: Neben der bekannten Code-Vervollständigung gibt es ein “Agents Window”, in dem mehrere lokale und Cloud-Agenten parallel arbeiten können, einen nativen Plan-Modus und die Möglichkeit, Agenten aus dem Browser oder sogar per Smartphone zu starten. Die Preise beginnen bei ca. 20 USD pro Monat für den Pro-Plan.

Bemerkenswert ist die aktuelle Konsolidierung am Markt: Im Juni 2026 hat SpaceX (seit Februar 2026 mit xAI fusioniert) angekündigt, Anysphere für 60 Milliarden USD zu übernehmen. Das im Juli 2026 veröffentlichte Grok 4.5 ist bereits ein Ergebnis dieser Zusammenarbeit: Es wurde nach Angaben von xAI gemeinsam mit Cursor entwickelt und unter anderem auf realen Cursor-Sessions trainiert. Über die xAI-API bietet Grok 4.5 ein Kontextfenster von 500.000 Tokens. Die in diesem Test verwendete Variante Cursor Grok 4.5 ist laut Cursor jedoch eine separate Konfiguration mit einem Kontextfenster von 256.000 Tokens. Die von mir verwendete Einstellung “High Fast” kombiniert hohen Reasoning-Aufwand mit der schnelleren (und teureren) Serving-Variante. Vom Funktionsumfang her ist Cursor mit Codex und der Claude-Code-App vergleichbar, bietet also beispielsweise auch einen integrierten Browser für die Validierung von Web-Applikationen. xAI positioniert das Modell explizit gegen die Opus-Modelle von Anthropic: vergleichbare Coding-Qualität, aber deutlich schneller und günstiger. Ob das stimmt, sehen wir gleich.

Der Test

Die Aufgabe

Als Testaufgabe verwendete ich meine private Street-Photography-Website photo.guntherpopp.de. Das Original ist eine klassische React-SPA, die seit einiger Zeit produktiv läuft. Für den Test erstellte ich ein separates Dokumentations-Repository, das die Website vollständig, aber implementierungsunabhängig beschreibt. Es enthält keinerlei Code, sondern ausschließlich:

  • eine Architekturdokumentation
  • ein semantisches Datenmodell mit den zentralen Konzepten der Domäne
  • diverse Feature-Spezifikationen
  • die eigentlichen Inhalte, also die Fotos, Metadaten und Bildbeschreibungen

Inhaltlich handelt es sich um ein zweisprachiges, bildzentriertes Portfolio: eine Galerie mit Serienfilter, Detailseiten mit den Metadaten (Belichtungszeit, Blende etc.) und der Beschreibung des Fotos, Carousels, eine About-Seite sowie diverse aus rechtlichen Gründen notwendige Inhalte. Die Seite verwendet kein Tracking und benötigt auch keine Cookies. Einen guten Eindruck vom Stil und Detailgrad der Spezifikationen vermittelt die Feature-Spezifikation der Carousels.

Das Setup

Das Repository mit der Spezifikation wurde dreimal kopiert, sodass jeder Agent eine identische Arbeitskopie erhielt. AGENTS.md war in allen drei Workspaces bis auf die Workspace-Zuordnung identisch: Die Datei fordert unter anderem einen Implementierungsplan vor der Umsetzung und Browser-Tests für die Validierung des Layouts und der Navigation. Alle drei Agenten erhielten anschließend denselben, bewusst knappen Prompt:

Please read and understand the architecture and the features of the
planned photo site. Then make a proposal on how to implement it.

Keiner der Agenten hatte während der Umsetzung Zugriff auf das Original oder dessen Code. Die Original-Website diente mir ausschließlich als persönliche Benchmark für Look-and-Feel und Funktionalität. Ich erwartete nicht, eine Kopie zurückzubekommen. Eine technisch bessere, alternative Lösung wäre mir sogar sehr willkommen gewesen.

Screenshot: Galerie der Original-Website
Die Original-Website vor dem Neubau

Meine Rolle während des Tests beschränkte sich auf die Freigabe der Implementierungspläne und die Beantwortung von Rückfragen.

Beobachtungen während der Umsetzung

Alle drei Agenten analysierten zuerst die Dokumentation und legten einen Implementierungsplan zur Freigabe vor. Erst danach implementierten sie die Website. Das in AGENTS.md geforderte Vorgehen respektierten sie also durchgängig. Interessant sind die Unterschiede in der Geschwindigkeit und Gründlichkeit:

Claude Code erstellte den Plan in ca. 7 Minuten und stellte dabei Rückfragen mit jeweils einer begründeten Empfehlung, unter anderem zum Build-Stack, zum Publishing-Workflow (also dem Vorgehen zur Vorbereitung der Bilder) und zum Testvorgehen:

Screenshot: Rückfrage von Claude Code zum Build-Stack
Rückfrage von Claude Code zum Build-Stack

Die Umsetzung dauerte insgesamt ca. 80 Minuten. Opus war damit mit Abstand am langsamsten, aber erledigte die Aufgabe auch am gründlichsten: Es implementierte nicht nur die Website, sondern kümmerte sich auch um die Qualitätssicherung inklusive End-to-End-Tests mit Playwright, Accessibility-Scans und visuellen Reviews über den integrierten Browser. Dabei fand und korrigierte der Agent eigenständig Layout-Probleme und hielt beispielsweise fest: “The mobile detail page pushes the photo below four navigation buttons. Let me put the image first on narrow screens.” Auch die Datenschutzanforderungen wurden am Ende explizit gegen das Build-Ergebnis verifiziert, darunter der Verzicht auf externe Hosts und Cookies. Einziger Wermutstropfen: Der Implementierungsplan wurde von Claude Code außerhalb des Workspace abgelegt und war damit nicht versioniert. Warum ich das für einen Nachteil halte, habe ich im Beitrag Best Practices: Implementierungsplan beschrieben.

Codex investierte ca. 13 Minuten in Recherche und Plan und stellte ebenfalls Rückfragen, etwa zum bevorzugten Layout:

Screenshot: Rückfrage von Codex zum bevorzugten Layout
Rückfrage von Codex zum bevorzugten Layout

Für die Implementierung (ca. 35 Minuten) verwendete Codex selbstständig einen Website-Building-Skill, kümmerte sich auch um den Publishing-Workflow und implementierte diverse Tests. Diese waren allerdings deutlich weniger umfassend als bei Claude Code. Insgesamt erfolgte die Umsetzung weniger sorgfältig, mehr dazu weiter unten im Abschnitt “Die Ergebnisse”.

Cursor war eine eigene Liga, was die Geschwindigkeit angeht: Nach nur ca. 10 Minuten (und rund 5 % meines Monatsbudgets im Pro-Plan) war das Gesamtergebnis fertig, also Plan und Implementierung. Dabei wurden auch Sub-Agenten eingesetzt, die beispielsweise parallel die Dokumentation und die Assets analysierten.

Screenshot: Parallele Subagenten während der Analyse in Cursor
Cursor delegiert die Analyse von Dokumentation und Assets an parallel arbeitende Subagenten

Schön gelöst: Der erstellte Implementierungsplan ließ sich in Cursor per Klick als Markdown-Datei im Workspace speichern.

Screenshot: Implementierungsplan in Cursor mit "Save to Workspace"
Cursor speichert den Implementierungsplan auf Wunsch per Klick als Markdown-Datei im Workspace

Wie die Ergebnisse weiter unten zeigen, ging die hohe Geschwindigkeit bei Cursor allerdings auf Kosten der Qualitätssicherung.

Die Ergebnisse

Dreimal dieselbe Architektur

Alle drei Agenten wählten unabhängig voneinander Astro als Technologie-Stack. Das Original ist eine React-SPA und die Spezifikation ist bewusst technologieneutral formuliert. Trotzdem kamen alle drei zum selben Schluss und begründeten ihn nahezu identisch: Statisch generierte Seiten sind SEO-freundlicher und liefern die Inhalte direkt im initialen HTML aus, ohne dass ein Client-Framework laufen muss. Auch in anderen Details wie dem Routing, der Sitemap-Struktur und der zweisprachigen Umsetzung sind die drei Ergebnisse praktisch deckungsgleich. Die Differenzierung zwischen den Agenten findet 2026 offenbar nicht mehr bei der Frage statt, ob die Anforderungen verstanden und umgesetzt werden können, sondern bei Aspekten wie Layout und Testabdeckung.

Claude Code: auslieferbar

Das Ergebnis von Claude Code kommt meiner Benchmark am nächsten: ein dunkles, bildzentriertes Layout, das dem Original erstaunlich ähnlich sieht, obwohl der Agent das Original nicht kannte und ich ein solches Layout nicht ausdrücklich gefordert hatte. Die Bildbühne ist korrekt dimensioniert, die Navigation funktioniert auf allen Geräten und die Bedienung ist intuitiv.

Screenshot: Galerie der Claude-Code-Version
Galerie der Claude-Code-Version

Alle Kernanforderungen sind umgesetzt und funktionieren: Serienfilter, zweistufige Navigation, Tastatursteuerung, Swipe-Gesten, Personenhinweise und Sprachumschaltung. Dazu kommen Dinge, die über die reine Aufgabenstellung hinausgehen: ein Architecture Decision Record inklusive dokumentiertem Dependency-Vetting, eine komplette Kommandozeilen-Werkzeugkette für meinen Publishing-Workflow (Import, Metadaten-Extraktion, Validierung, Veröffentlichung) und insgesamt 155 automatisierte Tests.

Tatsächlich läuft auf https://photo.guntherpopp.de seit dem Test die von Claude Code erstellte Variante mit einigen kleinen, kosmetischen Korrekturen produktiv (z. B. habe ich die Navigation auf der Detailseite noch etwas optimiert). Diese Korrekturen wären für die Produktivsetzung allerdings nicht nötig gewesen: Auch die initiale Version war bereits vollständig funktionsfähig und gestalterisch überzeugend.

Codex: überzeugend, mit kleineren Schwächen

Wie die Claude-Code-Version ist auch die Codex-Version dunkel und bildzentriert. Sie hat mich sofort angesprochen und kommt meiner Benchmark ebenfalls recht nahe. Auch funktional und technisch ist sie insgesamt gut umgesetzt.

Screenshot: Galerie der Codex-Version
Galerie der Codex-Version

Bei meinem manuellen Test fielen mir allerdings zwei Schwächen auf. Die erste betrifft das Routing: Die Astro-Konfiguration erwartet URLs ohne abschließenden Schrägstrich (trailingSlash: "never"), während Startseiten-Weiterleitung, Sprachumschalter, Canonical-URLs und Sitemap auf /en/ beziehungsweise /de/ verweisen. In der ausgelieferten Variante führte diese Abweichung bei einigen zentralen Navigationswegen zu einer 404-Seite. Die End-to-End-Tests erkannten das nicht, weil der dafür entwickelte Preview-Server diese beiden URLs gesondert behandelte. Das ist kein grundsätzliches Architekturproblem, zeigt aber, wie wichtig es ist, dass die lokale Testumgebung das spätere Hosting-Verhalten möglichst genau abbildet.

Auch die Bildbühne der Detailseite war noch nicht auf allen Bildschirmgrößen sauber abgestimmt. Auf dem Desktop wurde das Foto durch einen zu niedrigen Container teilweise abgeschnitten:

Screenshot: Detailseite der Codex-Version mit abgeschnittenem Foto
Fehler in der Codex-Version: Ein zu niedriger Container schneidet das Foto auf dem Desktop ab

Auf dem Smartphone zeigte sich der umgekehrte Effekt: Das Foto erschien relativ klein innerhalb einer großen schwarzen Fläche. Beim ersten Laden konnte dadurch kurz der Eindruck entstehen, das Bild sei noch nicht verfügbar.

Die beiden genannten Punkte wurden nach einer kurzen Rückmeldung an Codex innerhalb von Minuten korrigiert. Trotzdem bleibt festzuhalten, dass die ursprünglich ausgelieferte Version im Gegensatz zu den beiden anderen Implementierungen nicht produktionsreif war.

Cursor: solide und SCHNELL

Die Cursor-Version ist die einzige mit einem hellen, magazinartigen Design und Serifen-Typografie. Dieses Layout unterscheidet sich am stärksten von der Benchmark, ist aber insgesamt stimmig und gut umgesetzt. Die Bildbühne ist korrekt dimensioniert, die Navigation funktioniert auf allen Geräten und die Bedienung ist intuitiv.

Screenshot: Galerie der Cursor-Version
Galerie der Cursor-Version

Trotz der enorm schnellen Umsetzung ist das Ergebnis funktional vollständig. Im Vergleich zu den beiden anderen zeigen sich aber deutliche Unterschiede im Bereich Qualitätssicherung. Grok hat nur minimale Tests erstellt und das Layout nicht automatisiert über den Browser verifiziert. Zumindest den letzten Punkt hat Cursor im automatisch erstellten Validierungsbericht dokumentiert, der explizit darauf hinweist, dass die Browser-Interaktionstests in der Umgebung nicht möglich waren und manuell nachgeholt werden sollten. Ich habe hier nicht weiter nachgeforscht. Grundsätzlich sollte auch Cursor in der Lage sein, die Browser-Tests selbstständig durchzuführen; die Browser-Tools waren in der Konfiguration aktiviert.

Auch der Publishing-Workflow wurde sehr minimalistisch realisiert: Die Original-JPEGs werden direkt ausgeliefert, es gibt keine Metadaten-Extraktion, keine Validierung und keine Generierung optimierter Bildgrößen. Für eine private Website ist das vertretbar, und die fehlenden Schritte können bei Bedarf manuell nachgeholt werden. Tatsächlich bin ich ja eher ein Fan von schlanken Lösungen, die man bei Bedarf erweitern kann. Trotzdem habe ich mich am Ende für die deutlich schwergewichtigere Variante von Claude Code entschieden, weil sie den Publishing-Workflow vollständig automatisiert und mir damit Arbeit abnimmt.

Korrekturen zu früheren Beiträgen

Der Test korrigiert bzw. ergänzt einige Aussagen aus meinen früheren Beiträgen:

  • Im April-Vergleich habe ich geschrieben, dass sich Codex insgesamt “runder und ausgereifter” anfühlt als Claude Code. Mittlerweile hat sich das Gesamtbild verschoben: In diesem Test lieferte ausgerechnet Codex als einziger Agent ein nicht auslieferbares Ergebnis, während Claude Code die Aufgabe inklusive Qualitätssicherung vollständig löste. Auch im Bereich Tools hat Anthropic nachgelegt: Die Claude-Code-Desktop-App ist mittlerweile auf demselben Niveau wie die Codex-App.
  • Meine damalige Einschätzung, dass die Opus-Modelle beim reinen Coding “knapp vorn” liegen, hat der Test dagegen bestätigt. Auch die Einschätzung aus dem Copilot-Vergleich, dass die Anthropic-Modelle bei Frontend- und Layout-Aufgaben besonders stark sind, hat sich bestätigt.
  • Im Antigravity-Beitrag habe ich die native Browser-Integration als Alleinstellungsmerkmal beschrieben und beklagt, dass ich mir in anderen Tools bei Layout-Fehlern mit manuell erstellten Screenshots behelfen musste. Das ist mit Stand August 2026 überholt: Alle drei hier getesteten Tools bieten mittlerweile eine native Browser-Integration.

Fazit

Ein einzelner Test mit einer einzelnen Aufgabe ist keine Benchmark, und aus einer Greenfield-Aufgabe mit ungewöhnlich guter Dokumentation lässt sich nicht auf den Projektalltag schließen. Mit dieser Einschränkung im Hinterkopf ergeben die drei Durchläufe mit den Agenten folgendes Bild:

Claude Code mit Opus 5 arbeitet gründlich, selbstkritisch und mit eigener Qualitätssicherung, aber entsprechend langsam und teuer. Wo es auf Korrektheit und Nachvollziehbarkeit ankommt und weniger aufs Budget, ist das aktuell die erste Wahl.

Codex mit GPT-5.6 arbeitet deutlich schneller als Opus 5 und liefert Ergebnisse auf einem vergleichbaren Niveau. Die Prüfung der eigenen Arbeit erfolgte in diesem Test allerdings nicht so gründlich wie bei Claude Code. Die reale Konsequenz ist, dass die Codex-Version nicht vollständig funktionsfähig war und ohne (überschaubare) Korrekturen nicht ausgeliefert werden konnte. Codex ist aus meiner Sicht trotzdem eine gute Wahl, wenn neben der Qualität auch Geschwindigkeit und Kosten eine Rolle spielen.

Cursor mit Grok 4.5 hat mich am meisten überrascht. Ein funktionierendes, schlankes, spezifikationskonformes Ergebnis in zehn Minuten zu einem Bruchteil der Kosten: Das verschiebt die Maßstäbe dafür, was man von der Kombination aus schnellem Modell und gutem Tooling erwarten kann. Die Grenzen (weniger Tests, keine Browser-Verifikation, minimaler Publishing-Workflow) sind deutlich erkennbar, aber akzeptabel. Die xAI-Positionierung “vergleichbar mit Opus, aber viel schneller” ist aus meiner Sicht noch etwas zu optimistisch, aber die Richtung stimmt. Cursor ist aktuell die erste Wahl, wenn Geschwindigkeit und Kosten im Vordergrund stehen.

Meine Empfehlung aus den früheren Beiträgen gilt damit mehr denn je: Man sollte sich nicht auf ein einziges Tool festlegen, sondern die Stärken gezielt kombinieren und den Markt weiterhin aktiv beobachten. Die Karten werden gerade alle paar Monate neu gemischt.