Claude Code vs Cursor: seven ways developers split the work, now that neither tool is stuck on one surface
Each vendor erased the old editor against terminal line from its own end. What still divides them is quieter: a config folder that Cursor reads live while Claude Code imports Cursor rules once, and permission systems that ignore each other's deny rules.
Contents
Since October 12, 2026 a developer can have the same Claude model open twice in one Cursor window and pay for it two different ways. Signed in to the Claude Code panel, Anthropic’s own extension, with a Claude plan, the usage counts against that plan. Picking Claude in Cursor’s own agent panel on one of Cursor’s new plans, without your own API key, it is charged at API list price from a prepaid credit balance. Both run in the same window, side by side. The feature tables still sort the two tools by surface, editor against terminal, and the surface stopped being the difference this year.
Claude Code ships an extension with an “Install for Cursor” link. Cursor ships a headless CLI built for scripts and CI, cloud agents that run on remote machines, and loaders that read Claude Code’s own config folder. What follows is how people actually divide the work between the two, and what each division costs. The labels are the ones I used for Claude Code and Codex. Documented means a vendor’s docs, or a team’s own committed files in a public repository, show the mechanism. Reported means a named person published their setup and I am relaying it without having reproduced it.
For where I stand: my agents run as interactive Claude Code sessions in tmux, so I am on the terminal side of this. Everything about Cursor below comes from its documentation and the named reports, read on October 18.
Is Claude Code the same agent when it runs inside Cursor?
Yes, and the docs spell it out. The VS Code extension page links an install for Cursor directly, and says the extension “bundles its own copy of the CLI.” Its version number is the CLI version, ~/.claude/settings.json is “shared between the extension and CLI,” and the two share conversation history, so claude --resume in a terminal picks up a conversation started in the panel. The panel adds the editor things: inline side-by-side diffs, plan review as a Markdown document you can comment on, @-mentions with line ranges, checkpoints you can rewind to. It has fewer commands and skills than the CLI and no ! shell shortcut.
This is the baseline pattern, and it is old. Steve Sewell, the CEO of Builder.io, described it in July 2025 (reported): Claude Code in editor panes for the agent work, and from Cursor only the 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.One documented detail keeps this split stable. Cursor’s API key page says custom keys “only work with chat models. Tab completion continues using Cursor’s built-in models.” Tab is Cursor’s own model whatever you configure, so it is the one Cursor feature with no Claude Code counterpart to weigh it against.
Can Cursor be just the editor while Claude Code does all the AI work?
Two named developers report exactly that, and one of them then dropped Cursor. Tom Crawshaw writes (reported) that he runs Claude Code in Cursor’s integrated terminal all day and “barely touch[es] Cursor’s own AI.” He is explicit that he is not telling anyone to cancel Cursor. Eric Roby describes (reported) the same shape in March 2026: Claude Code in the terminal writes the code, Cursor is where he reviews it. The title says how it ended: he cancelled the subscription and is trying VS Code and Zed as the viewer.
The documented side shows why the step is short. Claude Code’s changelog through v2.1.300 carries a long run of fixes for running inside Cursor’s integrated terminal, and the overview says every surface connects to “the same underlying Claude Code engine.” Once the AI is the terminal process, the editor is a diff viewer with a file tree. In this pattern the question is not which tool is better. It is what the Cursor subscription still pays for, and the usual answer is Tab.
Should you split Claude Code and Cursor by task size?
Only for tasks long enough to absorb the switch, on the one dataset anyone has published. Blake Crosley tracked 30 sessions (reported) and splits by scope: Claude Code for multi-file refactors, tests, git and hooks, Cursor for single views, CSS and one-function edits. His headline is a 40% cut in implementation time. The timings are his own, with some solo baselines marked as estimates, so read them as one developer’s log rather than a benchmark. Even so, his table is more specific than the headline. On multi-file work the combined workflow averaged 50 minutes against 45 for Claude Code alone, so the split was slower there. The gain sits in one row, architecture plus polish, at 40 minutes against 60. He also puts the switching overhead at 3 to 5 minutes per task, which rules out anything under ten.
The failure he names is the useful part:
Cursor does not know about architectural decisions Claude Code just made,
producing suggestions that contradict the new architecture.His fix is manual. After an architecture session in Claude Code he updates his Cursor rules before switching, 2 to 3 minutes each time. That is the shared-instructions problem showing up in one person’s day, and the two config patterns below are what teams do about it.
Can Cursor Bugbot review the pull requests Claude Code writes?
Yes, and the reverse is reported too. Zack Proser wrote in March (reported) that he runs Bugbot “as an automatic reviewer on every Claude Code PR I open,” with the checklist in a .cursor/BUGBOT.md at the repository root. His reason is model diversity: a different model should review what the first one wrote. In his setup Cursor is not the editor at all. It is the second reader on GitHub.
Peter Eysermans at madewithlove went the other way (reported, October 2025). When Bugbot became a $40 a month add-on, his team moved review to Claude through the Claude Code GitHub Action, on a $20 Pro plan they already had, and he found Claude’s bug detection “notably better.” Price started the move and quality kept it.
The prices in both posts have changed. Cursor moved Bugbot to usage-based billing at renewals after June 8, 2026, says the average run costs $1.00 to $1.50, and on the new plans includes it from Premium up. The GitHub Action still accepts an OAuth token tied to a Claude subscription, so Eysermans’s setup still runs on a plan. Anthropic’s separate managed Code Review for Team and Enterprise is another product, billed through usage credits apart from plan usage. The two posts reach opposite setups for different reasons, and neither one measured the other’s choice.
Can a team let each developer choose Claude Code or Cursor?
One reported rollout did, and the deciding factor was not the model. Alex Ghiculescu described (reported, April 2025, older than the rest) a company of about 40 developers on a 12-year-old Rails codebase where “every developer” could buy Cursor or Claude Code. Cursor adoption ran slightly higher. His observation was that Claude Code “likes to write entire features for you” while Cursor stayed with “smaller and more self contained changes.”
His own reason for picking Claude Code was that he writes in Sublime Text and did not want to change editors. That generalizes better than anything else in the post: for an individual, the editor you already live in decides more than a benchmark does. For the company it meant two invoices and two sets of instruction files for one codebase. The next two patterns are about the second of those.
How do Claude Code and Cursor share one set of instructions?
Through AGENTS.md, unevenly. The documented reading rules first. Cursor’s rules page supports AGENTS.md in the project root and in subdirectories, with nested files combined and the more specific one winning, next to its own .cursor/rules/*.mdc files (a plain .md file there is ignored). Cursor’s CLI docs add that the CLI also reads CLAUDE.md at the project root; the editor’s rules page does not mention it. Claude Code, since v2.1.277, reads AGENTS.md by default only when no CLAUDE.md or CLAUDE.local.md exists, a fallback I went through in Claude Code now reads AGENTS.md. It does not discover Cursor’s .mdc rules on its own. /init folds .cursor/rules/ and .cursorrules into the CLAUDE.md it generates, and /import cursor (v2.1.265) appends a one-time copy.
Three public repositories show three working answers, all documented in their own files:
- Cypress keeps
AGENTS.mdcanonical. Its AI docs say Cursor and Codex read it natively and Claude Code reads it through an import: “One edit propagates to all three tools.” About sixty package-levelCLAUDE.mdfiles are stubs that import theAGENTS.mdbeside them. The rootCLAUDE.mdkeeps one section Cypress intends for Claude Code, and Cursor gets a.cursor/BUGBOT.mdfor review. - Zod uses symlinks: in colinhacks/zod, both
CLAUDE.mdand the legacy.cursorrulespoint atAGENTS.md. The shared file still opens with “This file provides guidance to Claude Code,” so one file is not the same as a tool-neutral file. - Cloud Foundry UAA went the other way. In cloudfoundry/uaa the canonical rules are Cursor-format
.mdcfiles in a neutralai/rules/folder, a script symlinks them into.cursor/, andAGENTS.mdtells every agent, Claude Code included, to read those files before starting. The summary of one rule says to keepAGENTS.md,CLAUDE.mdand the Copilot file in sync. That is a manual process, admitted in writing.
Cursor finds AGENTS.md files all the way down the tree by itself. Claude Code needs one of three setups to see the same ones: no CLAUDE.md at all, so the fallback applies; the Project instructions setting that loads both file families; or an importing CLAUDE.md next to every AGENTS.md that matters, which is what Cypress built. Anything that lives only in .cursor/rules reaches Claude Code only if a file it does load tells it to go and read it.
Does Cursor run your Claude Code skills, subagents and hooks?
By default, yes. This one is documented on Cursor’s side. Its skills page says it loads skills from .claude/skills/ and ~/.claude/skills/ “for compatibility,” its subagents page reads .claude/agents/, and its third-party hooks page says Cursor “can load and execute hooks configured for Claude Code” from .claude/settings.json, .claude/settings.local.json and ~/.claude/settings.json. All of it sits behind one setting, “Include Third-Party Plugins, Skills, and Other Configs,” which the same page says is on by default.
So the config does not flow the same way in both directions. Claude Code copies Cursor’s rules once, when you run /init or /import. Cursor reads Claude Code’s folder every session. In a team where Claude Code users own .claude/, they are also editing what Cursor runs. A subagent definition in .claude/agents/ can name its own model, and Cursor’s subagents page says the model picker applies to the parent agent, so an imported subagent can call a third-party model that bills separately even when the parent runs on an included one.
The hook mapping is partial, and that is where a guardrail can quietly stop applying. The third-party hooks page maps PreToolUse to Cursor’s preToolUse and UserPromptSubmit to beforeSubmitPrompt, translates the Bash tool to Cursor’s Shell, and marks Notification and PermissionRequest as unsupported, along with the Glob tool. A Claude Code PermissionRequest hook does not run in Cursor. A PreToolUse hook that matches Claude Code tool names runs only where a mapping exists. Cursor’s own hooks block on exit code 2, which its hooks page says “matches Claude Code behavior for compatibility,” and .cursor/hooks.json comes ahead of the .claude files in Cursor’s priority order.
If a hook in .claude/settings.json exists to stop something, test it in Cursor, not only in Claude Code. A project’s .claude/ folder also arrives with every clone, which is what I looked at in what a cloned repository can set in Claude Code. Cursor now reads the same folder under its own trust rules. Its security page describes the editor’s workspace trust as disabled by default, and its CLI refuses non-interactive runs in an untrusted workspace unless you pass --trust or --force. Neither page says when imported hooks from a fresh clone first run in the editor, and I have not tested it. That is the check to make before you rely on either.
Do Claude Code and Cursor protect you the same way?
No, and they don’t read each other’s rules. Claude Code’s permission modes run from Manual to bypassPermissions, and since v2.1.283 interactive terminal and VS Code sessions start in auto, where “a second model, the classifier, reviews actions instead of you.” The same docs say a hard guarantee needs a deny rule, not the classifier. Its sandbox is off until you run /sandbox. Cursor’s run modes are Auto-review, Allowlist and Run Everything, with Auto-review the default for new users. Allowlisted calls run as they are, eligible shell commands go into a sandbox, and the rest goes to a classifier on Cursor’s backend, which can approve a call to run outside the sandbox. The page’s warning is plain:
Auto-review is not a security boundary. The classifier can make mistakes.The rule files don’t carry over. Claude Code keeps its allow and deny rules in .claude/settings.json, the same file Cursor reads for hooks. Cursor’s third-party hooks page documents loading the hooks from it, and neither Cursor’s permissions page nor its run-modes page mentions Claude Code’s permission rules. Cursor has its own: Shell(), Read() and Write() token rules in .cursor/cli.json or ~/.cursor/cli-config.json, with deny winning over allow, and a permissions.json that the editor and, since March, the CLI both read, which takes plain-English allow and block instructions for Auto-review. A deny rule you wrote for Claude Code is, by the documentation, not a deny rule in Cursor. One more Cursor detail matters to anyone moving secrets out of reach: its ignore file docs say the terminal and MCP tools used by the agent cannot be blocked by .cursorignore.
Headless is where the docs are least settled. Cursor’s CLI page says it “has full write access in non-interactive mode,” while its headless page says that without --force, “changes are only proposed, not applied.” Test which one your version does before you put agent -p in CI. Claude Code’s -p has its own documented trap: without --bare, it runs a project’s hooks and connects its MCP servers even in a folder you never trusted. The cloned-repo post covers why --setting-sources user is the broader switch.
Which bill does a Claude model in Cursor go on?
It depends on how you are signed in and which panel you type into, and since October 12 the difference is larger. Cursor is now owned by SpaceX, which completed the acquisition on August 14, and new plans are sold as part of The X Subscription. Cursor’s models and pricing page describes what that means for Claude:
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.The included weekly pool covers Cursor’s own models, Composer and the Grok models it trains with SpaceXAI, and Auto routing in its cost mode draws from that pool whichever model serves the request. The cheapest new plan, Plus, has no third-party models at all. Teams and Enterprise add a Cursor Token Rate of $0.25 per million tokens on top, including on your own API key. With your own Anthropic key, Anthropic bills you directly. Existing plans are unaffected for now: the forum announcement says included third-party usage continues until you switch, and Cursor’s help page says the switch is permanent.
The Claude Code panel in the same window bills differently. Anthropic’s Pro and Max article says the plan “also covers Claude Code in supported IDEs, including VS Code, Cursor and other VS Code forks,” with usage counting toward the same limits as the terminal. Cursor’s own agent cannot use that plan. Anthropic’s legal page does not let third parties route requests through Free, Pro or Max credentials on behalf of their users, and Cursor’s API key page lists only API keys. So with a Claude plan login in the extension and Claude picked explicitly in Cursor’s agent on a new plan, Opus 5.5 on the left draws on what you pay Anthropic, and Opus 5.5 on the right draws on a balance you top up for Cursor. /usage in the Claude Code panel shows the plan side. Cursor’s side is on its usage dashboard.
Anthropic’s side has its own fine print. The monthly API credits that Max and Team plans gained on October 7 do not cover any of this: runs started from an IDE extension “count as Claude Code usage, so API credits don’t cover them, even with -p,” per the credits article. And the Pro and Max article warns that an ANTHROPIC_API_KEY in your environment makes Claude Code bill the API instead of the plan, which is easy to leave behind after setting up Cursor’s bring-your-own-key option.
Which Claude Code and Cursor split should you start with?
This is my read of the sources, not a measurement. If you already pay for a Claude plan with room to spare, run the agent work through the Claude Code extension or the CLI, inside Cursor if you like the editor, and keep Cursor for Tab and inline edits. That avoids paying Cursor list price for Claude on top of a plan that already covers it, and it is the one pattern here that has held since 2025. Before you renew, check which Cursor plan you are on, because a legacy plan and a new one treat the same Claude request differently. If your Claude usage is light and Cursor is your main tool, the arithmetic can come out the other way.
Then fix the config before it drifts. Make AGENTS.md the shared file, and give Claude Code a way to see every one of them: an importing CLAUDE.md beside each, as Cypress does, or the setting that loads both. Look at what is in .claude/ knowing that Cursor reads it too, and test any hook that is meant to block something in both tools.
Who should skip the second tool: anyone who already reviews diffs in a plain editor and does not miss Tab. Roby’s cancelled subscription is where the “Cursor as viewer” pattern leads, and nothing in the docs argues him out of it.
None of this shows up in a feature table. One tool reads the other’s config folder every session and the other copies it once, neither honors the other’s deny rules, and the same model can cost one thing in the left panel and another in the right.
01 / Discussion
No comment section here — all discussions happen on X.
02 / More articles
Claude Code fork subagents in claude -p: what 2.1.302 changed for headless runs
Offered is not used: a headless model may never pick a fork, and the official docs still describe the old default. Checking which subagent your pipeline got, why a background fork hands a parser two answers, and where switching it off pays.
Claude Code statusline and ccusage: the native rate limits, and a 5-hour block that ends at a different time
Two tools answer one question with different evidence: the server reports a reset time, a log parser infers one. When they disagree by hours, believe the server and keep the parser for history. The dollar figure, on a subscription, is an exchange rate.
MCP vs API for AI agents: the API catalog is a directory, and the choice is who sits in the middle
An API catalog does not compete with an MCP server: it can list one. With that settled, the choice between MCP and a plain HTTP API described by OpenAPI comes down to whether a host application integrates your service for the model, and whether anyone has already decided to put you in front of it.