Claude Code vs Cursor: sieben Arten, wie Entwickler die Arbeit aufteilen, seit keines der beiden Tools an eine Oberfläche gebunden ist

Seit dem 12. Oktober 2026 kann ein Entwickler dasselbe Claude-Modell zweimal im selben Cursor-Fenster offen haben und auf zwei verschiedene Arten dafür bezahlen. Wer im Claude-Code-Panel, der Extension von Anthropic selbst, mit einem Claude-Plan angemeldet ist, verbraucht dessen Kontingent. Wer im eigenen Agent-Panel von Cursor auf einem der neuen Cursor-Pläne Claude auswählt, ohne eigenen API-Key, zahlt den API-Listenpreis aus einem vorausbezahlten Guthaben. Beides läuft im selben Fenster, nebeneinander. Die Feature-Tabellen sortieren die beiden Tools immer noch nach Oberfläche, Editor gegen Terminal, und genau die Oberfläche ist dieses Jahr als Unterschied weggefallen.

Claude Code liefert eine Extension mit einem Link „Install for Cursor“. Cursor liefert eine headless CLI für Skripte und CI, Cloud-Agenten, die auf entfernten Maschinen laufen, und Loader, die den Konfigurationsordner von Claude Code lesen. Im Folgenden geht es darum, wie Leute die Arbeit zwischen den beiden tatsächlich aufteilen und was jede Aufteilung kostet. Die Kennzeichnungen sind dieselben wie bei Claude Code und Codex. Dokumentiert heißt: Die Doku eines Herstellers oder die committeten Dateien eines Teams in einem öffentlichen Repository zeigen den Mechanismus. Berichtet heißt: Eine namentlich genannte Person hat ihr Setup veröffentlicht, und ich gebe es weiter, ohne es nachgebaut zu haben.

Zu meinem Standort: Meine Agenten laufen als interaktive Claude-Code-Sessions in tmux, ich stehe also auf der Terminal-Seite. Alles über Cursor unten stammt aus der Doku und den genannten Berichten, gelesen am 18. Oktober.

Ist Claude Code derselbe Agent, wenn es in Cursor läuft?

Ja, und die Doku sagt das ausdrücklich. Die Seite zur VS-Code-Extension verlinkt direkt eine Installation für Cursor und sagt, die Extension „bundles its own copy of the CLI.“ Ihre Versionsnummer ist die der CLI, ~/.claude/settings.json ist „shared between the extension and CLI“, und beide teilen sich den Gesprächsverlauf, sodass claude --resume im Terminal eine Unterhaltung fortsetzt, die im Panel begonnen hat. Das Panel ergänzt die Editor-Dinge: Inline-Diffs nebeneinander, Plan-Review als Markdown-Dokument, das du kommentieren kannst, @-Erwähnungen mit Zeilenbereichen, Checkpoints, zu denen du zurückspulen kannst. Es hat weniger Befehle und Skills als die CLI und keinen !-Shell-Shortcut.

Das ist das Grundmuster, und es ist alt. Steve Sewell, CEO von Builder.io, hat es im Juli 2025 beschrieben (berichtet): Claude Code in Editor-Panes für die Agentenarbeit, von Cursor nur die Inline-Features.

I still use Cursor for quick Command+K completions and tab completions.
But the agent sidebar? I only touch it when Claude is down.

Ein dokumentiertes Detail hält diese Aufteilung stabil. Die API-Key-Seite von Cursor sagt, eigene Keys „only work with chat models. Tab completion continues using Cursor’s built-in models.“ Tab läuft auf Cursors eigenem Modell, egal was du konfigurierst. Damit ist es das eine Cursor-Feature, dem auf der Claude-Code-Seite nichts gegenübersteht.

Kann Cursor nur der Editor sein, während Claude Code die ganze KI-Arbeit macht?

Zwei namentlich bekannte Entwickler berichten genau das, und einer von ihnen hat Cursor danach aufgegeben. Tom Crawshaw schreibt (berichtet), dass er Claude Code den ganzen Tag im integrierten Terminal von Cursor laufen lässt und Cursors eigene KI kaum anfasst („barely touch[es] Cursor’s own AI“). Er sagt ausdrücklich, dass er niemandem rät, Cursor zu kündigen. Eric Roby beschreibt (berichtet) im März 2026 dieselbe Form: Claude Code im Terminal schreibt den Code, in Cursor prüft er ihn. Der Titel verrät, wie es ausging: Er hat das Abo gekündigt und probiert VS Code und Zed als Viewer aus.

Die dokumentierte Seite zeigt, warum der Schritt so kurz ist. Der Changelog von Claude Code bis v2.1.300 enthält eine lange Reihe von Fixes für den Betrieb im integrierten Terminal von Cursor, und die Übersicht sagt, jede Oberfläche verbinde sich mit „the same underlying Claude Code engine.“ Sobald die KI der Terminal-Prozess ist, ist der Editor ein Diff-Viewer mit Dateibaum. In diesem Muster lautet die Frage nicht, welches Tool besser ist. Sie lautet, wofür das Cursor-Abo noch bezahlt, und die übliche Antwort ist Tab.

Solltest du Claude Code und Cursor nach Aufgabengröße aufteilen?

Nur bei Aufgaben, die lang genug sind, um den Wechsel zu verkraften, jedenfalls laut dem einzigen Datensatz, den jemand veröffentlicht hat. Blake Crosley hat 30 Sessions protokolliert (berichtet) und teilt nach Umfang: Claude Code für Refactorings über mehrere Dateien, Tests, Git und Hooks, Cursor für einzelne Views, CSS und Änderungen an einer Funktion. Seine Schlagzeile ist eine um 40 % kürzere Implementierungszeit. Die Zeiten sind seine eigenen, einige Solo-Vergleichswerte sind als Schätzungen markiert, also lies sie als Logbuch eines Entwicklers und nicht als Benchmark. Trotzdem ist seine Tabelle genauer als die Schlagzeile. Bei Arbeit über mehrere Dateien brauchte der kombinierte Workflow im Schnitt 50 Minuten gegenüber 45 mit Claude Code allein, die Aufteilung war dort also langsamer. Der Gewinn steckt in einer Zeile, Architektur plus Feinschliff, mit 40 gegenüber 60 Minuten. Den Overhead für den Wechsel beziffert er auf 3 bis 5 Minuten pro Aufgabe, was alles unter zehn Minuten ausschließt.

Brauchbar ist vor allem der Fehler, den er benennt:

Cursor does not know about architectural decisions Claude Code just made,
producing suggestions that contradict the new architecture.

Seine Lösung ist Handarbeit. Nach einer Architektur-Session in Claude Code aktualisiert er seine Cursor-Regeln, bevor er wechselt, jedes Mal 2 bis 3 Minuten. Das ist das Problem gemeinsamer Anweisungen, sichtbar im Arbeitstag einer einzelnen Person, und die beiden Konfigurationsmuster weiter unten zeigen, was Teams dagegen tun.

Kann Cursor Bugbot die Pull Requests prüfen, die Claude Code schreibt?

Ja, und auch die umgekehrte Richtung ist berichtet. Zack Proser schrieb im März (berichtet), dass er Bugbot „as an automatic reviewer on every Claude Code PR I open“ einsetzt, mit der Checkliste in einer .cursor/BUGBOT.md im Root des Repositorys. Sein Grund ist Modellvielfalt: Was das erste Modell geschrieben hat, soll ein anderes prüfen. In seinem Setup ist Cursor gar nicht der Editor. Es ist der zweite Leser auf GitHub.

Peter Eysermans von madewithlove ging den anderen Weg (berichtet, Oktober 2025). Als Bugbot zu einem Add-on für 40 Dollar im Monat wurde, verlegte sein Team das Review zu Claude, über die GitHub Action von Claude Code, auf einem Pro-Plan für 20 Dollar, den es ohnehin hatte. Er fand Claudes Fehlererkennung „notably better.“ Der Preis hat den Umstieg ausgelöst, die Qualität hat ihn gehalten.

Die Preise aus beiden Beiträgen haben sich geändert. Cursor hat Bugbot auf nutzungsbasierte Abrechnung umgestellt, wirksam bei Verlängerungen nach dem 8. Juni 2026, beziffert einen durchschnittlichen Lauf mit 1,00 bis 1,50 Dollar und schließt Bugbot in den neuen Plänen ab Premium ein. Die GitHub Action akzeptiert weiterhin ein OAuth-Token, das an ein Claude-Abo gebunden ist, das Setup von Eysermans läuft also nach wie vor über einen Plan. Anthropics separates, verwaltetes Code Review für Team und Enterprise ist ein anderes Produkt und wird über Usage Credits abgerechnet, getrennt vom Plan-Kontingent. Die beiden Beiträge kommen aus unterschiedlichen Gründen zu gegensätzlichen Setups, und keiner hat die Wahl des anderen gemessen.

Kann ein Team jeden Entwickler zwischen Claude Code und Cursor wählen lassen?

Ein berichteter Rollout hat genau das getan, und entschieden hat nicht das Modell. Alex Ghiculescu beschrieb (berichtet, April 2025, älter als der Rest) eine Firma mit rund 40 Entwicklern auf einer zwölf Jahre alten Rails-Codebasis, in der „every developer“ Cursor oder Claude Code kaufen konnte. Cursor wurde etwas häufiger genommen. Seine Beobachtung: Claude Code „likes to write entire features for you“, während Cursor bei „smaller and more self contained changes“ blieb.

Er selbst hat Claude Code gewählt, weil er in Sublime Text schreibt und den Editor nicht wechseln wollte. Das lässt sich besser verallgemeinern als alles andere in dem Beitrag: Für den Einzelnen entscheidet der Editor, in dem er ohnehin lebt, mehr als ein Benchmark. Für die Firma hieß das zwei Rechnungen und zwei Sätze Anweisungsdateien für eine Codebasis. Um das Zweite geht es in den nächsten beiden Mustern.

Wie teilen sich Claude Code und Cursor einen gemeinsamen Satz Anweisungen?

Über AGENTS.md, aber ungleich. Zuerst die dokumentierten Leseregeln. Die Rules-Seite von Cursor unterstützt AGENTS.md im Projekt-Root und in Unterverzeichnissen, wobei verschachtelte Dateien kombiniert werden und die spezifischere gewinnt, neben den eigenen .cursor/rules/*.mdc-Dateien (eine einfache .md-Datei dort wird ignoriert). Die CLI-Doku von Cursor ergänzt, dass die CLI auch CLAUDE.md im Projekt-Root liest. Die Rules-Seite des Editors erwähnt das nicht. Claude Code liest seit v2.1.277 AGENTS.md standardmäßig nur, wenn weder CLAUDE.md noch CLAUDE.local.md existiert, ein Fallback, den ich in Claude Code liest jetzt AGENTS.md durchgegangen bin. Die .mdc-Regeln von Cursor findet es nicht von selbst. /init arbeitet .cursor/rules/ und .cursorrules in die erzeugte CLAUDE.md ein, und /import cursor (v2.1.265) hängt eine einmalige Kopie an.

Drei öffentliche Repositories zeigen drei funktionierende Antworten, alle in ihren eigenen Dateien dokumentiert:

• Cypress hält AGENTS.md kanonisch. Die KI-Doku sagt, Cursor und Codex lesen die Datei nativ und Claude Code über einen Import: „One edit propagates to all three tools.“ Rund sechzig CLAUDE.md-Dateien auf Paketebene sind Stubs, die die AGENTS.md daneben importieren. Die CLAUDE.md im Root behält einen Abschnitt, den Cypress für Claude Code vorsieht, und Cursor bekommt eine .cursor/BUGBOT.md für das Review.
• Zod nutzt Symlinks: In colinhacks/zod zeigen sowohl CLAUDE.md als auch die alte .cursorrules auf AGENTS.md. Die gemeinsame Datei beginnt trotzdem mit „This file provides guidance to Claude Code“, eine einzige Datei ist also noch keine tool-neutrale Datei.
• Cloud Foundry UAA ging den umgekehrten Weg. In cloudfoundry/uaa sind die kanonischen Regeln .mdc-Dateien im Cursor-Format in einem neutralen Ordner ai/rules/, ein Skript verlinkt sie per Symlink nach .cursor/, und AGENTS.md weist jeden Agenten an, Claude Code eingeschlossen, diese Dateien vor dem Start zu lesen. Die Zusammenfassung einer Regel verlangt, AGENTS.md, CLAUDE.md und die Copilot-Datei synchron zu halten. Das ist ein manueller Prozess, schriftlich zugegeben.

Cursor findet AGENTS.md-Dateien den ganzen Baum hinunter von selbst. Claude Code braucht eines von drei Setups, um dieselben zu sehen: gar keine CLAUDE.md, damit der Fallback greift; die Einstellung für Projektanweisungen, die beide Dateifamilien lädt; oder eine importierende CLAUDE.md neben jeder AGENTS.md, auf die es ankommt, so wie Cypress es gebaut hat. Was nur in .cursor/rules steht, erreicht Claude Code nur, wenn eine Datei, die es tatsächlich lädt, es anweist, dort nachzulesen.

Führt Cursor deine Skills, Subagenten und Hooks aus Claude Code aus?

Standardmäßig ja. Das ist auf Cursors Seite dokumentiert. Die Skills-Seite sagt, Cursor lade Skills aus .claude/skills/ und ~/.claude/skills/ „for compatibility“, die Subagenten-Seite liest .claude/agents/, und die Seite zu Third-Party-Hooks sagt, Cursor „can load and execute hooks configured for Claude Code“ aus .claude/settings.json, .claude/settings.local.json und ~/.claude/settings.json. All das hängt an einer einzigen Einstellung, „Include Third-Party Plugins, Skills, and Other Configs“, die laut derselben Seite standardmäßig an ist.

Die Konfiguration fließt also nicht in beide Richtungen gleich. Claude Code kopiert die Regeln von Cursor einmal, wenn du /init oder /import ausführst. Cursor liest den Ordner von Claude Code in jeder Session. In einem Team, in dem die Claude-Code-Nutzer .claude/ pflegen, bearbeiten sie damit auch, was Cursor ausführt. Eine Subagenten-Definition in .claude/agents/ kann ihr eigenes Modell nennen, und laut Subagenten-Seite von Cursor gilt die Modellauswahl für den Parent-Agenten. Ein importierter Subagent kann also ein Drittanbieter-Modell aufrufen, das separat abgerechnet wird, selbst wenn der Parent auf einem inkludierten Modell läuft.

Das Hook-Mapping ist unvollständig, und genau dort kann eine Schutzregel unbemerkt aufhören zu greifen. Die Seite zu Third-Party-Hooks bildet PreToolUse auf Cursors preToolUse ab und UserPromptSubmit auf beforeSubmitPrompt, übersetzt das Tool Bash in Cursors Shell und markiert Notification und PermissionRequest als nicht unterstützt, ebenso das Tool Glob. Ein PermissionRequest-Hook aus Claude Code läuft in Cursor nicht. Ein PreToolUse-Hook, der auf Tool-Namen von Claude Code matcht, läuft nur dort, wo es ein Mapping gibt. Cursors eigene Hooks blockieren bei Exit-Code 2, was laut Hooks-Seite „matches Claude Code behavior for compatibility“, und .cursor/hooks.json steht in Cursors Prioritätsreihenfolge vor den .claude-Dateien.

Wenn ein Hook in .claude/settings.json existiert, um etwas zu verhindern, teste ihn in Cursor, nicht nur in Claude Code. Der .claude/-Ordner eines Projekts kommt außerdem mit jedem Klon mit. Das habe ich mir in was ein geklontes Repository in Claude Code festlegen kann angesehen. Cursor liest jetzt denselben Ordner unter seinen eigenen Vertrauensregeln. Die Security-Seite beschreibt Workspace Trust im Editor als standardmäßig deaktiviert, und die CLI verweigert nicht-interaktive Läufe in einem nicht vertrauenswürdigen Workspace, außer du übergibst --trust oder --force. Keine der beiden Seiten sagt, wann importierte Hooks aus einem frischen Klon im Editor zum ersten Mal laufen, und ich habe es nicht getestet. Das ist die Prüfung, die du machen solltest, bevor du dich auf eines davon verlässt.

Schützen dich Claude Code und Cursor auf dieselbe Weise?

Nein, und sie lesen die Regeln des jeweils anderen nicht. Die Permission-Modi von Claude Code reichen von Manual bis bypassPermissions, und seit v2.1.283 starten interaktive Terminal- und VS-Code-Sessions in auto, wo „a second model, the classifier, reviews actions instead of you.“ Dieselbe Doku sagt, eine harte Garantie brauche eine Deny-Regel, nicht den Classifier. Die Sandbox ist aus, bis du /sandbox ausführst. Die Run-Modi von Cursor heißen Auto-review, Allowlist und Run Everything, mit Auto-review als Standard für neue Nutzer. Aufrufe auf der Allowlist laufen unverändert, geeignete Shell-Befehle kommen in eine Sandbox, und der Rest geht an einen Classifier auf Cursors Backend, der einen Aufruf auch außerhalb der Sandbox freigeben kann. Die Warnung auf der Seite ist deutlich:

Auto-review is not a security boundary. The classifier can make mistakes.

Die Regeldateien wandern nicht mit. Claude Code hält seine Allow- und Deny-Regeln in .claude/settings.json, derselben Datei, aus der Cursor die Hooks liest. Die Seite zu Third-Party-Hooks dokumentiert, dass Cursor die Hooks daraus lädt, und weder die Permissions-Seite noch die Run-Modi-Seite von Cursor erwähnt die Permission-Regeln von Claude Code. Cursor hat eigene: Token-Regeln Shell(), Read() und Write() in .cursor/cli.json oder ~/.cursor/cli-config.json, wobei Deny vor Allow gewinnt, und eine permissions.json, die der Editor und seit März auch die CLI lesen und die Allow- und Block-Anweisungen in normaler Sprache für Auto-review aufnimmt. Eine Deny-Regel, die du für Claude Code geschrieben hast, ist laut Doku in Cursor keine Deny-Regel. Ein weiteres Cursor-Detail ist wichtig für alle, die Secrets aus der Reichweite schaffen wollen: Die Doku zur Ignore-Datei sagt, dass das Terminal und die MCP-Tools, die der Agent nutzt, nicht durch .cursorignore blockiert werden können.

Headless ist der Bereich, in dem die Doku am wenigsten eindeutig ist. Die CLI-Seite von Cursor sagt, sie „has full write access in non-interactive mode“, während es auf der Headless-Seite heißt, ohne --force gelte: „changes are only proposed, not applied.“ Teste, was deine Version tut, bevor du agent -p in die CI hängst. Das -p von Claude Code hat seine eigene dokumentierte Falle: Ohne --bare führt es die Hooks eines Projekts aus und verbindet dessen MCP-Server, selbst in einem Ordner, dem du nie vertraut hast. Der Beitrag über geklonte Repositories erklärt, warum --setting-sources user der umfassendere Schalter ist.

Auf welcher Rechnung landet ein Claude-Modell in Cursor?

Das hängt davon ab, wie du angemeldet bist und in welches Panel du tippst, und seit dem 12. Oktober ist der Unterschied größer. Cursor gehört jetzt SpaceX, das die Übernahme am 14. August abgeschlossen hat, und neue Pläne werden als Teil von The X Subscription verkauft. Die Seite zu Modellen und Preisen von Cursor beschreibt, was das für Claude bedeutet:

Third-party models like Claude, GPT, and Gemini aren't part of the included
pool. On Premium and above, they're available in Cursor at the model's API
list price from the first request, paid from your prepaid credit.

Der inkludierte wöchentliche Pool deckt Cursors eigene Modelle ab, Composer und die Grok-Modelle, die es mit SpaceXAI trainiert, und Auto-Routing im Kostenmodus zieht aus diesem Pool, egal welches Modell die Anfrage bedient. Der günstigste neue Plan, Plus, hat überhaupt keine Drittanbieter-Modelle. Teams und Enterprise schlagen eine Cursor Token Rate von 0,25 Dollar pro Million Tokens auf, auch auf deinen eigenen API-Key. Mit einem eigenen Anthropic-Key rechnet Anthropic direkt mit dir ab. Bestehende Pläne sind vorerst nicht betroffen: Die Ankündigung im Forum sagt, die inkludierte Drittanbieter-Nutzung bleibe bis zum Wechsel bestehen, und laut Hilfeseite von Cursor ist der Wechsel endgültig.

Das Claude-Code-Panel im selben Fenster wird anders abgerechnet. Anthropics Artikel zu Pro und Max sagt, der Plan „also covers Claude Code in supported IDEs, including VS Code, Cursor and other VS Code forks“, wobei die Nutzung auf dieselben Limits angerechnet wird wie im Terminal. Cursors eigener Agent kann diesen Plan nicht nutzen. Anthropics Rechtsseite erlaubt Dritten nicht, Anfragen im Namen ihrer Nutzer über Free-, Pro- oder Max-Zugangsdaten zu leiten, und die API-Key-Seite von Cursor führt nur API-Keys auf. Mit einem Claude-Plan-Login in der Extension und ausdrücklich gewähltem Claude im Agenten von Cursor auf einem neuen Plan zieht Opus 5.5 links also von dem, was du Anthropic zahlst, und Opus 5.5 rechts von einem Guthaben, das du bei Cursor auflädst. /usage im Claude-Code-Panel zeigt die Plan-Seite. Cursors Seite steht in dessen Usage-Dashboard.

Auch Anthropics Seite hat ihr Kleingedrucktes. Die monatlichen API-Credits, die Max- und Team-Pläne am 7. Oktober bekommen haben, decken nichts davon ab: Läufe, die aus einer IDE-Extension gestartet werden, „count as Claude Code usage, so API credits don’t cover them, even with -p“, so der Artikel zu den Credits. Und der Artikel zu Pro und Max warnt, dass ein ANTHROPIC_API_KEY in deiner Umgebung Claude Code über die API statt über den Plan abrechnen lässt. Der bleibt leicht liegen, nachdem du in Cursor die Option mit eigenem Key eingerichtet hast.

Mit welcher Aufteilung zwischen Claude Code und Cursor solltest du anfangen?

Das ist meine Lesart der Quellen, keine Messung. Wenn du schon einen Claude-Plan mit Luft nach oben bezahlst, lass die Agentenarbeit über die Claude-Code-Extension oder die CLI laufen, gern innerhalb von Cursor, wenn dir der Editor gefällt, und behalte Cursor für Tab und Inline-Edits. So zahlst du Cursor nicht den Listenpreis für Claude zusätzlich zu einem Plan, der das schon abdeckt, und es ist das einzige Muster hier, das seit 2025 Bestand hat. Prüf vor der Verlängerung, auf welchem Cursor-Plan du bist, denn ein Legacy-Plan und ein neuer behandeln dieselbe Claude-Anfrage unterschiedlich. Wenn du Claude nur wenig nutzt und Cursor dein Hauptwerkzeug ist, kann die Rechnung andersherum ausgehen.

Dann bring die Konfiguration in Ordnung, bevor sie auseinanderläuft. Mach AGENTS.md zur gemeinsamen Datei und gib Claude Code einen Weg, jede einzelne davon zu sehen: eine importierende CLAUDE.md daneben, wie bei Cypress, oder die Einstellung, die beide lädt. Schau dir an, was in .claude/ liegt, im Wissen, dass Cursor es ebenfalls liest, und teste jeden Hook, der etwas blockieren soll, in beiden Tools.

Wer das zweite Tool auslassen sollte: alle, die Diffs ohnehin in einem schlichten Editor prüfen und Tab nicht vermissen. Robys gekündigtes Abo ist das, wohin das Muster „Cursor als Viewer“ führt, und nichts in der Doku redet es ihm aus.

Nichts davon taucht in einer Feature-Tabelle auf. Das eine Tool liest den Konfigurationsordner des anderen in jeder Session, das andere kopiert ihn einmal, keines respektiert die Deny-Regeln des anderen, und dasselbe Modell kann im linken Panel etwas anderes kosten als im rechten.