Claude Code vs. Cursor: Gleiches Modell, andere Erfahrung

Seit einigen Monaten arbeite ich produktiv mit beiden Tools — Claude Code und Cursor — in AI-driven Projekten. Am 9. Mai 2026 hatten wir bei form4 unseren ersten internen AI-Hackathon, und einiges aus dem laufenden Alltag ist dort in vier Stunden in komprimierter Form sichtbar geworden — ergänzt um neue Beobachtungen aus dem Team-Setup.

Dieser Post ist deshalb kein reiner Hackathon-Bericht, sondern ein Tool-Vergleich auf Basis dieser Erfahrungen. Der Hackathon dient als Case Study, die einiges davon bestätigt und einiges davon erweitert hat.

Kurz: Claude Code und Cursor verhalten sich grundverschieden, selbst wenn beide dasselbe Modell benutzen. Der Grund liegt nicht im Modell, sondern im Tool drumherum.

Setup: Vier Stunden, drei Ideen

Drei Teams à zwei bis drei Personen, freier Tech-Stack, kein Backend-Marathon, dafür AI-first. Raus kamen drei sehr unterschiedliche Projekte:

• MiniLearn — Micro-Learning in fünf Minuten, AI-generierte Inhalte
• Movie Quiz — Filmwissen-Quiz mit absichtlich knappen Hints
• Bug Hunt — Legacy Code from Hell spielerisch verpackt

Erkenntnisse aus den Teams

Im Anschluss haben wir gemeinsam zusammengetragen, was die Teams in den vier Stunden über die Tools hinaus mitgenommen haben. Drei Erkenntnisse sind besonders deutlich geworden.

80/20 ist auch hier das Muster. Mehrere Beobachtungen kreisten um dieselbe Erfahrung: schnell viel Output, dann wird es zäher, das Finetuning zieht sich. Die ersten 80 % einer Implementierung waren in Minuten da, die letzten 20 % haben den Großteil der Zeit gefressen. Das ist kein neues Muster — jeder Entwickler kennt es. Mit AI verschiebt sich nur die Tonlage: Die ersten 80 % fühlen sich an wie Magie, die letzten 20 % erinnern daran, dass sauberes Engineering nicht abgeschafft ist.

E2E-Tests sind ein guter Hebel — gerade weil AI an Schnittstellen Fehler macht. End-to-End-Tests ließen sich gut mit AI generieren. Wertvoll sind sie aber vor allem, weil typische Fehler im ersten Lauf an Schnittstellen entstehen — also genau dort, wo der Modell-Kontext nicht ausreicht. Das ist nicht AI-spezifisch: Schnittstellen sind auch bei menschlichen Entwicklern die Stelle, an der Verständnislücken sichtbar werden, und Fehler dort sind völlig normal. Ein E2E-Test, der parallel zur Implementierung entsteht, hilft der AI in der nächsten Iteration genauso wie er einem Menschen helfen würde — der danach generierte Code hat eine deutlich bessere Trefferquote.

Parallele Agents sind ein Teile-und-Herrsche-Problem. An dieser Stelle nicht zu verwechseln mit der Subagent-Reife einzelner Tools (dazu weiter unten mehr): Hier geht es um eine methodische Frage. Wie schneidet man Aufgaben so, dass mehrere Agents parallel laufen, ohne sich an denselben Stellen zu verhaken? In der Praxis landet man schnell bei Worktrees oder Feature-Branches — und damit bei Merge-Konflikten, die hinterher jemand wieder zusammenführen muss. Bemerkenswert war dabei, wie gut die Agents diese Konflikte selbst auflösen — was nicht nur Komfort ist, sondern oft die einzige praktikable Option: Code, den parallel laufende Agents in Bereichen erzeugen, die das Team nicht im Detail mitliest, lässt sich von Hand kaum noch sauber mergen, ohne sich erst wieder einzulesen. Tooling und Methodik sind hier insgesamt noch nicht ausgereift; das wird eines der spannenderen Themen der nächsten Monate.

Daneben gab es kleinere Erkenntnisse in dieselbe Richtung: Prompts nicht zu technisch formulieren — Intent statt Implementierungsdetail; Planung auf Epic-Ebene hat als Workflow-Pattern getragen; und ein selbstkritisches Eingeständnis, dass es Fälle gab, in denen Code lief, der Weg dorthin aber niemandem mehr ganz präsent war.

Damit zum Tool-Vergleich.

Was sofort auffiel

In meinen Projekten — und parallel auch im Hackathon — habe ich mit Claude Code und Cursor gearbeitet, in beiden Tools mit demselben Frontier-Modell, Claude Opus 4.7. Logisch wäre also: ähnliches Modell, ähnliches Ergebnis.

Tatsächlich fühlt es sich komplett anders an.

Claude Code läuft länger. Es fragt mehr nach. Es löst komplexere Aufgaben in einem Rutsch und kommt mit umfangreicheren, durchdachteren Ergebnissen zurück. Cursor ist dagegen schneller, hat den engeren Editor-Loop, liefert solide Resultate — wirkt aber weniger ambitioniert, weniger kreativ in dem, was es selbständig angeht.

Das war keine Einzelwahrnehmung: Im Hackathon haben alle drei Teams unabhängig voneinander dasselbe Muster beobachtet — und es deckte sich mit dem, was ich aus den Wochen davor schon kannte.

Tool oder Modell?

Die naheliegende Erklärung — "Cursor benutzt halt ein schlechteres Modell" — fällt sofort in sich zusammen. Wir hatten in beiden Tools Opus 4.7 aktiv. Es ist also kein Modell-Unterschied, sondern ein Tool-Unterschied.

Damit landet man bei einem Begriff, der in der Diskussion über AI-Coding-Agenten in den letzten Monaten sehr viel präsenter geworden ist: dem Harness.

Der Harness-Effekt

Der "Harness" ist alles, was um das Modell herum passiert: System-Prompt-Assembly, Context-Compaction, Tool-Routing, Permission-Loop, Subagent-Orchestrierung. Das Modell selbst macht nur einen Teil dessen aus, was am Ende beim Entwickler ankommt — der Rest steckt im Harness.

Wie groß der Effekt ist, zeigt eine Vergleichsanalyse von MindStudio: Opus 4.7 erreicht in Cursor's Harness 91,1 % auf Functionality-Benchmarks — im Claude-Code-Harness 87,2 %. Gleiches Modell, anderer Wrapper, fast vier Prozentpunkte Unterschied.

"The harness gap is now bigger than the model gap."

Klingt zunächst wie ein Punkt für Cursor. Tatsächlich optimieren die beiden Harnesses auf unterschiedliche Dinge:

• Cursor's Harness ist auf schnelle, korrekte Turns im Editor-Kontext optimiert. Composer-Calls unter 30 Sekunden, enger Loop, hohe Iterationsfrequenz.
• Claude Code's Harness ist auf Long-Running-Autonomie optimiert. Laut Anthropic-Analysen sind nur ~1,6 % der Codebasis KI-Logik — die übrigen 98,4 % sind deterministische Infrastruktur: Permission-Gates, Compaction-Pipelines, Hook-Architektur, Subagent-Spawning.

Praktisch heißt das: Wenn die Aufgabe in 30-Sekunden-Turns iteriert wird, ist Cursor stärker. Wenn die Aufgabe ein autonomer Refactoring-Lauf über zwanzig Dateien ist, ist Claude Code besser geeignet. Das erklärt, warum wir bei gleichem Modell zwei sehr unterschiedliche Erfahrungen hatten.

Der "2026 Agentic Coding Trends Report" von Anthropic nennt das Thema Long-Running Agents als einen der definierenden Trends 2026 — Agenten, die Stunden bis Tage durchlaufen, Kontext halten, sich selbst aus Fehlern erholen. Genau das Lastprofil, auf das Claude Codes Harness optimiert ist.

Auto-Mode: ein Reality-Check

Eine Beobachtung, die sich quer durch meine Cursor-Sessions zieht — sowohl aus dem Projektalltag als auch aus dem Hackathon: Der Auto-Mode ist für komplexe Aufgaben nicht zu gebrauchen. Er ist schnell, ja. Aber sobald die Aufgabe über trivialen Text-Kram hinausgeht, liefert er Code auf Junior-Niveau — wenn überhaupt.

Das ist keine Einzelmeinung. Im offiziellen Cursor Community Forum finden sich seit Q1 2026 reihenweise Threads mit Titeln wie "Auto mode has become almost unusable", "Quality of Auto mode significantly dropped", "Auto Mode is terrible". Symptome, die immer wieder genannt werden: Syntax-Errors, halbe Implementierungen, der Verdacht, dass komplexe Anfragen still ans billigere Modell weitergereicht werden.

Praktische Konsequenz für uns: Auto-Mode meiden, stattdessen Composer 2 explizit wählen. Composer 2 ist im Cursor aktuell das beste Modell für einfache Aufgaben hinsichtlich Preis und Qualität, dazu noch relativ schnell. Damit zum Pattern, das tatsächlich gut funktioniert hat.

Das Cursor-Pattern, das funktioniert: Plan-Opus / Execute-Composer-2

Was sich bei mir in den letzten Monaten bewährt hat — und was im Hackathon einmal mehr bestätigt wurde — ist eine bewusste Aufgabenteilung in Cursor: Opus 4.7 für die Planung, Composer 2 für die Umsetzung.

Die Begründung dahinter ist sauber ökonomisch und in der Community gut dokumentiert:

"Use a stronger model like Opus for planning and a cheaper one like Composer for execution. Planning benefits from better reasoning but produces little output, while the expensive part is usually code generation."

Planung ist reasoning-heavy, generiert aber wenig Output — daher in Tokens günstig. Code-Generierung ist output-heavy — daher teuer. Wenn man die beiden Phasen trennt, zahlt man nur dort den Premium-Preis, wo er einen messbaren Vorteil bringt. Composer 2 mit seinen 200+ Tokens/s ist dann ein ehrliches Workhorse-Modell, das die Pläne umsetzt.

In Cursor funktioniert dieser Ansatz gut. In Claude Code spielt er praktisch keine Rolle, weil Plan-Mode und Execution dort enger ineinandergreifen.

Subagent-Reife

Dieser Punkt stammt nicht aus dem Hackathon, sondern aus meiner täglichen Arbeit in AI-nativen, AI-driven Projekten der letzten Monate — und ist genau der Grund, warum ich in solchen Setups inzwischen den Impuls habe, auf Claude Code umzusteigen.

In diesen Projekten wirkt die Subagent-Funktion in Cursor im Vergleich zu Claude Code noch nicht ausgereift. Konkret hatte ich Fälle, in denen sich Subagents verhakt haben, parallel laufende Subagents nicht so dispatcht wurden wie konfiguriert, und in denen die Modell-Auswahl für Subtasks nicht respektiert wurde — also ein günstigeres Modell für einen Subtask gesetzt war, am Ende aber doch ein teureres lief.

Das deckt sich mit dokumentierten Bug-Reports im offiziellen Cursor Community Forum: Subagents bleiben im Status "Starting up" hängen, melden falsche "Completed"-Status, parallele Dispatches werden gedrosselt. Zur Modell-Auswahl gibt es einen eigenen Thread, der die Beobachtung quantifiziert: Subagents, die explizit auf claude-4.5-haiku oder composer gesetzt waren, liefen tatsächlich auf sonnet oder opus. Eine Feature-Request-Diskussion führt das auf einen strukturellen Designpunkt zurück.

Die Auswirkung auf die Kosten ist nicht trivial. Fünf parallele Subagents verbrauchen bereits etwa fünfmal so viele Tokens wie ein einzelner Agent; Workflows mit Subagent-Orchestrierung kommen auf 7- bis 10-fachen Token-Verbrauch im Vergleich zu Single-Agent-Sessions (Trilogy Engineering Workshop). Wenn dabei das eigentlich gewählte günstigere Modell durch ein teureres ersetzt wird, addiert sich der Effekt.

Dass Cursors Subagent-Funktion erst in Version 2.4 (März 2026) eingeführt wurde und seither in jedem Release-Zyklus angefasst wird, ist ein wesentlicher Faktor. Claude Code hat hier mehr Vorsprung — Subagents sind dort kein Add-on, sondern ein zentrales Architekturelement, das seit längerem produktiv im Einsatz ist und entsprechend abgehangener wirkt (Builder.io, Towards AI). Für mich ist das mittlerweile ein klares Argument: Sobald Subagent-Orchestrierung ins Spiel kommt, fahre ich mit Claude Code spürbar ruhiger.

Kosten

In Vergleichen wird der Consumer-Plan oft als Referenz genommen. Für den professionellen Einsatz ist der Teams-Plan die realistischere Bezugsgröße, weil Consumer-Pläne nach aktueller Einschätzung quersubventioniert sind. The Decoder berichtet, dass Anthropics $200-Plan bis zu $5.000 Compute pro Monat verursachen kann. CNBC im April 2026: "AI demand is inflated, and only Anthropic is being realistic." Auf Consumer-Ebene laufen die Anbieter mit negativer Marge, die Margen kommen über das Business-Geschäft.

Sticker-Price

Beim Claude-Code-Team-Plan unterscheidet Anthropic zwei Seat-Typen, die innerhalb desselben Team-Plans gemischt werden können (Team-Plan-Doku):

Anthropic gibt die Included Usage nicht in Dollar an, sondern als Multiplikator relativ zum Pro-Plan pro Session. Das macht die Pläne untereinander vergleichbar, aber den direkten Dollar-Vergleich mit Cursor schwieriger.

Für ernsthafte professionelle Nutzung ist der Standard-Seat mit 1,25× Pro-Usage erfahrungsgemäß zu eng dimensioniert — wer Claude Code wirklich produktiv im Tagesgeschäft einsetzt, läuft hier schnell ins Limit. Wir nehmen daher in diesem Vergleich Premium als realistische Bezugsgröße. Das ist ein bewusstes Apples-to-Apples-Setup gegen einen Cursor-Teams-User mit nicht-trivialer Workload.

Auf dem Papier ist Cursor damit rund dreimal günstiger pro Seat als Claude Code Premium — ein Vergleich, der in dieser Form aber Listenpreise gegen Listenpreise stellt und wenig über die tatsächlichen Kosten im Betrieb aussagt.

Pay-per-Use

Bei beiden Tools setzt nach Aufbrauchen der Included Usage Pay-per-Use ein. Die tatsächlichen Kosten hängen stark vom Workflow ab und sind entsprechend schwer zu prognostizieren.

Wichtig zu wissen ist bei Cursor, wie das Included-Budget verbrannt wird: Pro Seat sind im Teams-Plan $20 Included Usage enthalten — und in diesen Topf fließen alle Modell-Calls, sowohl Opus als auch Composer 2 (Cursor Pricing, Team Pricing Docs). Die Raten unterscheiden sich aber drastisch:

• Claude Opus 4.5/4.7: ~$5 Input / $25 Output pro 1M Token
• Composer 2: ~$0,5 Input / $2,5 Output pro 1M Token

Praktisch heißt das: Wer auf Opus arbeitet, hat das $20-Budget nach wenigen ernsthaften Sessions weggebrannt. Composer 2 streckt denselben Topf um etwa Faktor 10. Genau deshalb funktioniert das Plan-Opus / Execute-Composer-2-Pattern auch ökonomisch und nicht nur qualitativ — die teure Phase ist kurz und Token-arm, die lange Phase läuft auf der günstigen Rate.

Wer das Budget aufbraucht, fällt nicht aus, sondern in Pay-as-you-go zu denselben API-Raten (Cursor Pricing). Es gibt öffentlich dokumentierte Fälle, in denen das schnell entgleist: ein $20-Plan in vier Stunden weg, ein $60-Plan in 24 Stunden, ein Team-Annual-Account über $7.000 an einem Tag verbraucht. Solche Zahlen entstehen vor allem bei undisziplinierter Modell-Wahl (Opus überall) oder Subagent-Orchestrierung mit dem oben beschriebenen Modell-Routing-Problem.

Claude Code ist hier strukturell etwas vorhersehbarer: ein 5-Stunden-Rolling-Window plus 7-Tage-Cap geben klarer abgegrenzte Buckets. Wer darüber hinausgeht, zahlt ebenfalls zu API-Preisen weiter.

Für unser Setup können wir aktuell nicht beziffern, welche Limits ein Entwickler bei welcher Art von Arbeit verbraucht. Das spiegelt den Stand dieses Marktsegments im Mai 2026 wider. Belastbare Zahlen dazu liefern wir nach, sobald wir längere Nutzungszeiträume ausgewertet haben.

Wann was?

Aus diesen Erfahrungen — Projektalltag und Hackathon zusammengenommen — lässt sich grob ableiten:

Cursor benutzen, wenn:

• enge Editor-Iterationen, schnelles Feedback im Vordergrund stehen
• die Aufgabe in Composer-2-Reichweite (Sekunden bis wenige Minuten) liegt
• man bewusst plant: Opus für den Plan, Composer 2 für die Umsetzung
• der Workflow stark in einer IDE verankert ist

Claude Code benutzen, wenn:

• die Aufgabe Multi-File-Refactoring oder größere autonome Läufe ist
• "Fire and forget" mit anschließender Review der Plan ist
• Kostenkontrolle über Buckets (Rolling Window) wichtiger ist als Editor-Latenz
• man die volle Kontrolle über Permission-Modes, Hooks und Subagents nutzen will

In der Praxis nutzen viele Entwickler beide Tools parallel.

Fazit

Die zentrale Beobachtung — sowohl aus den letzten Monaten als auch verdichtet im Hackathon — ist, dass das Tool um das Modell herum für die tatsächliche Arbeitserfahrung mehr Gewicht hat als das Modell selbst. Diese Beobachtung deckt sich mit dem, was öffentliche Quellen zeigen.

Hackathons sind dabei ein nützliches Format, um Tools unter Zeitdruck und im Team zu testen — sie ersetzen aber keine Langzeitnutzung, in der Themen wie Subagent-Stabilität oder Kostenverhalten erst sichtbar werden. Bei form4 bauen wir auf beiden Achsen Erfahrungswerte auf: welches AI-Tool wofür sinnvoll ist und welche Kosten dabei realistisch entstehen.

Quellen

• Anthropic — 2026 Agentic Coding Trends Report (PDF)
• MindStudio — Cursor SDK vs Claude Code Harness
• ZenML LLMOps — Claude Code Agent Architecture: Single-Threaded Master Loop
• Cursor — Introducing Composer 2
• Cursor — Pricing
• Cursor Docs — Team Pricing
• Cursor Docs — Get Started with Teams
• Cursor Community Forum — Auto mode has become almost unusable
• Cursor Community Forum — Sub Agents wont run and are stuck at "Starting up"
• Cursor Community Forum — Subagent model selection not respected
• Cursor Community Forum — Subagents are not useful if we can't select their model
• Trilogy AI — Cursor Engineer Talks Cost Saving Opportunities
• Builder.io — Claude Code vs Cursor: What to Choose in 2026
• Towards AI — Subagents in Agent Coding: How They Differ in Cursor vs Claude Code
• Medium / Realworld AI Use Cases — Some tricks to saving money with Cursor & Claude Code
• Medium / Realworld AI Use Cases — Claude Code & Cursor: the $20 and $60 plans are a joke
• The Decoder — Anthropic's Claude Code subscription may consume up to $5,000 in compute
• CNBC — AI demand is inflated, and only Anthropic is being realistic
• Anthropic — Claude Code on team and enterprise
• Claude Help Center — What is the Team plan?
• Claude Help Center — Extra Usage for Team and Enterprise plans