What Cursor AI actually is

Cursor is a code editor built on top of Visual Studio Code. That single fact answers most of the marketing confusion around it. When you install Cursor, you are not getting a separate product that talks to your code. You are getting a fork of VS Code with the AI features baked in at the editor level. Every file you open, every line you highlight, every keystroke you make is visible to the AI layer, and that is what makes the experience feel different from pasting code into a chat window on a separate site.

Under the hood, Cursor sends your code context to large language models, currently supporting OpenAI, Anthropic, and a few other providers depending on your plan. Your code is not used to train the underlying models on the paid tiers, though you should still review the privacy settings before working on anything sensitive. The application is a desktop app available on macOS, Windows, and Linux, and it imports your existing VS Code settings, extensions, and keybindings on first launch.

The two features that define the product are Cmd+K for inline code generation and editing, and Cmd+L for a chat panel that can see your whole project. Everything else flows from those two primitives. Composer is a third mode that lets you edit across multiple files at once, useful for scaffolding new features or doing refactors that touch a directory. If you have used GitHub Copilot, the rough mental model is similar, but Cursor gives you more control over context. You can pull specific files into the prompt, you can reference documentation, and you can ask the model to apply changes directly rather than just suggest them. That last point is the part that actually changes how you work.

Setup and authentication

Download the installer from cursor.com and run it. The first launch will offer to import your VS Code configuration. If you are already a VS Code user, accept the import. Your themes, extensions, keybindings, and snippets will all come across. If you are not a VS Code user, you will get a clean editor with sensible defaults and you can configure things later.

The next step is signing in. Cursor uses its own account system, separate from any LLM provider account you may have. You can sign in with Google, GitHub, or email. After authentication, you will choose a plan. The free tier gives you a limited number of AI completions per month, the Pro tier gives you enough for daily work, and the Business tier adds admin controls and privacy guarantees for teams. Pricing per request varies across the underlying models, but in practice a heavy day of coding on the Pro plan uses a small fraction of your monthly allowance.

Once you are signed in, open the settings panel and look at the Models section. This is where you select which underlying model Cursor uses for each command. Different models have different strengths and different costs, and you can set defaults for chat versus inline edits versus composer. The current version of Cursor supports GPT-4 class models, Claude 3.5 and 3.7 Sonnet, and a few others. A useful starting configuration is Claude for chat and explanation, GPT for generation.

Two settings deserve attention during setup. First, in Privacy, make sure Codebase Indexing is configured the way you want. When enabled, Cursor builds a semantic index of your project so the AI can find relevant code without you pasting it in. This is what makes project-wide questions actually useful. Second, in Features, check whether you want Cursor Tab autocomplete enabled. This is the inline suggestion feature that predicts your next edit rather than the next line. Some people love it, others find the latency distracting. Try both before deciding.

First working example

Let us walk through a real task. Open an empty folder in Cursor, create a file called app.py, and start typing. You will see greyed-out completions appear as you write, those are the Cursor Tab predictions. Press Tab to accept.

Now hit Cmd+K with the file open. A small input box appears inline. Type “write a FastAPI endpoint that takes a JSON body with name and email, validates the email, and returns a greeting”. Cursor will generate the code directly in the file. Press Cmd+Enter to accept the entire block, or use the arrow keys to accept it line by line.

Next, open the chat panel with Cmd+L. Ask “what does this endpoint do and what could go wrong with it?” Cursor will read the file and give you a summary, pointing out that the email validation is a basic regex and will not catch every malformed address. You can then ask it to “add proper email validation using the email-validator library and update the requirements.txt”. It will edit both files.

The third pattern to try is multi-file editing. Hit Cmd+I to open Composer. Tell it “add a pytest file that tests the happy path and the invalid email case”. Composer will create a new test file and wire it up. Run pytest in your terminal and you will see whether the generated tests actually pass. In my experience they pass on the first run most of the time, with the rest needing a quick fix.

This three-step pattern of generate, critique, test is the loop you will repeat for almost every task. The first time you use it, the speed feels wrong, like you skipped a step. That is the point. The AI handles the typing, you handle the judgement.

Key settings that matter

Most users never leave the default settings, which is a mistake because a few of them have an outsized effect on output quality.

Model selection is the biggest lever. In Settings > Models, you can pick different models for chat, inline edit, and composer. Claude 3.5 Sonnet tends to be strong on refactoring and explanation. GPT-4 class models tend to be strong on generation from scratch. Cursor lets you set a default per action type, so a reasonable starting configuration is Claude for chat and explanation, GPT for generation. You can override per-request with the model picker at the top of any panel.

Context window settings control how much of your code gets sent with each request. The default is fine for most files, but when working on a large codebase, you may want to bump the max context size. Be aware that larger context means higher cost per request and sometimes noisier responses, because the model has more irrelevant code to wade through.

Custom rules live in .cursorrules at the root of your project. This is a plain text file where you write instructions the AI will follow for every request in that project. A good starter file in spirit looks like this: “always use type hints in Python, prefer the standard library over external packages, write docstrings for public functions, never use print for debugging”. The current version of Cursor reads this file automatically. Treat it like a code review checklist that the AI enforces.

Ignored files work the same as .gitignore. Cursor will skip any file matching the patterns you list, which matters for keeping generated code, virtual environments, and large data files out of the context.

Tab size, indentation, and language-specific formatting are inherited from VS Code. If your team has an .editorconfig file, Cursor will respect it. Make sure your terminal shell is configured too, since Composer can run commands directly.

Where it shines

Cursor performs best on tasks that involve understanding existing code rather than generating from scratch. “Refactor this function to use async”, “find all the places where this constant is used”, “explain why this test is flaky”, these are the questions where the project-wide context turns the AI from a fancy autocomplete into something genuinely useful.

It is also strong on boilerplate. Scaffolding a new feature, writing the obvious CRUD endpoints, generating test files for existing functions, building out the plumbing for a new microservice. The AI does the typing, you check the output and adjust the design.

Documentation work is another good fit. Cursor can read a function and generate a docstring, or read a module and generate a README draft. The output is rarely publish-ready, but it gets you most of the way there in seconds.

For learning a new codebase, the chat panel is excellent. Open a project you have never seen, ask “what does this repository do and what is the entry point”, and follow up with “trace the request flow from the API route to the database”. You will have a mental model in minutes that would have taken hours of reading.

Where it fails

Cursor struggles with anything that requires running code to verify. It will confidently suggest a fix that does not compile, or import a library that does not exist in your requirements. You still need to run the code and read the error messages.

It is also weak on very large refactors that touch dozens of files. Composer can handle small multi-file changes, but asking it to rename a database column across the entire codebase usually produces partial results that need manual cleanup. A typical enterprise codebase will have edge cases the model simply does not see.

Security-sensitive code is another weak spot. The AI will happily suggest eval, hardcoded secrets, and SQL string concatenation. You cannot trust generated code in security-critical paths without a careful review. This is not a Cursor-specific problem, it is a general LLM limitation, but it shows up constantly in real use.

Long-running tasks also degrade. If you ask the model to implement a complex feature in a single Composer request, the output quality drops sharply in the latter half. The model loses track of the design and starts producing inconsistent code. Breaking the work into smaller Composer requests is almost always better than one large one.

The context window, even when maxed out, is not infinite. On a large monorepo, the AI will sometimes miss relevant files or hallucinate functions that do not exist. The codebase index helps, but it is not a perfect solution. You will see this often in the 50k+ line range.

Finally, Cursor is only as good as your prompts. Vague instructions produce vague output. “Make this better” does nothing. “Refactor this function to use dependency injection and split the validation into a separate function” works. The skill of writing good prompts transfers from one AI tool to the next, but you have to develop it.

Practical workflow pattern

The way most professional developers end up using Cursor looks like this. Open the project, glance at the codebase index status to make sure it is fresh, then start the day with the chat panel open in a side tab.

For each task, the loop is the same. Read the relevant code yourself first, even if briefly, so you know what the AI is working with. Use Cmd+K for inline edits on the file you are already in. Use Cmd+L when you need the AI to see multiple files or answer a question. Use Cmd+I sparingly, only when you genuinely need multi-file changes. Most of your day should be Cmd+K and Cmd+L, with Composer reserved for scaffolding new work