Cursor: modes, rules, pricing, and limits

Cursor combines a code editor with AI agents that can explore a project, prepare a plan, and edit files. Using it effectively means choosing the right mode, providing precise context, controlling permissions, and reviewing changes. Its cost depends on your subscription, the models you use, and any additional usage.

What Cursor does and what remains your responsibility

Cursor lets you move from asking a question about code to making changes in a project. That continuity is convenient, but it brings two different activities close together: receiving an explanation and authorizing a program to act.

A coding agent can find the relevant files, propose a fix, apply it, and then use the terminal to check the result. You still need to decide whether the change solves the problem, respects the project’s constraints, and is ready to merge.

Consider a hypothetical example: a form accepts an invalid address. A useful request states the expected behavior, identifies the files likely to be involved, and explains how to check the fix. A broad request to improve the form leaves more decisions to the model and creates more room for the scope to expand.

The result you review therefore includes several things: file changes, commands executed, tests, and an explanation of any remaining limitations. A message saying the task is complete does not establish that every necessary check has been performed.

Our article on how coding agents work explains this action loop. This guide provides a lasting method for working with Cursor; the AI tools directory places this use case alongside other types of tools.

Choosing between exploration, planning, and editing

Start by deciding what you are authorizing for the task. Understanding an architecture, choosing an approach, and modifying an application call for different levels of autonomy.

Criterion	Ask	Plan	Agent
Goal	Understand the code	Prepare a change	Implement a change
Expected work	Search and explanation	Exploration and a plan you can revise	Editing and tool use
When to use it	Getting to know a project	An ambiguous request or a change spanning several areas	A sufficiently defined scope
What to review	References and reasoning	Assumptions and steps	File changes and verification

The official documentation describes Plan Mode as a research and clarification phase before code is written. You can review and revise the plan before starting implementation. This helps when a request could be addressed in several different ways.

For a small, localized fix, an extensive plan may add little value. You can ask directly for a limited change with clear acceptance criteria. A migration or a change to authentication, by contrast, warrants a review of the approach before any files are edited.

Do not treat a mode as a security guarantee. The mode organizes the work; permissions and available access determine what the environment actually allows. Review both before authorizing sensitive work.

Prerequisites: prepare a project you can restore

To get started, you need a Cursor account, a network connection, and a project you are authorized to share with the services involved. Install the environment the project requires as well: the editor does not replace its interpreter, compiler, or dependencies.

Begin with a practice repository or a working copy without sensitive data. You should know how to launch the application and recognize its normal behavior. Without that baseline, a change can appear correct while breaking another user workflow.

Before asking the agent to do anything:

Save your existing work and identify any changes already present.
Create a dedicated branch if you use Git.
Locate the development instructions and available tests.
Remove unnecessary secrets and production access.
Define the expected result and the operations that require approval.

Do not ask the agent to clean up a folder indiscriminately when it contains unsaved work. Without an explanation, it may struggle to distinguish an intentional change from a temporary file.

For a beginner, the first goal should be modest: a fix you understand and can undo. The guide to working effectively with a coding agent goes further into breaking tasks down and reviewing the results.

Installing Cursor and preparing your first session

1. Install the desktop application

Use the official download page and choose the package for your operating system and machine architecture. Cursor offers applications for macOS, Windows, and Linux, according to the page checked on October 24, 2026.

Next, open a specific project folder. Avoid using your entire home folder or a directory containing several clients’ projects as the workspace. A clear boundary makes files easier to find and reduces exposure of material unrelated to the task.

Sign in to your account, then review the privacy settings, selected model, and execution options. For your first session, keep explicit approval enabled for operations you do not yet understand.

2. Install the CLI only if you need it

The CLI provides another interface for working from the terminal. You do not need it to follow this method in the desktop application.

The following commands come from the official Cursor CLI installation documentation, checked on October 24, 2026. On macOS, Linux, or Windows with WSL:

curl https://cursor.com/install -fsS | bash

On native Windows, in PowerShell:

irm 'https://cursor.com/install?win32=true' | iex

These commands download and execute a script. In a managed workplace environment, follow the approved deployment procedure.

Then check the installation:

agent --version

Start an interactive session:

agent

The documented update command is:

agent update

3. Get an overview before making changes

First, ask for an explanation of the project: its entry point, folder structure, startup procedure, and test locations. Require file paths so you can check the answers against the repository.

If the agent cannot find something, ask it to say so. A guessed test command may produce output that has little to do with the procedure the project actually uses.

Making your first change while staying in control

4. Write a request you can verify

A good request includes the problem, expected outcome, scope, and constraints. Here is an example instruction to adapt:

Le formulaire accepte une adresse vide.
Repère la validation existante et explique la cause.
Propose une correction limitée à ce comportement.
N'ajoute pas de dépendance.
Ajoute ou adapte un test pertinent.
Demande mon accord avant toute opération sur une base de données.

This is an editorial example, not a built-in Cursor command. It asks the agent to investigate why a form accepts an empty address, propose a narrowly scoped fix without adding a dependency, add or adapt a relevant test, and seek approval before any database operation. Replace each constraint with an actual project requirement.

Avoid combining a bug fix, a visual redesign, and a technical reorganization in the same request. Separate changes are easier to review and discard independently.

5. Review the plan and permissions

If you use Plan, check the proposed files, assumptions, and tests. Ask the agent to clarify unknowns before starting implementation.

When a command requests permission, read both the command and the directory where it will run. A familiar-looking command can act on a remote service or invoke a script whose name does not reveal its effects.

6. Verify the result before merging

Review the file diffs. Look for changes outside the agreed scope, deletions, new dependencies, and configuration changes.

Run the project’s relevant checks, then reproduce the affected user workflow. Finally, ask for a report that distinguishes what was run, what passed, and what still needs checking. Keep the decision to merge in your own hands.

Providing context without sending the entire repository

An agent can work from a faulty assumption if it cannot see the relevant files. At the same time, adding unrelated documents makes the request harder to follow.

For each task, provide the observed behavior, expected result, and relevant references: a file, error message, existing test, or architecture instruction. Prefer a reproducible example to a long, approximate account of what happened.

The context window is the amount of information a model can process during an exchange. It guarantees neither a complete understanding of the repository nor correct handling of every detail.

If the conversation drifts, stop the edits and restate the problem using confirmed facts. A fresh session with a focused summary can be easier to supervise than a growing collection of contradictory corrections.

Keep data separate from instructions, too. A ticket, code comment, or external page can contain a prompt injection. Its contents should not authorize a file transfer, a command, or a permissions change.

One practical instruction is to ask the agent to flag operational instructions found in this material before following them. This supplements technical restrictions without replacing them.

Writing useful rules you can maintain

The official Cursor rules documentation covers user rules, project rules, team rules, and the AGENTS.md file. Project rules live in .cursor/rules and use the .mdc extension.

A rule can always apply, apply to certain files, be selected according to relevance, or be invoked manually. An ordinary Markdown file placed in .cursor/rules does not replace the expected format.

Here is an editorial example of a project rule to adapt:

---
alwaysApply: true
---

- Lire les instructions de développement avant de modifier le projet.
- Réutiliser les conventions existantes.
- Ne pas ajouter de dépendance sans expliquer sa nécessité.
- Ne pas modifier les fichiers générés.
- Présenter les vérifications exécutées et les limites restantes.

The example asks the agent to read the development instructions, follow existing conventions, explain any need for a new dependency, leave generated files alone, and report completed checks and remaining limitations.

Put personal preferences in user rules and shared conventions in the repository. Limit specialized rules to the files they concern.

A rule should state a requirement you can check. Asking for clean code leaves substantial room for interpretation; asking the agent to preserve a public interface provides a concrete criterion.

Review rules alongside the code: an outdated procedure can lead the agent to repeat a mistake. Avoid conflicting instructions duplicated across several files. Rules remain instructions to the model, rather than security barriers.

Pricing: separate the subscription from usage

As of October 24, 2026, the official pricing documentation lists the following plans in US dollars, excluding taxes. Check prices and terms again before subscribing.

Current plan	Monthly price	Included usage	Third-party models
Free	$0	Limited	Unavailable
Plus	$8	Base allowance	Unavailable
Premium	$30	Four times Plus	Billed separately
Super	$100	Fifteen times Plus	Billed separately
Ultra	$200	Fifty times Plus	Billed separately

The current plans fall under The X Subscription. Their usage allowance for Cursor models resets weekly and is shared across the relevant services. Third-party models, available from Premium onward, draw on prepaid credit as soon as you use them.

Legacy subscriptions, including Pro and Pro+, retain different arrangements. An older explanation of billing may therefore not apply to a current plan.

To build a budget, record your exact plan, the model in use, available credit, and any limits on additional spending. Check automatic top-up settings as well.

Then assess costs using representative tasks: a short fix, an investigation, and a change spanning several parts of the project. Include the human time spent reviewing results and handling any necessary rework.

The useful measure is the cost of an accepted task. A low-cost response that takes a long time to correct may offer less value than a more expensive change you can verify directly.

Privacy, secrets, and MCP tools

According to Cursor’s security page, updated on August 25, 2026, Privacy Mode prevents your data from being used for training. The vendor also describes controls and commitments involving its model providers. This does not mean processing stays on your computer.

Before opening a confidential repository, review the obligations that apply to your organization, the services involved, and the data they can access. Do not paste secrets into a conversation to work around a configuration problem.

The .cursorignore file limits access to certain files by Cursor features. However, the ignored files documentation states that terminal and MCP tools can access affected content. This file therefore does not provide a complete isolation boundary.

Cursor can connect to external tools through its official MCP configuration. Each connection adds capabilities and access you need to review: reading documents, querying a service, or modifying data, depending on the server.

Start by connecting only a source you need, preferably with read-only access. Check who provides the server, its permissions, and how to revoke its access.

The tutorial on installing an MCP server in Cursor explains the setup. For sensitive environments, the guide to securing an AI agent helps organize permissions, isolation, and human approval.

Common problems

The agent changes too many files. Stop the task and inspect the diffs before continuing. Restate the scope and separate the fix from optional improvements. Do not accept a rewrite simply because it has already been produced.

The response describes a file that does not exist. Ask for the exact path and confirmation that the file exists. Also check that you opened the correct folder. A plausible explanation may be based on a general convention rather than your project.

A rule seems to be ignored. Check its extension, scope, and application mode. Then ask the agent to verify a concrete requirement. The presence of a file does not establish that every instruction in it was followed.

The agent command cannot be found. Check that you installed the CLI, then reopen the terminal. Review the installation path and PATH using the official documentation. The desktop application and terminal command are separate installations.

Tests pass, but the problem remains. Check that the test actually reproduces the original defect. A test added after the fix may only confirm the behavior of the new code. Repeat the user scenario as well.

Usage is higher than expected. Check the selected model, additional credits, and activity from services sharing your allowance. A request in plain language does not necessarily correspond to a single model call.

Limitations and selection criteria

Cursor is a suitable option if you want to work in an editor, follow the changes, and alternate between explanations and implementation. You still need time to read the code and verify the results.

For someone entirely new to development, the risk is accepting a project whose dependencies or deployment they no longer understand. Keep objectives limited and ask for explanations of every decision that shapes the project.

For a team, also assess account management, shared conventions, privacy, and the review process. A successful demonstration on a small example is not enough to justify deployment across the team.

The Cursor and Claude Code comparison explains their different approaches. Above all, compare tools on the same repository using the same criteria: functional correctness, unnecessary changes, verification, usage, and review time.

Checklist before merging a change

Frequently asked questions

Can you use Cursor without knowing how to code?

You can ask for explanations and simple changes in plain language. Before publishing an application, however, you need to be able to check its behavior, dependencies, and access to data. A result that looks right on screen is not enough to establish that it is secure.

Do you have to install Cursor CLI?

No. You can work in the desktop application without installing the CLI separately. The CLI gives you access to an agent in the terminal and supports automation workflows. Start with a single interface so you can understand its permissions and usage.

Does a Cursor subscription include every model?

No. Current plans distinguish between included usage for Cursor models and separately billed usage for third-party models available on certain plans. Legacy subscriptions follow different arrangements, so check the exact name of your plan.

Can Cursor rules prevent a dangerous command?

A rule instructs the model; it does not impose a technical restriction. Protection also depends on permissions, environment isolation, and approval checks. An instruction to act cautiously does not replace limits on access.

Can you use Cursor with a confidential repository?

That depends on your organization's obligations and the configuration you choose. Review data processing, the providers involved, and connected tools before opening the repository. Assess Privacy Mode alongside those factors rather than treating it as fully local execution.

Cursor reference guide: the AI code editor, modes, rules, pricing, and limits