How to Use Cursor in 2026: Composer, Agent, MCP, Rules & Background Agent Guide

Cursor is the AI-first code editor that started as a VS Code fork in 2023 and, by mid-2026, has matured into a standalone agentic IDE shipping its own models, its own Background Agent, a JetBrains plugin, native iOS and Android apps, a headless CLI, and a public BugBot service that reviews pull requests on GitHub. Pricing now spans Free, Pro ($20/month), Pro+ ($60/month), Ultra ($200/month), Business, and Enterprise tiers, all running on a metered usage model where every prompt to a frontier model burns request-equivalent credits. The latest stable build at the time of writing is the 1.x series with Cursor Tab v2, the multi-file Composer / Agent loop, and its own in-house Composer-1 and Sonic models trained for low-latency edits — alongside the usual Anthropic Claude, OpenAI, Google Gemini, and xAI Grok options. This guide walks through installing Cursor, configuring it for a real codebase, using Tab autocomplete, Composer, Agent mode, the new .cursor/rules/ directory format, Cursor MCP, BugBot, the cloud Background Agent, and Cursor Hooks — then shows how to connect the editor to DeployHQ's automated Git deployments so production stays predictable while the agent moves fast.

Why Cursor Matters for Web Developers in 2026

The category Cursor pioneered — the AI-first editor — is now crowded. Cline (open-source agent for VS Code), Aider for atomic Git commits and architect mode, Anthropic's Claude Code terminal agent, the autonomous Devin coding agent, the Warp agentic terminal, and the GPU-accelerated Zed editor all ship credible agent loops, alongside Windsurf and GitHub Copilot. What still distinguishes Cursor for professional web developers in 2026:

• Editor-grade UX, not chat-grade. Cursor is a fork of VS Code that re-renders the editor surface around AI rather than bolting a sidebar onto someone else's IDE. Tab autocomplete, multi-cursor edits, the Composer diff view, and the Agent panel are all first-class — not extensions.
• The deepest model selection in any single editor. Claude Sonnet 4.7, Claude Opus 4.7, GPT-5.5, GPT-4.1, Gemini 2.5 Pro, xAI Grok 4, plus Cursor's own Composer-1 (a fast multi-file edit specialist) and Sonic (its low-latency Tab model). You pick per task; no one model has to be good at everything.
• Background Agent moves work off-machine. A cloud-hosted sandboxed agent reads GitHub issues, opens branches, commits, and drafts pull requests while you sleep. Pair it with Slack or the Cursor mobile app and a backlog item can be a draft PR by the time you sit down.
• BugBot puts AI code review in the PR loop. When BugBot is enabled on a GitHub repo, it inspects every pull request — human-authored or agent-authored — and posts inline comments about regressions, missing error handling, and risky changes before a reviewer gets there.
• Cursor MCP is mature. A real GUI for adding Model Context Protocol servers, plus a ~/.cursor/mcp.json for global servers and .cursor/mcp.json for project-scoped ones. Both stdio and SSE transports work, and the recent Cursor MCP marketplace makes installing third-party servers a click rather than a JSON edit.
• Cursor Rules are now structured. The legacy .cursorrules file still works, but the modern format is .cursor/rules/*.mdc — markdown with YAML frontmatter (description, globs, alwaysApply) so rules can be conditional, file-scoped, and version-controlled per scope. There's also agents.md, the cross-IDE standard rule file Cursor reads as a fallback.

If you've used Cursor before but haven't touched it since 2024, treat this as a fresh setup. The pricing, the rule format, the cloud agent, and the MCP UI have all changed enough to warrant a re-read.

Step 1: System Requirements

Cursor runs as a desktop app on every major OS, plus a mobile app and a cloud-only Background Agent.

Desktop:

• macOS 11 (Big Sur) or later — Apple Silicon and Intel both supported
• Windows 10 or 11
• Linux — Ubuntu 20.04+, Fedora 38+, Debian 11+, or the universal AppImage on other distributions

Hardware:

• 8 GB RAM minimum, 16 GB recommended for large monorepo indexing
• SSD strongly recommended — Cursor builds local embeddings of your codebase and that I/O matters
• 2 GB free disk for the application; an indexed monorepo can add another 1–3 GB depending on size

JetBrains plugin (GA in 2026): IntelliJ IDEA, PyCharm, WebStorm, GoLand, RubyMine, and PhpStorm 2024.2 or later. The plugin replicates Tab, Inline Edit, Chat, and Composer — Background Agent and BugBot run server-side so they're identical regardless of host IDE.

Mobile: the iOS and Android apps support chat with the Background Agent and surfacing of cloud-agent results — no editing surface.

Cursor CLI: Node.js 18+ if you install the headless CLI for CI use. The CLI is suitable for cron jobs and scripted code edits, and it shares MCP servers, rules, and authentication with the desktop app.

Network: an outbound HTTPS connection is required for cloud models. If you exclusively use a local Ollama or LM Studio model the editor still phones home for telemetry by default — you can opt out in Settings → Privacy with Privacy Mode.

Step 2: Install Cursor

Installation is the same shape as installing VS Code.

Desktop install

1. Visit cursor.com and download the build for your OS
2. Run the installer:
   • macOS — drag Cursor.app into /Applications
   • Windows — run the .exe and accept the wizard
   • Linux .deb / .rpm — sudo dpkg -i cursor_*.deb or sudo rpm -i cursor_*.rpm
   • Linux AppImage — chmod +x cursor-*.AppImage && ./cursor-*.AppImage
3. Launch Cursor

Importing your VS Code setup

The first-launch flow asks two questions worth getting right:

1. Import from VS Code — yes, almost always. Cursor copies your installed extensions, themes, keybindings, and settings.json. Anything that doesn't carry over (a vanishingly small list of marketplace-restricted extensions) shows up flagged.
2. Keyboard layout — pick VS Code unless you're a long-time Vim/Emacs user, in which case install the Vim or VSpaceCode extension after import.

You can run Cursor and VS Code side by side with separate user-data directories — they don't conflict. Many developers keep VS Code for plain text editing and Markdown, and Cursor for code that needs the AI surface.

Cursor for JetBrains

In your JetBrains IDE: Settings → Plugins → Marketplace, search for "Cursor", install, restart. The Cursor tool window appears in the right sidebar. Sign in with your existing Cursor account and the same models, rules, and MCP servers become available — there's nothing to reconfigure.

Cursor CLI

The CLI is in stable release on macOS, Linux, and (as of 2026) Windows:

npm install -g @cursor/cli
cursor auth          # opens a browser to sign in
cursor               # interactive session in the current directory
cursor --headless "fix the failing tests in src/auth/" --branch fix/auth

The CLI is the right tool for CI jobs that want a Cursor agent to fix a regression as part of the pipeline, or for shell-scripted bulk edits across many repos. It honours the same .cursor/rules/, MCP servers, and account credits as the desktop editor.

Verify install

Launch Cursor, open a project (File → Open Folder), and watch the bottom status bar — once "Indexed" stops blinking, the local embeddings are ready and Tab will be project-aware.

Step 3: Choose Your Plan

Cursor's pricing changed materially in 2025 and again in 2026. The current tiers:

The metered model is the part everyone needs to understand. Each request to a frontier model is priced in request equivalents based on the model's input/output cost — Claude Opus 4.7 burns credits roughly 5× faster than Sonnet 4.7, Composer-1 sits below Sonnet, and Cursor's Sonic (used by Tab) is effectively free within plan limits. There is no separate "fast request quota" any more — that was the legacy 500-fast-request system, which Cursor retired in favour of dollar-denominated metering. If you remember the old model and are searching for "cursor 500 fast requests", that limit no longer exists; you have a dollar budget and a real-time meter in Settings → Billing.

BugBot is priced separately at $40/user/month for unlimited PR reviews — there's a free tier for hobbyists.

Background Agent runs on top of your plan's metered spend, billed identically to Composer/Agent runs in the editor.

For most working web developers the Pro plan covers normal day-to-day work. If you live in Composer for hours daily, Ultra is the calmer tier — the meter doesn't keep you up at night.

Sign in

Click the gear icon → Account → sign in with email, Google, or GitHub. Subscriptions follow the account, not the machine, and a single account works across desktop, JetBrains plugin, CLI, and the mobile app.

Step 4: Configure Cursor for Your Workflow

Before opening Composer for the first time, spend ten minutes on configuration. It pays back across every later session.

Pick your default models

Settings → Models lists every available model, grouped by provider. The current shortlist:

• Cursor Sonic — the Tab model. Sub-100ms latency, predicts multi-line edits, free within plan limits. Always on for Tab.
• Cursor Composer-1 — Cursor's own multi-file edit specialist. Cheaper than frontier Claude/GPT, fast, surprisingly competent for routine refactors and feature scaffolding.
• Claude Sonnet 4.7 — the strong default for Chat, Inline Edit, and Composer. Best balance of cost, quality, and tool-use reliability.
• Claude Opus 4.7 — switch to this for architectural decisions, hard debugging, and any task that needs careful reasoning. ~5× the cost per request.
• GPT-5.5 — strong alternative to Sonnet 4.7, particularly good with structured output (JSON schemas, type definitions). Often slightly faster.
• GPT-4.1 — the previous-generation OpenAI model, still useful for cost-sensitive work.
• Gemini 2.5 Pro — the largest context window of the bunch (up to 2M tokens). Use it when you need to feed an entire monorepo into one prompt.
• xAI Grok 4 — strong for code-with-current-data tasks (web searches built in).

A reasonable default policy: Sonic for Tab, Composer-1 for routine Composer edits, Sonnet 4.7 for Chat, Opus 4.7 reserved for the genuinely hard problems. Cursor remembers per-feature defaults so you don't have to switch manually every time.

Set up your .cursor/rules/ directory

This is the modern rule format and it's a meaningful upgrade over the old .cursorrules single file. See Step 6 for the full breakdown — for setup, just create the directory:

mkdir -p .cursor/rules

A first sensible rule, .cursor/rules/000-project.mdc:

---
description: Project-wide standards
alwaysApply: true
---

- This is a TypeScript Next.js application using App Router
- Use server components by default; mark client components with "use client"
- Tailwind CSS for styling, shadcn/ui for primitives
- Drizzle ORM for the Postgres database
- Vitest for tests; co-locate `*.test.ts` next to source files
- Never use `any` — prefer `unknown` and narrow with type guards

Commit .cursor/rules/ to Git. Every developer on the team gets the same agent behaviour.

Configure MCP servers

Settings → MCP is the GUI; under the hood, MCP configuration lives in two files:

• Global: ~/.cursor/mcp.json (or %USERPROFILE%\.cursor\mcp.json on Windows)
• Project-local: .cursor/mcp.json at the workspace root, checked into Git

A typical project-local config might look like:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://localhost/myapp_dev"
      }
    },
    "linear": {
      "url": "https://mcp.linear.app/sse",
      "transport": "sse"
    },
    "sentry": {
      "command": "npx",
      "args": ["-y", "@sentry/mcp-server"],
      "env": { "SENTRY_AUTH_TOKEN": "${SENTRY_AUTH_TOKEN}" }
    }
  }
}

Two transports are supported: stdio (a local process — command + args) and SSE (a remote URL — url + transport: "sse"). Project-local servers override globals with the same name. After a config change, hit Reload MCP servers in Settings → MCP.

For the practical, opinionated list of which MCP servers actually pay back the setup cost, the best MCP servers for web developers writeup covers the current top picks.

Index your codebase

Cursor builds a vector index of your project on first open. Watch the Indexing indicator in the status bar — it can take a couple of minutes for a 100k-line repo. The index is what makes Tab and Composer feel like they "know" your code.

Two adjustments worth making in Settings → Indexing & Docs:

1. Add documentation sources — paste URLs for your framework's docs (Next.js, Drizzle, Tailwind, your internal SDK). Cursor crawls and indexes them so Chat can @ them.
2. Exclude noisy directories — node_modules, dist, .next, vendor, generated migrations. Less noise, faster indexing, sharper recall.

Privacy Mode

If you're working on regulated code, enable Settings → Privacy → Privacy Mode. This guarantees no prompts, completions, or file content are stored server-side beyond the duration of the request — no model training, no logs. The trade-off is that some features that depend on cached state (like resuming a long Composer session after a network blip) become more fragile.

Step 5: Cursor Tab — Multi-Line Predictive Editing

Tab is Cursor's headline feature and the single most-used surface in the editor. It runs on Cursor Sonic, the in-house low-latency model, and predicts what you'll type next — not just on the current line, but multi-line edits and even your next cursor position.

How Tab works in practice

Type normally. Cursor shows a ghost-text suggestion. Press Tab to accept the entire suggestion in one keystroke, Esc to dismiss. If the suggestion is multi-line, you get a side-by-side diff view so you see exactly what's changing.

The model uses three signals beyond the visible code:

• Recent edits in adjacent files — Tab knows you just renamed a function and proposes the matching renames elsewhere
• The file's local context — the imports, the surrounding scope, the types
• The project index — patterns from sibling files; how you tend to write tests, how you tend to handle errors

Cursor publishes Tab acceptance metrics: roughly 28% higher acceptance with 21% fewer suggestions than the legacy single-line autocomplete. The headline number isn't the acceptance rate — it's that Tab learns to suggest less, so the suggestions you do see are worth keeping.

Tab patterns that work

• Refactor by example. Rename one usage, and Tab finds the rest.
• Mirror edits across files. Add a column to a Drizzle schema; Tab proposes the matching changes to the seed file and the validation schema.
• Write tests by writing the assertion first. Type the expect(...) and let Tab fill in the setup.

When to turn Tab off

For very small, complex changes where you want full deliberate control — a tricky security check, a fragile migration, a hand-tuned algorithm — pressing Esc repeatedly gets old. Disable Tab temporarily with Cmd/Ctrl+Shift+P → Cursor: Toggle Tab, then re-enable when you're back to routine work.

Step 6: Cursor Rules in 2026 — .cursor/rules/*.mdc

Cursor Rules tell the agent how your project should be coded. They are markdown files Cursor injects into the system prompt before every interaction. The 2026 format is structured: rules live in .cursor/rules/, each with YAML frontmatter that controls when they apply.

The rule file format

---
description: API security rules
globs:
  - "src/api/**/*.ts"
  - "src/server/**/*.ts"
alwaysApply: false
---

- Validate every request body with Zod before any DB access
- Never log full request bodies in production
- All endpoints under /api/v1 require JWT auth except /auth/login and /auth/register
- Return a typed error envelope: `{ error: { code, message } }` — never plain strings

Three frontmatter keys do the work:

When alwaysApply: false and globs are set, the rule only loads when the current chat references files matching one of the globs. This is what lets you keep ten or twenty specific rules in .cursor/rules/ without ballooning the system prompt — irrelevant rules don't load.

Recommended rule layout

A reasonable convention for a Next.js + TypeScript + Postgres project:

.cursor/rules/
├── 000-project.mdc          # alwaysApply, project overview
├── 100-typescript.mdc       # globs: **/*.ts, **/*.tsx
├── 110-react.mdc            # globs: **/*.tsx
├── 200-api-security.mdc     # globs: src/api/**, src/server/**
├── 300-database.mdc         # globs: src/db/**, drizzle/**
├── 400-tests.mdc            # globs: **/*.test.ts
└── 900-style.mdc            # globs: **/*.{ts,tsx,css}

Number prefixes give you control over the order rules are concatenated into the prompt — earlier rules take precedence on conflicts, the same way before_action filters layer in Rails or middleware stacks layer in Express.

Legacy .cursorrules and agents.md

Cursor still reads three other rule sources for compatibility:

• .cursorrules — the original single-file format. Kept for backwards compatibility; new projects should use .cursor/rules/.
• agents.md at the project root — the cross-IDE standard adopted by Cline, Cursor, GitHub Copilot, Claude Code, and most agentic tools. Project-wide rules in agents.md are read by every compatible agent, which is the right choice for shared standards on multi-tool teams.
• User-global rules — set in Cursor Settings → Rules → User. Applied to every project on this machine. Useful for personal preferences ("always use semicolons", "prefer arrow functions") that shouldn't be on the team's repo.

When all four sources contain rules, project rules win over user rules, and explicit globs matches win over alwaysApply: true. Test the precedence by opening Cursor: Show Active Rules from the command palette — it lists exactly which rules loaded for the current context.

For a deeper comparison of .cursorrules, agents.md, CLAUDE.md, and copilot-instructions.md across the wider AI-coding-tool ecosystem, the AI coding config files guide and the related writeup on how to write effective AI coding agent instructions cover the cross-IDE picture.

Step 7: Composer, Inline Edit, and Agent Mode

Cursor exposes three AI surfaces for actually editing code, each with a different shape.

Inline Edit (Cmd/Ctrl + K)

The smallest surface. Highlight a function (or place the cursor where you want a change), press Cmd+K, type a one-sentence instruction, accept the diff. Examples:

Add error handling for network failures
Convert this to async/await with proper cancellation
Add Zod validation for the request body
Refactor this into smaller helper functions

Inline Edit is the fastest way to apply a focused change. It runs on Sonnet 4.7 by default (configurable), shows you a diff, and only writes after you accept.

Chat (Cmd/Ctrl + L)

Chat is for questions and conversations — "explain this code", "why is this failing", "what would happen if I changed X". Chat can read files via @file mentions, search the project semantically, and call MCP tools, but it doesn't edit code by default. Press Apply on a code suggestion in the chat to turn it into an Inline Edit.

@ mentions in Chat give you precise scope control:

Composer (Cmd/Ctrl + I)

Composer is the multi-file edit surface. Open it, describe a feature in a few sentences, and Composer:

1. Reads the relevant files (declared in the prompt with @, or discovered via project index)
2. Identifies which files need changing and which need creating
3. Proposes diffs across all of them, in one review surface
4. Applies your accepted changes atomically

The diff view is Composer's superpower — you see every file that changes in one place, accept or reject each diff individually, and ship coherent multi-file features without hand-orchestrating the edits. Example prompt:

Add a user profile page at /profile that shows the user's order history
and a "cancel order" button for orders within 24 hours of placement.
Include:
- a server component that loads orders
- a client component with the cancel handler
- a server action for cancellation
- proper authorization (only owner can cancel)
- a Vitest test for the server action

Composer reads @app/, @src/db/, @src/auth/, scaffolds the new route, the components, the action, the test, and presents one consolidated review.

Agent mode

Agent extends Composer with autonomy. Instead of stopping after producing diffs, the agent can:

• Run terminal commands (with approval gates configurable per command)
• Read command output and react to it
• Run tests, parse failures, propose fixes, iterate
• Call MCP tools (query the database, post to Linear, fetch a Sentry stack trace)
• Loop until the task is genuinely done — green tests, type-check passing, lint clean

Toggle Agent in the Composer panel. Agent mode is more expensive than plain Composer because it makes more model calls, and it's the right tool for tasks that don't have an obvious end state in advance: "implement the migration, run it against the dev database, fix any errors, then run the test suite and fix failures until it's green".

A practical guardrail: enable Settings → Agent → Require approval for destructive commands, which forces a click-through on rm -rf, DROP TABLE, git push --force, and similar. Tests, builds, and read-only queries auto-approve.

Step 8: Background Agent — Cursor in the Cloud

Background Agent is Cursor's cloud-hosted asynchronous agent, introduced in 2025 and significantly expanded in 2026. It runs in a sandboxed cloud VM, has its own ephemeral checkout of your repo, and can take a GitHub issue or a Slack message and turn it into a draft pull request without your laptop being open.

What it can do

• Read a GitHub issue, branch, implement, push, and open a PR
• Pick up Slack messages addressed to it and respond with code changes
• Run from your phone — describe a fix in the Cursor mobile app, get a PR before you're at your desk
• Hand off long-running tasks from your editor when you switch contexts
• Act on a schedule (cron-style) for routine maintenance — dependency bumps, lint sweeps

Setup

1. Settings → Background Agent → Connect GitHub. Cursor installs a GitHub App with read/write access to repos you select.
2. Choose a base image. Cursor provides Ubuntu LTS images with Node, Python, Go, and Ruby pre-installed; for stranger toolchains, you provide a Dockerfile and Cursor builds the agent's environment from it.
3. Set environment variables and secrets. Cursor encrypts these and injects them at runtime — never visible in agent output or logs.
4. (Optional) Connect Slack. A Cursor Slack app lets you @cursor fix the failing test in src/checkout/... from any channel.

A real Background Agent loop

You file a GitHub issue: "Search results page returns 500 when query string contains a NUL byte. Sentry trace: ..." and tag @cursor. Within minutes:

1. Background Agent picks up the issue
2. Spins up a sandbox, clones the repo, checks out a fresh branch
3. Reads the linked Sentry trace, identifies the unsanitised input
4. Adds a Zod check, writes a test reproducing the NUL-byte case, runs the suite
5. Commits, pushes, opens a PR titled "fix: handle NUL bytes in search query string"
6. Tags you for review and posts a Slack notification

You review on your phone or laptop, request changes, the agent iterates. When you're happy, DeployHQ deploys the merged branch and you're done — without ever leaving Slack.

When Background Agent is and isn't a good fit

Good fit: - Reproducible, contained bugs with clear acceptance criteria - Dependency upgrades and version bumps - Routine refactors ("convert these class components to function components") - Test coverage gaps ("add tests for the auth middleware") - Documentation tasks ("update the README with the new env vars")

Bad fit: - Anything requiring product judgment ("design the new dashboard") - Tasks that touch infrastructure outside the repo - Work where the test suite is unreliable — the agent will iterate forever trying to make flaky tests green - Anything where wrong code in production is dangerous and review can't be trusted to catch it

Background Agent uses the same metered spend as in-editor Composer, so a runaway loop on a flaky test suite can burn meaningful budget. Set a per-task spend cap in Settings → Background Agent → Spend Limits.

Step 9: BugBot, Hooks, and the Cloud Surface

A handful of features deserve their own callouts because they materially change the workflow shape.

BugBot — automated PR review

BugBot is the GitHub-side companion to Cursor in the editor. Once installed (a one-click GitHub App), it reviews every pull request — human or agent — and posts inline comments about:

• Likely bugs and regressions
• Missing error handling
• Unsanitised inputs
• Race conditions
• Deviations from your .cursor/rules/
• Test gaps for the changed code paths

It runs the same models as the editor; you choose Sonnet 4.7, GPT-5.5, or another model in the BugBot settings. Comments arrive within a couple of minutes of the PR opening, ahead of any human reviewer, and BugBot's verdict is non-blocking by default — it advises, you decide.

BugBot pricing is separate from Cursor's editor plans: $40/user/month for unlimited repo reviews on Pro, with custom Enterprise terms. There's a free tier for public repos and individual hobby use.

Cursor Hooks — local automation triggers

Cursor Hooks (introduced 2026) are scripts you wire to specific editor events:

• onPreEdit — runs before Composer applies changes; can veto an edit
• onPostEdit — runs after Composer commits the change to disk
• onPreCommit — runs before the agent stages a Git commit
• onApprove — runs when you click Approve on a Composer diff

Hooks are bash, Node, or Python scripts in .cursor/hooks/. Use cases:

• Block edits to files in infra/production/ unless a special flag is set
• Auto-format every Composer-applied file with Prettier or ruff before saving
• Run tsc --noEmit after every edit and surface errors back to the agent
• Send a Slack notification when the agent commits to main

Hooks bridge the gap between the editor's AI surface and your existing developer tooling — they let you keep the agent inside the same guardrails you'd impose on a human teammate.

The Cursor mobile and web app

The Cursor iOS and Android apps surface Background Agent results, let you chat with the agent from anywhere, and approve PR drafts on your phone. The companion cursor.com/app web UI does the same from any browser. None of these surfaces support direct file editing — they're for monitoring, approving, and queuing work, not for coding away from the desktop.

Step 10: Best Practices for Effective Use

A handful of patterns separate developers who feel productive in Cursor from those who feel frustrated.

Lead with rules, not prompts

If you find yourself typing the same instruction three times in three sessions, it belongs in .cursor/rules/. The agent's defaults plus your project's specifics should let you describe what you want without re-stating how you want it every time.

Use @ mentions for scope control

Instead of "fix the auth bug", try @file:src/middleware/auth.ts @file:src/routes/api.ts followed by the description. Specific is cheaper (fewer tokens), faster (less search), and more accurate (no guessing which file you meant).

Pick the model per task

• Sonic for Tab — always
• Composer-1 or Sonnet 4.7 for routine multi-file edits
• Opus 4.7 or GPT-5.5 for hard reasoning, architectural choices, gnarly bugs
• Gemini 2.5 Pro when you genuinely need a multi-million-token context (full monorepo summarisation, large legacy refactors)

The default policy is to keep cheaper models on the wheel and reach for the expensive ones when they pay back the cost.

Review every diff

AI-generated code passes type-checks and tests at a high rate, but "passes the tests" is a low bar. Things to check on every Composer or Agent diff:

• Imports — right paths, no surprise dependencies, no unused imports
• Error handling — catching specific exceptions, returning typed errors, no swallowed catches
• Naming — matches your project conventions
• Side effects — did the edit touch files you didn't expect?
• Tests — does the new test actually exercise the new behaviour, or does it just type-check?

Cursor's diff view makes this fast; treat the review as you'd treat a teammate's PR.

Use Composer-1 for cost discipline

Cursor's own Composer-1 is materially cheaper than frontier Claude/GPT and competitive on routine multi-file edits. For a typical "scaffold this feature" task it's the right default — reach for Sonnet or Opus when the routine fails. Many developers cut their monthly Cursor spend by 40–60% by switching the Composer default from Sonnet to Composer-1 and reserving Sonnet for genuinely complex tasks.

Branch every meaningful Composer session

Cursor doesn't have its own undo-the-AI-changes layer — it relies on Git. Run every non-trivial Composer or Agent session on a feature branch:

git checkout -b feat/profile-page
# ... Composer session ...
git diff main..HEAD     # review the full set of changes

Combined with DeployHQ's atomic file transfers and instant rollback to a prior release, the cost of a Composer session that goes sideways is roughly zero — abandon the branch, start over.

Step 11: Pair Cursor with DeployHQ for Git-to-Production

Cursor writes the code; DeployHQ ships it. The boundary is clean: Cursor owns local edit/test/debug and (via Background Agent) cloud agent work; DeployHQ owns the build pipeline, the file transfer, the cutover, and the rollback.

A complete Cursor → DeployHQ workflow

1. Open Composer with the feature description

Add email notifications when an order ships. Include:
- the mailer template (HTML and text variants)
- a background job using BullMQ
- a hook in OrderService.markAsShipped() that enqueues the job
- Vitest tests for the job and the service hook
- update the README with the new SMTP env vars

Reference @file:src/services/order.ts and @file:src/jobs/index.ts.

2. Cursor implements across files

Composer reads the referenced files, scaffolds the mailer, the job, the service change, and the tests. You see one consolidated diff covering six files.

3. Review and refine

Walk through each diff. Reject the test that's testing the wrong thing; ask Composer to rewrite it ("the test should verify the email contains the order number, not just that send() was called"). Accept the rest.

4. Run the suite locally

Cursor wants to run: pnpm test
[Approve] [Reject]

Approve. Tests pass. If they fail, Composer reads the error, proposes a fix, you approve, the loop continues until green.

5. Commit and push

git checkout -b feat/shipping-notifications
git add -A
git commit -m "Add shipping notification emails with BullMQ job"
git push origin feat/shipping-notifications

If you've enabled the Cursor Git integration, the same flow runs from the editor's source control panel.

6. DeployHQ deploys

With your DeployHQ project configured for automatic deployments on merge to main:

• DeployHQ pulls from your repository (deploy from GitHub to your servers, deploy from GitLab to your servers, Bitbucket, or self-hosted Git)
• Runs your server-side build pipeline (pnpm install --frozen-lockfile, pnpm build, asset hashing)
• Transfers files atomically via SFTP, SSH, or your cloud target — old release keeps serving traffic until the new release is fully staged
• Cuts over with zero-downtime deployments
• Keeps every deployment versioned so a single click rolls back to the previous release if anything goes wrong

The full feature flow — from "write me an email job" to live in production — runs in the time it takes to drink a coffee, and every step is auditable.

Pair Background Agent with DeployHQ for end-to-end automation

The pairing gets stronger when you combine Background Agent and DeployHQ. The shape:

1. A bug report lands as a GitHub issue, tagged @cursor
2. Background Agent investigates, fixes, opens a PR
3. BugBot reviews the PR and posts inline comments
4. A human reviewer signs off and merges
5. DeployHQ deploys to production automatically

Nothing in this loop requires you to be at a keyboard during steps 2–5. For a deeper exploration of how AI agents fit inside CI/CD specifically, the agentic workflows in CI/CD pipelines writeup and the practical walkthrough on AI agents from GitHub issue to production deploy cover the architectural choices.

Why the editor/deployer split matters

• Auditability — Git history shows what Cursor changed; DeployHQ's deploy log shows what shipped and when. Two sources of truth, neither dependent on the other.
• Rollback safety — DeployHQ rolls back to any previous deployment independently of Cursor's involvement. AI-generated code is no harder to reverse than human-generated code.
• Team mixing — half the team can use Cursor, the other half VS Code with Cline, the rest the JetBrains plugin or the CLI. The deploy pipeline doesn't care which editor produced the diff.
• Build pipeline isolation — DeployHQ's build commands run server-side, isolated from whatever happened on the developer's machine. Composer-generated package.json changes get a clean pnpm install rather than relying on local lockfile state.

Setting up DeployHQ for Cursor projects

If you don't have DeployHQ wired up:

1. Create a free DeployHQ account
2. Connect your Git host — GitHub, GitLab, Bitbucket, or any self-hosted Git
3. Configure your server connection — SSH, SFTP, or a supported cloud provider
4. Set your build commands. For a Next.js project:

pnpm install --frozen-lockfile
pnpm build

1. Enable automatic deployments on main (or whatever your deployment branch is)
2. Push from Cursor; DeployHQ picks up the change and deploys

The whole setup takes about ten minutes. From then on, every PR Cursor merges into your deployment branch ships automatically.

Step 12: Troubleshooting

"Slow indexing" or "Tab feels stale"

Large monorepos take time to index. Watch the Indexed indicator in the status bar; until it's solid green, Tab and Composer have a partial picture. Speed it up by excluding node_modules, .next, dist, vendor, target, and any large binary asset directories in Settings → Indexing → Exclude patterns.

"Composer is making bad suggestions"

Almost always one of three things:

• Insufficient rules. The agent doesn't know your conventions. Add rules in .cursor/rules/.
• Insufficient context in the prompt. Use @file and @code to point Composer at the canonical examples.
• Wrong model for the task. Composer-1 and Sonnet 4.7 are great defaults for routine work; switch to Opus 4.7 or GPT-5.5 when the task is genuinely complex.

"MCP server won't connect"

In Settings → MCP → [server name] → Logs, check the stderr output. Common causes:

• The command is wrong or not on $PATH — use absolute paths in ~/.cursor/mcp.json
• Required environment variables aren't set — Cursor inherits the IDE's environment, which may differ from your interactive shell
• For SSE transport, the URL is unreachable — curl -sI <url> to confirm
• The MCP server itself crashed — run the command manually in a terminal to reproduce

"Hit my spend limit"

The legacy "500 fast requests" limit no longer applies. The modern limit is dollar-denominated and visible in real time at Settings → Billing. If you're consistently hitting it:

• Switch routine Composer work from Sonnet to Composer-1 (40–60% cost reduction)
• Use Plan-style chat conversations before invoking Composer — refining the approach in chat is much cheaper than rejecting Composer outputs
• Move to Pro+ ($60) or Ultra ($200) if your usage genuinely warrants it
• Be ruthless with @file scope — generic prompts cause expensive whole-codebase exploration

"Tab is suggesting things from the wrong file"

The local index has gone stale. Cmd/Ctrl+Shift+P → Cursor: Re-index workspace rebuilds it from scratch. If the problem persists across re-indexes, check that the file you'd expect Tab to mirror is actually in the indexed set (excluded directories don't get suggestions).

"Background Agent didn't pick up my issue"

Confirm in Settings → Background Agent:

• The repo is in the connected GitHub App's allowed list
• The issue body actually contains @cursor (case-insensitive)
• The base image / Dockerfile build succeeded — check the agent's runtime log for build failures
• Background Agent isn't paused (a paused agent shows a yellow banner in the dashboard)

"BugBot isn't commenting on my PRs"

Check the BugBot dashboard for the repo:

• Confirm the GitHub App has write access (it needs to post comments)
• Check that the PR's base branch matches BugBot's configured branch filter — BugBot only reviews PRs targeting branches you've enabled
• For huge PRs (>500 changed lines), BugBot may take longer; the dashboard shows queued reviews

"Cursor and VS Code keep asking me to install the same extensions"

They use separate user-data directories on purpose. To share extensions, point Cursor at VS Code's directory — but expect the occasional conflict when an extension uses a Cursor-specific API. Most teams keep them separate.

Frequently Asked Questions

Is Cursor free?

Yes — there's a Hobby tier at $0 with limited Tab and a small monthly chat allowance. For serious daily use, Pro at $20/month is the typical entry point. The Hobby tier is enough to evaluate the editor; you'll feel the limits within a couple of weeks of real work.

Cursor vs Cline — which should I use?

The Cline AI coding agent is an open-source extension that adds an agent to standard VS Code, JetBrains, Cursor, Windsurf, Zed, and Neovim. Cursor is a standalone editor with deep AI integration baked in. Use Cline if you want to keep your existing editor and audit the agent's source. Use Cursor if you want the most polished AI-native UX and don't mind running a separate IDE. Many developers run both — Cursor for greenfield work and Cline inside Cursor itself for the moments when an open-source agent is preferable.

Cursor vs Windsurf — which is better?

The Windsurf AI editor with Cascade agent ships its Cascade agent with a similar shape to Cursor's Composer/Agent. The differentiation in 2026 is mainly model selection and pricing — Cursor has more frontier model options (including its own Composer-1 and Sonic), Windsurf leans on Anthropic and OpenAI. UX-wise both are VS Code forks with custom AI surfaces; you'll get used to either one quickly. Try both on the free tier for a week.

Cursor vs GitHub Copilot — do I need both?

The GitHub Copilot AI coding assistant is excellent at single-line autocomplete and at conversational Chat inside any IDE. Cursor's Tab is broadly competitive on autocomplete and significantly ahead on multi-file Composer/Agent workflows. If you only use AI for line-level completion, Copilot at $10/month is cheaper. If you want the agent loop — read codebase, plan changes, edit multiple files, run tests — Cursor's the better choice. Some teams run both: Copilot for completion in JetBrains, Cursor for Composer in VS Code-style work.

What's the difference between Composer and Agent mode in Cursor?

Composer scaffolds a multi-file change in one pass — read, propose, diff, apply. Agent extends that with autonomy: it can run terminal commands, read the output, react to errors, and iterate until tests pass. Composer is the right tool when you know what should change and want the agent to apply it consistently. Agent is the right tool when you want the model to figure out whether the change worked and fix it if not.

How does Cursor MCP work?

Cursor implements the Model Context Protocol — an open standard for connecting agents to external tools. Configure servers in Settings → MCP or directly in ~/.cursor/mcp.json (global) or .cursor/mcp.json (project). Both stdio (local processes) and SSE (remote URLs) transports work. Once configured, Composer and Agent can call MCP tools — query a Postgres database, fetch a Sentry trace, post to Linear, look up a doc — without you copy-pasting context.

What's the modern format for Cursor Rules?

Use .cursor/rules/*.mdc — markdown files with YAML frontmatter (description, globs, alwaysApply). The legacy single-file .cursorrules still works for compatibility, and agents.md at the project root is also read as a cross-IDE fallback. New projects should use .cursor/rules/ because the conditional, file-scoped loading keeps the system prompt small as your rule set grows.

Does Cursor work offline?

Mostly no. Tab, Composer, Agent, and Chat all call cloud models. The exception is if you configure Cursor with a local Ollama or LM Studio model — then everything except Background Agent and BugBot runs on your machine. Local models are fine for simple completion but materially weaker on multi-file Composer work; for most professional use the network dependency is real.

Conclusion

The Cursor that exists in 2026 is meaningfully different from the editor that launched in 2023. Tab has matured into the strongest predictive autocomplete shipping in any editor. Composer and Agent have absorbed multi-file feature scaffolding as a routine task. The new .cursor/rules/ format turns AI behaviour into version-controlled, file-scoped configuration. Cursor MCP makes integrating databases, observability, and internal tools a one-time setup. Background Agent moves work off-machine entirely — a GitHub issue can be a draft PR by the time you sit down. BugBot adds AI code review to every pull request. Cursor Hooks give you scriptable guardrails around the agent's edits. The JetBrains plugin and the mobile/web apps mean the same agent works wherever you are.

For developers running serious deployment workflows, pairing Cursor with DeployHQ is the natural shape: Cursor handles the smart-editor side (writing code, refactoring across files, fixing bugs, automating PR review), while DeployHQ handles production — running build pipelines, executing atomic file transfers, cutting over with zero downtime, and supporting one-click rollback when something does go wrong.

Connect your repository to DeployHQ and let Cursor handle the editing while DeployHQ handles the shipping.

If you have questions about integrating Cursor into your deployment workflow, reach out at support@deployhq.com or find us on Twitter/X at @deployhq.