Cursor AI: what it is, how to use it and what it costs

Cursor AI is a code editor where the AI works inside your project rather than in a separate chat window: it reads files, edits several places at once, runs commands and checks what broke. On the surface it is a familiar editor; underneath it is a workplace where part of the work is done by an agent.

Russian-language search asks three things about it above all: how to use it, what it costs, and whether you can pay for it from Russia. Below are answers to all three, plus what reviews usually leave out: what happens to your company's code once you hand it to a tool like this, and what controlled measurements of working speed actually show.

What is Cursor AI in plain terms?

In short: a code editor with a built-in AI agent that completes whole tasks instead of suggesting the next line.

The official definition reads:

«Cursor is a coding agent for building ambitious software» — Cursor documentation.

The difference from an ordinary editor is simpler than it sounds. In an ordinary one you write code by hand and the editor helps with highlighting and autocomplete. In Cursor you state the task in words — "add an order export to Excel", "fix the failing test", "explain what this module does" — and the agent finds the right files itself, edits them, runs commands and shows you the result.

The broader approach, where software is written in words, is covered separately — what vibe coding is and why it matters for business. Cursor is the most popular tool in that picture, and usually the one through which businesses first meet the approach: 11,800 searches a month in Russian search go to it alone.

One detail matters for anyone already working in VS Code: Cursor is built on its codebase. The migration documentation says so word for word — «Cursor is based upon the VS Code codebase». In other words, this is a standalone program, not a plugin for someone else's editor — with the same interface logic, its own extensions, and settings that transfer with a single click.

How does Cursor differ from an ordinary editor and from a chatbot?

In short: a chatbot answers in text, autocomplete finishes a line, Cursor completes a task and checks itself.

The practical difference shows in a simple example. "Fix the bug in the report" in a browser chat turns into a correspondence: show the code, show the error, try this, no, now something else is failing. The same request in Cursor is one sentence, after which the agent looks for the cause in the files itself, fixes it, reruns the check and comes back with a result.

The main risk worth remembering from day one grows out of the same thing. The agent stops when the work looks done. It has no sense of responsibility for the outcome — only the signals you gave it: tests, project rules, your sign-off. With no signals, the only criterion left is "looks about right".

How work in Cursor is organised: Tab, the agent and rules

In short: three modes — smart autocomplete, an agent for whole tasks, and project rules that set the agent's boundaries.

Tab — autocomplete that sees the context. The documentation describes it this way: "Tab is Cursor's AI-powered autocomplete. It suggests code as you type, drawing on your recent edits, the surrounding code and linter errors." Unlike classic autocomplete, it changes several lines at once, adds missing imports and proposes consistent edits in related places. Once a suggestion is accepted, pressing Tab again jumps to wherever the editor thinks you will be editing next.

The agent — the one that does the work. Called up with Cmd+I. It can edit files, run terminal commands, search the codebase, read files and images, go online and even drive a browser to check how the interface behaves and take a screenshot. For large changes there are checkpoints — snapshots of the project state you can roll back to if the agent takes the work in the wrong direction.

Rules — what separates one-off use from a working tool. These are, as the documentation puts it, "system instructions for the agent": a description of the project, code conventions, prohibitions. There are four kinds of rules:

• project rules — files in the .cursor/rules folder, kept in the repository and applied for the whole team;
• user rules — your personal preferences, active across all projects;
• team rules — set by an administrator in the dashboard, available on the Team and Enterprise plans;
• AGENTS.md — a plain text file in the project root with no extra markup; supports nested files in subdirectories.

When rules conflict, the priority runs: team rules, then project rules, then user rules. The practical point of this mechanism is direct: without rules every developer gets code from the agent in their own style, and a month later the project looks as if five different contractors had written it.

Getting started: installing and importing your VS Code setup

In short: download it from the official site, import your VS Code settings in one click, open the project folder.

1. Download the editor from cursor.com and install it like any other program — there are builds for macOS, Windows and Linux.
2. On first launch, accept the import from VS Code. Settings, themes, keyboard shortcuts and extensions move over automatically: Settings → General → Account → VS Code Import. If you want a selective import, export the profile from VS Code and load it manually.
3. Open the whole project folder, not a single file — the agent needs the full context, otherwise it works blind.
4. Create a rules file. Start with AGENTS.md in the root: a couple of paragraphs about what the project is, what it is written in, and what must not be done. This is the cheapest investment of time available to you.
5. Start with a small task on a non-critical part of the project and look at the result with your own eyes. Early on it helps to ask the agent to show a plan first and only then make the edits.

A tip: do not give the agent the right to run any command without confirmation until you understand how it behaves on your project. That goes double for commands that delete something or push changes to a shared repository.

Cursor or Claude Code: which to choose?

In short: Cursor is an agent inside an editor, Claude Code is an agent in the terminal; the choice depends on where you spend your day and who on the team will be using it.

In essence both solve the same problem: they take a request in words, study the project, make changes, run the checks. The difference is in the packaging, and it decides more than it first appears.

We have a detailed write-up on the second tool — Claude Code: what it is, how it works and how to use it. In short: the first wins on long sessions across a large repository, where tight control over what enters the model's working memory matters. The second wins on the barrier to entry — someone who has never lived in a command line finds it clear from the first launch.

There is a third option people rarely write about: you do not have to pit them against each other. Claude Code installs as an extension inside Cursor, and then the editor serves as the workplace and the agent as the one doing the work. Many teams end up exactly at that pairing.

What does Cursor cost and how are the limits counted?

In short: 20 dollars a month for an individual plan, 40 and 120 per team seat; the limit is counted as an amount of included model usage, not as a number of requests.

Pricing as of August 19, 2026, per the official page:

The consumption mechanics work like this: you have two pools, both reset every month. The first is Cursor's own models, where the limits are generous. The second is third-party models, billed at their providers' rates, and it is this pool that runs out first if you work on the most powerful models. Once the included usage is spent, you can buy more at standard rates or move to a higher plan; quality and processing speed are not degraded in the meantime.

When budgeting for a team, keep two things in mind. First: Standard and Premium differ in limits, their feature set is the same, and on a team of ten the difference comes to 800 dollars a month. Second: on team plans, third-party models carry an additional token charge — 0.25 dollars per million. It does not apply to Cursor's own models.

Does Cursor work in Russia?

In short: the program launches and runs; the difficulty is in paying for it.

Cursor publishes no list of supported countries. In the terms of service the restriction is worded broadly:

"You must comply with all applicable trade laws, including sanctions and export control laws. The Service may not be used in or for the benefit of countries and territories under US embargo, or by persons and entities with whom dealings are prohibited or restricted under applicable trade law" — Cursor terms of service, §17.5.

On the official forum a company representative answered a Russian user's direct question even more plainly: «Cursor is not under sanctions in Russia, and anyone can use it». The payment question in that same thread was left open.

Payment is the real obstacle: the service's payment system does not accept cards from Russian banks. The discussion on the official forum, where a company representative confirmed the product was available, ended at exactly that point — the question "how do I pay" was never answered. You can see it in search too: "cursor ai payment", "buy subscription", "pay" together draw more than three hundred impressions a month. Russian-language results on the topic are noticeably cluttered with ads for payment intermediaries: half the material at the top was written for the sake of a link to such a service. Their promises deserve the same treatment as any other advertising of financial services.

For a company there is a separate layer here that reviews never raise: paying a foreign service as a legal entity and using it inside a corporate perimeter is a question not only for the developer but for the accountant and the lawyer. If ten employees use the tool, "we bought a subscription through a friend" stops being a workable arrangement.

What happens to the code you hand over to Cursor?

In short: the code goes to servers abroad; privacy mode forbids training on it but does not undo the transfer itself.

This is the central question when the subject is a company system rather than a personal project. Let us go through the facts from Cursor's security page.

Privacy mode. The company's wording is direct: "When the mode is on, we will not train on your data. We also apply technical measures and contractual requirements on model providers to protect your data." It is available to everyone, including the free plan; it is switched on in settings or by the team administrator.

Certification. A SOC 2 Type II report is issued on request, and external penetration testing is carried out annually.

Geography. It is separately stated that the company does not use infrastructure in China and does not engage Chinese contractors. Nothing is said about infrastructure in Russia — there is none.

The practical conclusion follows from that last point. Any work by the agent means that fragments of your code leave Russia — for servers run by Cursor and by the model providers. A landing page does not care. But a system holding customer personal data, payments or trade secrets runs into the question of cross-border transfer and Federal Law 152-FZ, Russia's personal data protection law, rather than into an editor setting.

The way to handle it is to split the perimeter: what may go outside, what must stay in. Banning the tool outright works worse — the team simply works around it quietly. In practice the line runs along specific things: real customer data in test environments, access keys, pricing logic. Arranging that without losing development speed is part of the work we do in custom projects from the very beginning, not after an incident.

Is it true that work goes faster with AI?

In short: not everywhere. In a controlled experiment on Cursor, experienced developers turned out to be 19% slower than without it — and did not notice.

This is the most honest measurement that exists, and the tool in it was Cursor Pro specifically. Researchers at METR took 16 experienced developers and 246 tasks in projects where participants had an average of five years of experience. Half the tasks were allowed to be done with AI, half without.

Developers forecast that AI would cut completion time by 24%, and after the experiment they estimated the speed-up at 20%. In fact, using AI increased task completion time by 19% — "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", arXiv:2507.09089.

Everyone got it wrong: economists predicted a 39% reduction in time, machine learning specialists 38%.

None of this means the tool is useless — it shows where exactly the gain is and where it is not. The experiment ran on mature projects that participants know by heart: there a person is already working at their limit, and the agent adds overhead for explaining the task and checking the result. The gain lives elsewhere — on an unfamiliar codebase, on routine such as tests and dependency updates, on prototypes where the speed of testing an idea matters more than the durability of the solution.

And a separate conclusion, more important for a manager than the number itself: the subjective sense of speed here diverges from reality by 39 percentage points. If the adoption decision is made on how the team feels, it is being made on unreliable data.

How safe is the code an agent writes?

In short: syntactically it is almost always correct, and roughly half of it passes security checks.

Veracode runs hundreds of models through tests every year. In the March 2026 update covering more than 150 models the picture is this: the code compiles and runs in over 95% of cases, but only 55% passes security checks. The figure has not moved in two years, even though the models themselves have grown markedly stronger over that period.

The spread across languages is wide: Python — 62%, C# — 58%, JavaScript — 57%, Java — 29%. By vulnerability type it is uneven too: models handle SQL injection and weak cryptography in 82–86% of cases, but close cross-site scripting and log injection only 13–15% of the time. The report's conclusion: almost half of generated code contains known vulnerabilities unless the prompt explicitly demands a secure implementation.

There is a second, less obvious effect. A separate study ran 400 code samples through forty rounds of "improvements" using four different prompting approaches. The result: a 37.6% rise in critical vulnerabilities after five iterations. In other words, asking "make it better" several times over with no human between the rounds makes security worse, not better.

The practical meaning of both figures is the same: the agent writes code that works, and that is not the same as code that can be run in production. The difference is visible only to someone who reads the code — and it is exactly at that point that a prototype turns either into a system or into technical debt.

What changed in Cursor in August 2026?

In short: the tool stopped being merely an editor — it can now host your code and run agents in the cloud.

Recent releases from the official changelog:

• August 17 — Origin Code Hosting. The company stated it outright: "Cursor can now host your code." A tab for managing repositories appeared, along with two-way pull request synchronisation with GitHub and links to build and deployment services.
• August 13 — fast start for cloud agents. Pre-prepared environments: the agent launches in a ready environment instead of being set up from scratch, and time to first response fell threefold.
• August 3 — Google Workspace plugins. Agents gained access to mail, drive and calendar.
• July 29 — an iPad app with full review of changes.

The direction reads unambiguously: from an assistant in the editor to a platform that stores code and runs agents on its own side. For a solo developer that is convenient. A company should reread the previous section: the more functions move into the vendor's cloud, the more of your working perimeter ends up there.

Who is Cursor right for, and who needs engineered development?

In short: as a working tool — almost any team; as a way to save on a contractor — only where a mistake is cheap.

Three situations where Cursor pays for itself almost immediately:

• You already have developers. Then the editor takes the routine off them: tests for modules written long ago, dependency updates, clearing warnings. That is hours every week per person.
• You need to test an idea before investing. A prototype that comes together in an evening and shows whether the hypothesis holds is cheaper than any specification.
• You inherited someone else's project. There is no one to ask and no documentation — the agent reads the sources and explains how it all works.

There is exactly one situation where it lets you down: trying to use it in place of a contractor on a system that money depends on. The issue is not the quality of generation: 95% of what is generated compiles and runs. Everything breaks on the 45% that fails security checks — that is where the edge cases, access rights, data reconciliation and behaviour under load live. The economics of that choice are covered in a separate piece — your own system or an off-the-shelf package.

The practical yardstick is simple. Ask what one quiet failure in this system would cost. If the answer is measured in a lost evening — take the tool and build it yourself. If the answer is measured in customers' money, a regulator's fine or halted sales — the agent needs an engineer behind it who reads the code and answers for the result.

At INCUBE AI we work with such agents every day, and so we see that line without illusions. If you are sizing up the approach for your own task — come in for a consultation: we will go through the process and say plainly what is worth building in-house in a week and what should be done as an engineered system — under contract, with data kept in Russia and with support after handover.

Sources

• Product overview — Cursor documentation
• Tab autocomplete — Cursor documentation
• The agent and what it can do — Cursor documentation
• Project rules — Cursor documentation
• Pricing and limits — official Cursor page
• Migrating from VS Code — Cursor documentation
• Cursor changelog
• Security and privacy mode — Cursor page
• Cursor terms of service
• METR. "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", arXiv:2507.09089
• Veracode. Spring 2026 GenAI Code Security Update
• Shukla S. et al. "Security Degradation in Iterative AI Code Generation", arXiv:2506.11022