Cursor Review: Setup, Costs and a Complete Coding Workflow

Cursor is worth evaluating when you want to inspect files, direct an agent and review its edits in the same working environment. For a creator maintaining a website or a freelancer shipping small applications, that arrangement can make the handoff between request and code easier to follow.

The buying answer

• Good fit: someone making frequent changes to an existing project who wants a visible editing and review workflow.
• Starting option: Hobby is free with limited Agent requests; Pro is $20/month.
• Useful capability: an agent that can search, edit and use project tools while you examine the working changes.
• Main weakness: included usage and the work required to verify generated code need separate attention.
• Recommendation: try one complete change on your own repository, including the final browser check, before upgrading. Official pricing, Agent overview.

Two weaknesses to understand first

A larger diff can feel like faster progress while making the result harder to trust. Consider a request to improve a signup form. If the agent redesigns the whole page, replaces validation and changes how subscribers are stored, you now have three decisions to review. The size of the output does not tell you whether any of them were necessary. This is an illustrative review risk, not a hands-on finding about failure frequency.

Cost is another source of misunderstanding. Current documentation describes separate Cursor Models and Other Models usage pools. Selecting a third-party model draws from the latter at that model's API rate. Do not carry forward an old assumption that a particular number of requests describes every paid plan. Models and usage.

The practical response to both problems is a small evaluation with a recorded starting point, clear acceptance criteria and a usage check afterward. That gives you evidence about your own work rather than somebody else's impressive demo.

How the agent finds and changes code

Cursor's Agent can work across files and use tools rather than merely propose a completion at the cursor. A request becomes a sequence of searches, reads, edits and execution results. The editor shows the resulting code, but the underlying reasoning still depends on which evidence reaches the model. Agent documentation.

A current detail matters here: the old codebase-indexing URL now redirects to documentation for search. That page describes Instant Grep building its index locally and says Cursor does not store codebase embeddings for search. File content opened from a match can still enter a model request. Local indexing is therefore not the same claim as local model inference. Current search documentation.

For diagnosis, separate discovery from understanding. The agent may find the right filename and still misread the business rule. Ask it to trace a concrete example through the function and its caller. If a signup is rejected, identify whether the rejection occurred in browser validation, request parsing, a database constraint or the email provider. “The signup code looks correct” is not a useful intermediate result.

Set up the project before buying more usage

Install from the official download page and open the repository you intend to change. Record the current branch and preserve unfinished work. Run the project's normal development command and check once that the application starts. This recommended baseline prevents an installation issue from masquerading as a generated-code bug.

Put durable guidance in a small project rule. Current Cursor rules use .mdc files under .cursor/rules; the docs explicitly say ordinary .md files there are ignored. AGENTS.md is a simpler Markdown alternative. Rules are included as model context when applicable, with automatic, manual and file-scoped choices. Rules format.

For a website, useful guidance might identify the existing button component, the command for the relevant form test and the source of approved marketing copy. “Make everything beautiful and robust” does not settle any implementation question. Keep credentials in the project's established secret-management path rather than pasting them into an example prompt.

The following is an illustrative project-rule body, not executed configuration:

Reuse the existing form and button components.
Preserve approved copy unless the task asks for copy changes.
For newsletter work, test empty, malformed and successful inputs.
Report any check that could not run and why.

Use the rule editor to create its applicable metadata. Do not blindly copy a path pattern from another repository: a rule scoped to src/forms/** will not guide a form living elsewhere.

Worked example: make a newsletter form recover from failure

Assume a creator's newsletter form disables its submit button while a request is running. If the email provider returns an error, the button stays disabled and the visitor cannot retry. The required result is a retryable error state without accidental duplicate submissions. This entire scenario is an original proposed evaluation.

1. Give the agent a state transition

A useful task description names the states: idle, submitting, success and error. Submitting should disable the button. Success should show confirmation. Error should show a useful message and allow another attempt. The input email should survive a recoverable error.

Ask: “Find the newsletter submit handler and trace the error path. Identify where submitting is reset. Explain the smallest change needed for retry, preserving the current design and provider integration. Show the relevant files before editing.”

The intermediate output should point to a missing cleanup branch or an equivalent concrete cause. If the explanation only says “improve error handling,” request the exact transition that is currently absent.

2. Define a controlled failure

Use the existing test setup to make the provider or request boundary return a failure. Do not send repeated test subscriptions to your real audience service. The first check should show the current problem: after a rejected request, the button remains disabled.

Then specify the corrected expectation: the error message appears, the email remains, the button becomes available and a subsequent successful request reaches confirmation. This prevents the easy but wrong “fix” of always enabling the button even while the first request is running.

3. Inspect the proposed patch

A plausible fix might reset loading state in a cleanup block. Whether that is sufficient depends on how the component handles unmounting, cancellation and duplicate requests. Ask the agent to explain which of those concerns actually exists in your code rather than adding abstractions for all of them.

Review both the handler and the test. If the agent deletes the failed-request assertion, the green test no longer represents the requested behavior. If it changes the email provider or introduces a queue, ask what evidence requires that expanded scope.

4. Verify the visible behavior

Run the form in the browser against the controlled failure. Submit by clicking and by pressing Enter. Check that a second attempt works after an error, that repeated clicks during submission do not create multiple requests and that confirmation appears only after success.

For a visual check, inspect narrow-screen layout and keyboard focus. An error message can be technically present but appear below the visible area or move the controls unexpectedly. Preserve screenshots or a short validation note with the change so a collaborator knows what was checked.

The final artifacts should be a focused diff, a meaningful regression test and a brief report of actual commands and outcomes. Cursor's review guidance describes reviewing branch changes and combining checks with human review. It does not make passing tests a guarantee of correctness. Reviewing and testing.

Make the next change easier to review

After the form fix, retain the controlled failure and the short project rule. Those are more useful for the next task than a long transcript of attempted repairs. A future edit that breaks retry behavior should fail the same check, while the rule points the agent toward the existing components.

Cursor recommends focused rules with concrete references and warns against copying entire style guides into them. Apply that advice to a repeated mistake you actually observed. If the agent keeps introducing new buttons, point to the canonical button component. If it already follows the convention, another instruction adds little. Rules guidance.

The vendor's agent-practices article also illustrates establishing expected inputs and outputs before implementation. Keep that principle while using today's documented rule format: .mdc project rules or the supported AGENTS.md alternative. An older example's prose is not a reason to ignore the current format. Published practices.

You can stop when the focused diff, controlled failure and visible retry behavior agree. More generated tests are useful only if they answer a remaining question; a second test that repeats the same mocked assertion does not inspect the visitor's experience.

Pricing: budget for your usage pattern

These are published USD monthly rates checked September 29, 2026, not annual equivalents. The public pricing page verifies Hobby, Pro and Teams; the model documentation lists Pro Plus and Ultra. Check taxes, selected billing cycle and the actual offer at checkout. Plans, Individual tiers.

At those rates, Pro costs $240 over twelve monthly payments, Pro Plus $720 and Ultra $2,400. Moving from Pro to Pro Plus adds $40 per month. At an illustrative value of $40 per working hour, that upgrade needs to recover an additional hour of net productive time monthly. More generated code alone does not meet that test.

For example, standard Composer 2.5 lists $0.50/million input tokens and $2.50/million output tokens. An illustrative 100,000 uncached input plus 20,000 output tokens costs 0.1 × $0.50 + 0.02 × $2.50 = $0.10. This excludes other billing categories and is not a completed-job quote or subscription allowance. Rate table.

The public pricing page says on-demand usage can continue after included usage and is billed afterward. Check your settings and dashboard before using a long unattended task as a trial. Billing explanation.

Local versus cloud work

Cloud Agents execute in their own virtual machines and can continue without your laptop remaining connected. Source-control access must be configured for repository work. This is useful when a task can be reproduced from the repository and its declared environment. Cloud Agents.

For the newsletter example, stay local initially if the provider mock and development environment already work there. Move a task to cloud execution only after documenting how to install dependencies, supply appropriate test credentials and run the same check. Otherwise you may spend the session debugging environment differences instead of the form.

Independent tasks are better candidates for concurrency than multiple agents editing one component. That is our operational recommendation: the review and integration work still lands with you, even when execution happens elsewhere.

Failure diagnosis and alternatives

Compare Claude Code if you prefer directing repository tasks through a terminal or your existing environment. Use Claude chat for occasional explanation when applying a suggested change yourself is acceptable. Pick Cursor when its visible editing and review workflow helps you complete changes you can validate. Skip an upgrade when your bottleneck is unclear requirements, missing tests or unfamiliarity with the application. A higher usage allowance does not resolve those problems.

Frequently asked questions

If you need to understand the control loop behind these tools, the harness engineering guide explains state, recovery and evaluation. Use those mechanisms to assess an agent's behavior across repeated jobs.

Is Cursor Pro unlimited?

Do not interpret it as unlimited agent work. Current documentation describes included usage pools and model-dependent consumption.

Why is my project rule ignored?

Check the extension first: project rules require .mdc. Then check its scope and application mode. A plain Markdown alternative is AGENTS.md.

Does local search keep every interaction on my computer?

No. The search documentation says indexing is local, but opened file content can be sent in a model request.

Do Cloud Agents need my laptop running?

The documented cloud environment runs independently. Your task still needs a reproducible setup and suitable repository access.

Should I subscribe to Cursor and Claude Code together?

Evaluate the same bounded task separately first. Pay for both only if each removes a distinct bottleneck whose value exceeds its cost.