Claude Code vs Cursor: which one keeps you in the terminal

Both tools now do the same job. Both read a repository, plan a change, edit files, run commands, and stop to ask before doing something risky. Both cost twenty dollars a month to start. The claude code vs cursor question stopped being about which model writes better code some time ago, and the part that still differs is the shape of the window the work happens in, plus what that shape does to the rest of a Mac.

The shape, which is the actual difference

Cursor is an editor that an agent lives inside. Claude Code is a terminal process with editor extensions bolted on. Each one has grown a version of the other, and that is exactly why the distinction is worth stating precisely rather than dismissing.

Cursor ships a CLI, installed with a one-line script, invoked as agent, with the same modes as the editor and a print mode for scripts and CI. Claude Code ships a VS Code extension, a JetBrains extension, and a desktop app. So the honest summary is not that one is a CLI and the other is a GUI. It is that each one's centre of gravity sits in a different place, and the secondary surface is thinner than the primary one.

What follows from that is which things feel free. In Cursor, opening a file to read it, scrolling a diff, and clicking into a symbol are all zero-effort, because an editor is already there. In Claude Code, piping output into the session, chaining it with a shell command, and dropping the whole thing into a script are zero-effort, because a shell is already there.

The secondary surfaces are worth knowing about before assuming a tool has to be abandoned to get the other shape. Cursor's CLI is installed with a single shell command and started by typing agent, with an optional prompt on the same line, and it carries the same three modes as the editor: a full-access agent mode, a planning mode that asks clarifying questions before writing anything, and a read-only mode for exploring without changes. Non-interactive runs use a print flag, which is what makes it usable inside CI. Claude Code's editor integrations work the other way around, putting the same session inside VS Code or a JetBrains IDE rather than reproducing the editor's own interface.

Pick the one whose free operations match the work being done most often. A developer who reads more code than they run will feel the editor. A developer whose day is builds, logs, migrations, and file surgery will feel the shell.

What each costs today

Prices below are the ones published on each company's own pricing page, and neither includes tax.

Plan level	Claude	Cursor
Free	$0, and Claude Code is not included	Hobby, $0, limited Agent requests
Entry paid	Pro, $20 per month, or $17 per month billed annually at $200 up front	Individual, from $20 per month
Heavy individual use	Max, from $100 per month, at 5x or 20x Pro usage	Pro+ and Ultra tiers above Pro
Team	$25 per seat per month, or $20 billed annually	Teams, $40 per user per month
Enterprise	Seat price plus usage at API rates	Custom

Two things in that table matter more than the headline numbers.

The first is that Claude Code is not on the free tier at all, while Cursor's Hobby plan gives limited agent requests without a card. For evaluating, that difference is real: one can be tried for an afternoon at no cost, and the other cannot.

The second is how overage works. Every Cursor plan includes a set amount of model usage, and on-demand usage past that is billed in arrears. Claude's paid plans carry usage limits with usage credits available on top. Either way, the monthly figure is a floor rather than a ceiling once an agent is running long tasks, and that is the number worth watching for the first two months rather than the subscription price.

Cursor also states plainly that subscriptions are sold only through its own site and that no resellers are authorized, which is worth knowing before buying through a third party.

Models, and where the choice lives

Cursor is model-agnostic by design. Its model list includes several Anthropic models, Google's, OpenAI's, and its own Composer, with context windows published per model on the same page. Claude Code runs Anthropic models, with the model and effort level selectable inside a session.

This cuts both ways and the direction depends on temperament. A single-vendor tool has one set of behaviours to learn, one place where limits are defined, and one bill. A multi-vendor tool lets a cheap model handle a mechanical rename and an expensive one handle an architectural change, at the cost of having to make that call repeatedly.

There is a practical detail worth checking before treating model choice as decisive: both tools let the frontier models work against the same repository, so the code quality argument tends to collapse into a preference about harness behaviour. Which prompts are auto-injected, how aggressively the tool reads surrounding files, when it stops to ask, how it summarizes a long session. That is the layer that differs, and it is not visible on a pricing page.

Authentication is the other place where the two diverge in a way that affects companies more than individuals. Claude Code accepts a claude.ai subscription login, a Console key, or a cloud provider route through Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry, which matters when procurement has already settled on one cloud. Cursor's self-serve plans take credit and debit cards, with invoice billing and wire transfers reserved for the Enterprise plan, and privacy mode, which guarantees that code is not used for training by Cursor or its model providers, is a setting rather than a plan tier.

Rules files, and which one travels

Persistent instructions are where most of a team's real configuration accumulates, and the two tools have converged on a shared convention with different extras around it.

Claude Code reads CLAUDE.md for project instructions and can read a repository's AGENTS.md files, either alone or alongside it. Rules can be scoped to file types in a .claude/rules/ directory. It also has an auto memory that writes notes based on corrections given during a session, separate from the file a person maintains by hand.

Cursor supports four kinds of rules: project rules as .mdc files in .cursor/rules, version-controlled and scoped by path pattern; user rules global to the environment; team rules managed from a dashboard on the Team and Enterprise plans; and AGENTS.md as the simple alternative to the .cursor/rules directory.

The overlap is the point. A repository with a well-written AGENTS.md is portable between both, which makes a trial genuinely cheap and makes switching later much less painful than it looks. The parts that do not travel are the extras: the .mdc path scoping on one side, the auto memory and rules directory on the other.

One warning that applies to both and is easy to miss: instructions in these files are context, not enforcement. A tool that is asked nicely in a markdown file not to touch production credentials may still do it. Blocking an action requires a hook, which both tools support, not a sentence in a rules file.

How much each one will do without asking

Unattended behaviour is where the real risk sits, and both tools expose it as a two-layer setting: what is technically possible, and when it stops to ask.

Cursor's agent runs inside the editor with approvals for commands, plus a read-only Ask mode for exploration and a Plan mode that designs an approach before editing. Cloud agents, automations, and an agentic review tool sit alongside it, along with hooks and subagents for splitting work.

Claude Code takes the same two-layer approach in the terminal, with permission rules, hooks that can block a tool call before it runs, subagents, skills, plugins, and MCP servers. Its Remote Control feature adds something Cursor's desktop editor does not have an equivalent for: a running local session that can be steered from a phone or browser while the work stays on the machine.

For anyone whose hesitation is about autonomy rather than features, the honest advice is the same for both. Start in the read-only or planning mode, watch what it proposes to run, and widen permissions one category at a time. The tools differ in wording here, not in substance.

Running both, which is what most people end up doing

A large number of working setups are not a choice at all. The editor handles reading, reviewing, and small precise edits. The terminal agent handles long autonomous runs, scripted batches, and anything that has to be repeatable in CI. Two subscriptions at twenty dollars each is a real cost, but it is a smaller cost than a week spent fighting a tool for a job it was not shaped for.

If both are running, the boundary worth drawing is about who owns the working tree at a given moment. Two agents editing the same files concurrently produces conflicts that are tedious to unpick, and the cheap fix is a separate git worktree per agent rather than a rule about taking turns. Both tools support that pattern.

The cost that neither pricing page mentions

Here is the part that stays constant no matter which one wins the comparison. Neither tool removes the trips between the folder, the shell, and the assistant for work that is about files rather than code.

Open the folder. Copy the path. Paste it into a terminal. Get a listing. Read it. Decide. Apply. On a cleanup of a few hundred files, that shuttling takes longer than the thinking does, and it does not get faster when the model gets better, because the bottleneck is the window arrangement rather than the inference. An editor-shaped agent is not built for it, and a terminal agent handles the commands but leaves the browsing somewhere else.

A file manager with a built-in terminal closes that specific gap, keeping the current folder as the context so nothing has to be pasted between windows. What that arrangement looks like in practice is described on the Features page, and how it differs from working in Finder next to a separate terminal is laid out on the Compared with other file managers page.

What to change first

Put an AGENTS.md in the repository this week, because it works in both tools and makes any later comparison a fair one. Then run each one for three days on the same real task and count interruptions rather than judging output quality. If most of those interruptions turn out to be window switching rather than waiting on a model, the tool to change is the one holding the folders, and Atriens is built for that half of the problem.