Cursor, an editor where the model sees the whole repository

Cursor, an editor where the model sees the whole repository

Cursor is a fork of VS Code in which a language model is not a bolted on extension but part of the editor itself. The difference lies in context access: the assistant sees open files, change history, project search results, and terminal errors, rather than only the fragment you paste in.

In June 2026 the company behind the product, previously known for a record pace of revenue growth, signed an agreement to be acquired by SpaceX in an all stock transaction valued at sixty billion dollars, with closing planned for the third quarter. Two days later it acquired the Continue team and wound that open source project down.

What moving from an extension to an editor buys

The biggest difference does not lie in model quality, since the models are the same as elsewhere. It lies in how much context reaches the request without your involvement.

An extension usually sees the current file and whatever you select. An editor built around a model indexes the repository, so a question about where payments are handled finds an answer without you supplying paths. That sounds minor and decides whether the tool answers questions about architecture or merely completes lines.

The second difference is acting on many files at once. Renaming a field on a type, fixing every use of it, and updating tests is one instruction rather than twenty separate edits.

The third is the feedback loop. The editor sees compiler errors and test results, so it can fix its own change without a human relaying the message.

Auto mode and model choice

The most important thing for the bill and the most often skipped. Auto mode picks a model for the task itself and on paid plans does not draw from the credit pool, so it should be the default setting.

You pick a model by hand when a task is hard and you know the cheaper one will not manage. Then you reach for stronger reasoning and pay from the pool. The reverse order, pinning the most expensive model to everything, is the most common cause of bill surprise.

The vendor also develops its own model aimed at coding, cheaper than frontier models at comparable quality on typical editing tasks. Test it on your own repository, since differences between models depend heavily on language and project style.

The practical rule: start in auto mode and switch to a frontier model deliberately, on tasks spanning many files or requiring reasoning about architecture.

Project rules

This is the most underrated feature and the one that improves suggestion quality most. Rules are files in the repository describing project conventions, attached to the context automatically.

---
description: Frontend conventions
globs: ["src/**/*.tsx"]
alwaysApply: false
---

- Function components with typed props, no React.FC
- Styling with Tailwind classes only, no styled-components in new code
- API calls only through `src/api/client.ts`
- No comments in generated code

A rule matched to paths attaches only when working on matching files, so the context does not bloat with rules that do not apply right now. Three attachment modes are worth understanding, since mixing them is the most common cause of rules that never fire.

alwaysApply: true          # always in context, use sparingly
globs: ["src/**/*.tsx"]    # only while working on matching files
description: "..."         # the model decides whether to reach for it

A rule set to always apply enters every request, so three such rules of a hundred lines each consume the context before the model sees your code. A rule with a description and no glob is sometimes skipped, because the decision to use it belongs to the model.

A good rule says what not to do rather than only what to do. A model reaches by default for the most popular solutions rather than the ones you adopted, so the difference between two phrasings of the same principle is considerable.

Weak:
- We write clean, readable code

Better:
- We do not use moment.js, new code uses date-fns
- We do not call fetch directly in a component, only through src/api/client.ts
- We do not add new dependencies without asking
- Tests are written against behaviour, not against the implementation

The first phrasing changes nothing, since the model already believes it writes readably. The second cuts off specific choices it would otherwise make on its own.

Keep rules in the repository rather than in editor settings. Then they bind the whole team and go through review like any other code.

.cursor/rules/frontend.mdc
.cursor/rules/api.mdc
.cursor/rules/tests.mdc
.cursorignore

That last file serves a separate purpose: it excludes named paths from indexing. Dependency directories, generated code, and test fixtures only dilute retrieval, and files holding secrets should never reach the index at all.

node_modules/
.next/
dist/
*.generated.ts
.env*
infra/secrets/

Working across many files

Agent mode applies changes across the project, runs commands, and reads their output. It is the most powerful and the most risky part of the tool.

Three habits separate useful work from cleaning up after it. The first is a clean repository state before starting, so model changes stay distinguishable from your own and revert in one command. The second is tasks the size of a single commit, since an agent asked to rebuild half an application produces a diff nobody will review. The third is reviewing changes before accepting them, exactly as with somebody else's code.

Restrict command execution permissions too. An agent running whatever it deems necessary will eventually run a database migration or a command deleting files. A list of commands requiring confirmation solves that without taking the tool's usefulness away.

Pricing

Annual billing cuts the rate by roughly a fifth, bringing the base plan to about sixteen dollars a month. The team plan changed in June 2026, raising limits and adding a separate seat tier for people leaning heavily on frontier models. Two seat tiers inside one team is worth noting when planning a budget: the two people assigning agent tasks all day get the pricier seats while the rest of the team stays on the base ones, instead of raising the rate for everybody. The top tier is quoted individually, with no rate in the price list.

Three things drive whether you stay within plan. The first is how much of your daily work runs in auto mode, since it does not draw from the pool. The second is context length: working with twenty files open costs many times more than with three. The third is repeating tasks the model does not understand for want of project rules, so the same change goes to the model three times.

Context, or how the model knows what you are asking about

Answer quality depends almost entirely on what reached the request. It pays to know the routes context takes in, since each behaves differently.

Naming a file or directory attaches its content directly. That is the most reliable route and worth using when you know where the heart of the matter lies. Referencing repository changes attaches the current diff, which suits asking for a review of your own work before committing.

Project search runs on the index and suits exploratory questions, when you do not know where to look. It is less reliable in large repositories, since it returns semantically similar fragments rather than necessarily the right ones.

Referencing external documentation fetches a page and adds it to the request. That solves the most common problem with libraries whose interface changed after the model's knowledge cutoff.

The practical conclusion runs against intuition: more context does not mean better. Twenty open files distract the model and cost many times more than the three right ones. Closing unnecessary tabs before a hard question is one of the simplest things that improves results.

Working with a large existing project

Tools of this kind perform best on new code and are most often used on old code. A few things shift that balance favourably.

The first is a project description in the rules: what the application does, what the main directories are, and where the entry points sit. Without that knowledge the model starts every task by guessing the structure.

The second is framing tasks by reference to existing code. Asking to "add invoice handling analogous to the orders module in src/orders" yields results matching project convention, while asking to "add invoice handling" yields tutorial code.

The third is incremental work. In a large repository one big instruction almost always turns out worse than five small ones, since each step can be checked before more accumulates on top of it.

The fourth is tests as a reference point. If the project has tests, the agent can run them after every change and fix its own errors. If it does not, start by writing tests for the part you intend to change.

Cursor against the alternatives

These tools do not exclude each other, and many teams run two at once: an editor for interactive work and a terminal assistant for long tasks. That second tool is sometimes the terminal itself: Warp has an agent built into the shell and can run CLI assistants side by side, so debugging a deployment needs no window switching. Billing there runs on credits at API rates, though, and the free plan carries no credit pool, so without your own model vendor key the agentic features cost from day one. The cost of that arrangement is often lower than one top tier plan, since each tool does what it is cheaper at.

When comparing, remember that the differences between these tools are smaller than the difference between using them with project rules and without. The same model in the same editor gives incomparable results depending on whether it knows what the conventions in your code look like. So before switching tools because the suggestions are poor, check whether the repository holds anything describing them.

The second thing worth checking before changing tools is how tasks are phrased. General requests give general results, however good the model on the other side is.

Privacy and company data

By default code reaches model vendors, so deploying inside a company needs deliberate configuration. Privacy mode disables code retention on the service side, and an ignore file keeps chosen directories out of the index.

.env*
secrets/
**/*.pem
infrastructure/production/

Set exclusions on day one, since the index is built when the project is first opened. Adding a rule later does not recall what already went out.

For data that cannot leave your infrastructure, no setting substitutes for a local model. Then the right choice is an editor with a model running on your own machines, at the cost of suggestion quality. The off the shelf product in that niche is Tabnine, which on top of private cloud deployment offers a fully air gapped variant and retains none of the code you send. You pay for that literally: individual plans were withdrawn, and rates start at 39 dollars per seat per month on an annual commitment.

Common mistakes

The first is working without project rules. The model then suggests popular solutions rather than the ones adopted in your code, and every suggestion needs fixing.

The second is pinning the most expensive model permanently. Auto mode handles most tasks without drawing from the pool, and the difference shows only on hard reasoning.

The third is tasks too large for the agent. A diff covering forty files will not be reviewed, so it enters the repository on faith.

The fourth is no clean state before starting the agent. Mixing your own changes with the model's means unwinding a failed attempt by hand.

The fifth is indexing directories holding secrets. An environment file in the index is a leak you cannot undo.

The sixth is treating generated tests as proof of correctness. A test written by a model for code written by a model usually confirms what the code does rather than what it should do.

FAQ

What does Cursor cost?

The free plan lets you try the tool, and the typical choice for daily work is the 20 dollar monthly plan. Higher tiers, 60 and 200 dollars, raise the frontier model usage pool. Annual billing cuts the rate by roughly a fifth.

Is Cursor better than Copilot?

For whole project work usually yes, since it sees more context and acts across many files at once. GitHub Copilot wins on price and on letting you stay in your existing editor. For plain code completion the difference is slight.

What does the SpaceX acquisition mean?

The agreement was signed on 16 June 2026 with closing planned for the third quarter, subject to regulatory approval. Nothing changes immediately for users, but when planning years ahead it is worth assuming possible shifts in pricing and product direction, both typical after a change of owner.

Does code reach model vendors?

By default yes. Privacy mode limits code retention on the service side, and an ignore file keeps chosen directories out of the index. A requirement for full locality needs a model running on your own infrastructure.

Is it worth using Cursor alongside a terminal assistant?

Many teams do exactly that. The editor suits interactive work and reviewing changes, while a terminal assistant suits long tasks and work on a server. Splitting the roles often costs less than one top tier plan.

Documentation sits on the product site, and the transaction was covered by TechCrunch.