What Cursor AI is and how it fits next to your files and terminal

Cursor AI is a code editor with an agent built into it, and most of the confusion around it comes from that second half. The editor part is familiar to anyone who has used VS Code. The agent part changes what the window is for: instead of typing every edit, the work becomes describing a task, watching a process run commands, and deciding what to accept. That shift is what makes the tool worth understanding before installing it, and it is also what decides whether it belongs at the center of a setup or next to one.

What the product actually is

Cursor is built on the VS Code codebase. The migration page in the documentation states it plainly.

Cursor is based upon the VS Code codebase, allowing us to focus on making the best AI-powered coding experience while maintaining a familiar editing environment. Source: cursor.com

That inheritance is the reason extensions, themes, keybindings, and settings can be imported in one step from the account section of the settings panel. It is also why the editing experience feels like nothing changed until the AI features are used.

Three of those features do most of the work. Tab is the autocomplete, and it suggests code based on recent edits, surrounding code, and linter errors. It can modify several lines at once, add missing imports, and jump to the next likely editing location when Tab is pressed again after accepting a suggestion. Agent is the assistant that completes tasks on its own, opened with Cmd+I, with tools for searching the codebase, reading and editing files, running terminal commands, controlling a browser, and fetching pages from the web. The documentation notes there is no limit on the number of tool calls an agent can make during a task. Ask mode is the read-only variant, useful for understanding a codebase without any edits happening while the question is answered.

Around those three sit the model picker, rules files that persist instructions across sessions, and a command line version of the agent that runs outside the editor entirely.

What the free plan covers and what the paid plans change

Pricing matters here more than it does with a conventional editor, because the cost is usage, not the software. The help documentation lists the plans directly.

Plan	Price
Hobby	Free
Pro	$20/mo
Pro+	$60/mo
Ultra	$200/mo
Teams Standard	$40/user/mo
Teams Premium	$120/user/mo

The Hobby plan includes Agent, Chat, and Tab completions with the Auto model, with limited usage. Paid individual plans extend the included usage and add cloud agents and other features. Usage resets monthly with the billing cycle and does not roll over, and when the included amount runs out the choice is on-demand billing or a higher plan. Requests made with a personal API key do not draw from the included pools on individual plans, since the model provider bills for them directly.

The practical reading of that table is that the decision is not $20 against free. It is how much agent usage a month of real work consumes, which nobody can answer in advance. Running the free plan for a week on an actual project produces a better estimate than any comparison article.

Models, and why the picker matters less than it looks

Every release brings a new model to the top of the list, and the picker invites the belief that choosing correctly is the main lever. In practice the plan's usage pools matter more than the name selected. Cursor's own models draw from one pool included with the plan, third-party models draw from a second pool charged at provider prices, and the model chosen changes how fast the included amount is consumed. The Spending tab in the dashboard shows both pools in real time, which is the only honest way to find out what a normal week costs.

Auto routing exists for the same reason. Rather than pinning one model, a request can be routed to whichever model fits, billed at that model's list price. For most tasks the difference in output between two frontier models is smaller than the difference made by the context the agent was given, which is why rules and ignore files repay attention more than the picker does.

There is one case where the model choice is decisive: long agent runs on unfamiliar code, where a weaker model produces more wrong turns and each wrong turn costs a review cycle. For a rename across a handful of files, almost anything works.

How the agent gets permission to run things

The most consequential setting in Cursor is not the model. It is how much the agent can do without asking. Run Modes control that, in Settings under Agents, and the documentation describes three.

Auto-review runs allowlisted calls immediately, puts other shell commands in a sandbox when that is possible, and sends anything that cannot be sandboxed to a classifier that either allows it, asks the agent for a different approach, or asks for human approval. Allowlist mode runs only the actions on an explicit list without approval, which produces predictable behavior at the cost of more prompts. Run Everything runs every tool call automatically, which the documentation frames as accepting the risk in exchange for zero prompts.

The sandbox is what makes the middle ground workable. It restricts file access and network activity for shell commands. Commands that need writes outside the workspace or privileged operations cannot run inside it, so they surface for review instead of failing silently.

The setting to check on the first day is this one, not the model picker. An agent that can run anything in a repository with deploy scripts and credentials in reach is a different tool from one that cannot reach outside the workspace, and the difference is one dropdown.

The two files that shape everything the agent does

Behavior that seems like a model quality problem is usually a context problem, and two mechanisms control context.

Rules give the agent persistent instructions. Project rules live in .cursor/rules as .mdc files, are version-controlled with the repository, and can apply always, apply when the agent judges them relevant, apply to files matching a path pattern, or apply only when mentioned by name in chat. A plain AGENTS.md file works as a simpler alternative for projects that do not need that granularity. User rules apply globally to one person's environment, and team rules are managed from the dashboard on Team and Enterprise plans.

Ignore files control what the agent can see. A .cursorignore file in the project root excludes paths from AI context, .gitignore is respected automatically, and environment files, .git/, and lock files are already excluded by default. One caveat in the documentation deserves attention.

Ignored files are blocked from Agent. Terminal commands and MCP tools run outside of Cursor's file access controls, so they may still be able to read ignored files. Source: cursor.com

An ignore file is a context filter, not a security boundary. Secrets that must stay unread by a model should not be reachable by a shell command the agent is allowed to run.

Where the editor is the wrong window

Cursor is organized around a project. The file tree shows the folder that was opened, and the agent works inside it. That is the right shape for writing software in one repository, and the wrong shape for several kinds of work that sit next to it.

Files outside the opened project are the first gap. Reference material in a notes vault, assets on an external drive, downloads waiting to be sorted, screenshots that need renaming before they are used. None of that lives in the repository, and pointing an editor at a folder of images to rename them is an awkward fit.

Long-running work is the second. An agent task that takes twenty minutes needs somewhere to run that is not blocking the window being used for something else. Cursor's own answer is to move the work out of the editor: the CLI runs the same agent in a terminal, with Agent, Plan, and Ask modes available through slash commands or the --mode flag, and a print mode for scripts and CI. Cloud agents run in isolated virtual machines instead of on the local machine, with an iOS app and a web interface for starting and following them.

The third is everything that is not code. A file manager task, a batch of shell commands over a directory, a quick look at what an agent just produced. Those are file and terminal operations, and an editor is a heavy window to keep open for them.

Two smaller features exist because of the same pressure. Checkpoints save snapshots of the codebase during an agent session, created automatically before significant changes, so a wrong turn can be reverted by restoring files to an earlier point in the chat timeline. The documentation is explicit that checkpoints are stored locally, are separate from Git, and should be used only for undoing agent changes rather than as version control. Agent Review runs a dedicated review of local changes from inside the editor, either automatically after commits or on demand through a slash command, comparing all local changes against the main branch rather than only the latest edit.

Both features answer the question that appears once an agent is writing real code: what actually changed, and how is it undone. Neither removes the need to read diffs, and neither replaces a commit.

Where the agent runs	Good for	Constraint
Editor (Cmd+I)	Focused work inside one project	The window stays occupied
CLI (agent)	Terminal-centered work, scripts, CI	No editor context or diffs
Cloud agents	Long tasks, parallel runs, mobile follow-up	Requires connected source control

Fitting it next to files and a terminal

The common setup that emerges after a few weeks is not one window. It is an editor for code, a terminal for commands, a file manager for everything that is not in the repository, and some way to check on agents that are still running. That is three or four windows, and the switching between them is where the day leaks time.

Reducing the switching is mostly about deciding where each kind of work belongs, then removing the windows that exist only to bridge the others. A file manager with a built-in terminal removes one of them, since the folder being looked at and the shell running commands on it stop being separate applications. What a single window covers is set out on Features, how that approach differs from other file managers is laid out on Compared with other file managers, and the answer to whether a paid agent plan and a file tool overlap is on Pricing.

What to change first

Install Cursor, import the VS Code profile, and then open Settings and set the Run Mode before starting any real task. After a week, look at where the window switches actually happen: if most of them are between the editor and a terminal or a folder, the thing to fix is the workspace around the editor rather than the editor itself, which is what Atriens is built for.