Cursor (AI IDE Platform Market Research)

1. Introduction

Cursor is an AI-native integrated development environment developed by Anysphere, built on a fork of VS Code. It entered the public eye in 2023 in a form of "editor + autocomplete + chat", then quickly pivoted to an agent-centric product architecture, and is now one of the most recognizable products in the AI IDE category by brand awareness.

Cursor's product strategy has a distinctive feature: it turns as much of Harness's six-layer capabilities as possible into "out-of-the-box" defaults, while making team-side organizational governance capabilities paid add-ons. Individual users get rules, MCP, skills, hooks and cloud agents at the Pro tier; while centralized billing, team marketplace, usage analytics, privacy mode, SSO, SCIM, audit logs and the AI code tracking API sit at the Teams and Enterprise tiers. This tiering line is essentially selling L1–L4 (individual productivity) separately from L5–L6 (organizational predictability).

1.1. Developer and Product History

1.2. Positioning and Latest Version

Cursor is positioned as an editor-first AI development environment: it puts the strongest inline experience (Tab prediction and inline diffs) together with full agent capabilities in a single interface, so developers don't need to switch tools between "writing it yourself" and "delegating to AI". This creates a clear division of labor with the terminal-centric Claude Code and Codex CLI — the latter two are better suited to long-running, unattended batch tasks.

The latest version and version number are fast-changing information; at the time of writing, no verifiable current version number could be obtained from the official release page, recorded as [To be filled]; the specific generation and release timing of its in-house model (the Composer series) are likewise marked [To be verified].

1.3. Pricing

The following prices are taken from Cursor's official pricing page (accessed in 2026):

Supplementary notes (third-party, marked [To be verified]): annual billing is roughly 20% cheaper than monthly; the Hobby tier includes a limited autocomplete quota and a small number of slow premium requests; paid tiers use a two-layer "credit pool + Auto mode" structure, where in Auto mode Cursor routes to a more cost-effective model without consuming the credit pool used for manual model selection.

2. Glossary

3. Feature Description

3.1. In-Editor Intelligence

3.2. Agent and Parallel Execution Capabilities

3.3. Extension and Integration Capabilities

• MCP: Can connect external tools and data sources; the Enterprise tier provides MCP access controls limiting the range of servers an organization may use.
• Skills and hooks: Available from the Pro tier onward, allowing reusable workflows and lifecycle scripts to be fixed into the repository and shared across the team.
• Extensions and team marketplace: Rules, skills and extensions can be published to the team-internal marketplace for unified distribution; this is Cursor's most distinctive L1 governance design on the organizational side — upgrading "context conventions" from personal habit to versionable, auditable team assets.
• VS Code compatibility: Extensions, themes and shortcuts can be migrated directly, lowering switching costs.

3.4. Team and Enterprise Capabilities

4. Platform Architecture

图 4-1｜Cursor 双运行时平台架构（本地编辑器 × 云端代理运行时）

数据来源：基于本文分析绘制的示意图。

4.1. Overall Architecture

Cursor uses a dual-runtime structure of "local editor + cloud agent runtime":

The key engineering implication of this structure is: a single "task" may span both local and cloud execution domains, so the context assembly rules must be consistent on both sides, or there will be a split where "it runs well locally but goes off the rails in the cloud". This also explains why Cursor puts rules and skills into the team marketplace for unified distribution.

4.2. Rules and Context Assembly

Cursor's rules system is among the most finely layered of the six platforms in this group; the four activation modes correspond to four context costs:

This design maps directly onto two principles of the Harness L1 layer: context is a scarce resource, and too much guidance becomes no guidance. Injecting a 200-line project specification indiscriminately into every request both wastes budget and dilutes attention; mounting by glob and reading on demand is the scalable approach.

4.3. Execution and Isolation Model

Cursor's execution safety relies on three stacked layers:

1. Diff rendering and manual acceptance: every change is presented as diff hunks, accepted or rejected hunk by hunk — this is the default first guardrail, keeping the judgment of "what changed" in human hands.
2. Command confirmation and Auto-run policies: command execution requires confirmation by default; the Enterprise tier provides Auto-run, browser and network control policies, letting organizations uniformly set how far to open things up.
3. Cloud-side sandbox: cloud agents run in Cursor's hosted environment, isolated from the local machine, naturally limiting the blast radius.
1. Self-hosted infrastructure hosting (Self-Hosted Machines, 2026-09-02 changelog): tool execution for cloud agents can land on the enterprise's own network (in forms such as AWS Lambda MicroVM, Kubernetes, Coder, Cloudflare, Daytona, Modal), while planning and the reasoning loop remain on the Cursor cloud — L2 execution is deployed separately from L1/L3 orchestration, serving data-compliance scenarios. Cursor discloses that more than 60% of its internally merged PRs are generated by cloud agents (vendor-reported figure).

It should be noted: Cursor's official pricing page and public materials do not disclose a list of operating-system-level sandbox primitives at the same granularity as Claude Code (such as the specific configurations and default write scopes of Seatbelt / bubblewrap); this item is recorded as [To be filled], and one should not assume its isolation strength is equivalent to that of terminal-style tools.

5. Harness Design

5.1. L1 Context Engineering Layer

Cursor's investment in L1 is mainly reflected in three areas:

(1) Layering and on-demand loading of rules. The four rule types (Always / Auto Attached / Agent Requested / Manual) turn "how much to inject" into an adjustable knob. The engineering recommendation: keep Always rules within a few dozen lines, writing only non-negotiable red lines and global conventions; mount language and module conventions via Auto Attached globs; and route long documents through Manual.

(2) Codebase indexing and semantic retrieval. The index lets the agent consume context by relevance rather than loading everything, which is the prerequisite for usability on medium-or-larger repositories. The lever under the user's control is controlling the index scope — excluding generated artifacts, lock files and output directories from the index significantly reduces noisy recall.

(3) Model routing and credit awareness. Auto mode hands cost and latency routing to the platform, while manual model selection consumes the credit pool. This is effectively a cross-cutting design between L1 and L6: indirectly constraining context cost through routing policy. Teams should be clear about which tasks may use frontier models (complex refactors, architecture decisions) and which must use Auto (autocomplete, routine changes), or credits will be drained on low-value tasks.

Known weaknesses: always-on rules and indexed content together form a fixed overhead for every request; the more rules you write, the smaller the window available for the task itself. This is the most common degradation path for Cursor users — a rules file grows from 50 lines to 500, and then they complain "the agent got dumber".

5.2. L2 Tools and Execution Layer

Design highlight: making MCP access controls an Enterprise capability. This is relatively rare among comparable products — most products allow arbitrary MCP server connections, and yet MCP servers are precisely a high-risk entry point for prompt injection and privilege escalation. Cursor elevating "what can be connected" into an organizational policy is an uncommon explicit link between L2 and L6.

Known weakness: the isolation granularity of the local execution path is not publicly disclosed, making it impossible to judge equivalence with terminal-style tools (Claude Code's Seatbelt / bubblewrap, Codex CLI's Landlock + seccomp).

5.3. L3 Orchestration and Control Layer

Cursor's orchestration capability is made up of three tiers:

1. Single-session agent loop: plan, execute, observe results and iterate within the current session until the task completes or is interrupted.
2. Background / parallel agents: dispatch tasks to independent execution units without blocking the current editing, suited to parallelizable independent subtasks.
3. Cloud agents and automation: execute asynchronously in a hosted environment and return results as PRs, suited to long-duration and periodic tasks.

From an engineering standpoint, the three should be treated as different levels of trust: the single-session loop suits changes requiring close supervision; background agents suit mutually independent batch tasks; cloud agents suit migrations and refactors where regression protection is already established.

Objectification of the orchestration layer (Projects, Beta, phased rollout from 2026-09-10): Projects productizes the large-granularity work unit at the "one feature / one migration" level into an independent object — the coordinator agent (Coordinator Agent) itself does not write code; it is only responsible for planning, dispatching tasks to several parallel implementation agents and collecting the results; the project runs on a dedicated cloud computer (not interrupted by shutdown), and when local verification is required the coordinator temporarily spins up a local agent; the project maintains cross-machine synchronized shared files and context, so the testing methods and codebase knowledge accumulated by any agent are reused by subsequent agents; it can also be bound to a Slack channel, a scheduled task or a PR event to automatically trigger delegation. This is the first form in this group that productizes the L3 orchestration layer (coordinator — sub-agent dispatch) into an independent object, evolving in the same direction as Claude Code's sub-agent mechanism and the OpenAI Agents API's hosted multi-agent. Pricing has not been announced, [To be verified].

Known weakness: public materials do not show a lifecycle event list as complete as Claude Code's hooks, nor an explicit "plan — confirm — execute" two-phase mode as a first-class citizen. For scenarios that require "locking in the plan before acting", users often have to codify this process themselves in their rules.

5.4. L4 Memory and State Layer

Cursor's L4 is made up of three parts:

The actual strength of this layer depends on whether the team writes conventions into the repository. Cursor provides the mechanism, but it does not replace engineering discipline: a repository without rule files starts from zero on every session.

5.5. L5 Evaluation and Observability Layer

L5 is the thinnest of the six layers in Cursor. It provides observability of cost and usage, but does not provide a mechanism for "the machine judging whether this change was right or wrong" — such mechanisms exist naturally through testing and CI in terminal-style tools, while in editor-style tools the team must fill the gap itself. This group's recommendation is therefore: teams using Cursor must establish regression testing and CI gates as independent hard constraints; they cannot count on the tool to provide them.

5.6. L6 Governance and Security Layer

Cursor's L6 is the most organizationally complete among the six platforms in this group:

For regulated industries, the four capabilities — "codebase, model and MCP access controls + Auto-run controls + audit logs + AI code tracking API" — together form a complete closed loop for whether an enterprise can delegate authority: it can limit what it sees, limit what it can do, check retroactively what it did, and separately attribute AI output from human output.

Known weakness: audit and tracking capabilities are concentrated at the Enterprise tier; if a small or mid-sized enterprise stays at the Teams tier, it lacks organization-level behavioral trails.

5.7. Six-Layer Capability Summary

6. Practical Case Studies

Note: the case studies in this section are written based on Cursor's publicly disclosed capabilities and reproducible workflow orchestration, and do not cite unverified enterprise performance data. Wherever quantitative results are involved, they are either omitted or marked [To be verified].

6.1. Case Study 1: Building Layered Rules for a Large Repository

Background: a multilingual monorepo where the team's conventions on directory structure and error handling were inconsistent, and agent-produced code style drifted badly.

Approach: reorganize the rules into four categories — put a few-dozen-line Always rule in the root (security red lines, disallowed APIs, commands that must run before commit); place Auto Attached rules in per-language and per-module directories with globs limiting their effective scope; write migration guides and release processes as Agent Requested rules with clear descriptions; and set long-form architecture documents as Manual. Rules are distributed uniformly through the team marketplace.

Effect mechanism: always-on context overhead is compressed into a controllable range, and rules align with the actual objects being edited; team conventions go from verbal consensus to versioned, reviewable assets stored with the repository.

6.2. Case Study 2: Handling Batch Migration with Cloud Agents

Background: the same class of mechanical migration needs to be run across dozens of modules (such as API replacement after a dependency upgrade); doing it manually is time-consuming and prone to omissions.

Approach: write the migration rules as Auto Attached rules, explicitly stating "do not refactor unrelated code as a side task"; dispatch an independent background or cloud agent task per module to run in parallel; require each task to return as its own PR upon completion, forbidding direct commits to the main branch.

Effect mechanism: tasks are isolated from each other, so a single task failure does not affect the others; each PR is independently reviewable and revertible; the blast radius of the batch change is limited to PR granularity.

6.3. Case Study 3: Using Bugbot for Pre-Merge Review

Background: the volume of AI-generated changes is large, human review becomes a bottleneck, and review quality degrades with review fatigue.

Approach: enable Bugbot agentic code review in the PR process, letting the machine pass over "style and common defects" first; human review focuses on semantic correctness and architectural consistency.

Effect mechanism: review is split into a machine-judgable layer and a human-must-judge layer, concentrating human attention on high-value judgments. Note that this kind of review is an assistive measure and cannot replace regression testing — this group has seen no public material showing Bugbot can score programmatically, so it is marked [To be verified].

6.4. Case Study 4: Privatization Constraints in Regulated Industries

Background: teams in finance or healthcare where code cannot leave the organization or be used for training, and AI output records must be retained for audit purposes.

Approach: enable team-wide privacy mode; configure codebase, model and MCP access controls at the Enterprise tier to limit the usable models and server scope; disable or restrict Auto-run and browser access; turn on audit logs and service accounts; and import AI-generated records into the internal audit system via the AI code tracking API.

Effect mechanism: the three things — "what it can see, what it can do, and what records it leaves behind" — are simultaneously enforced on the platform side, forming a governance evidence chain that can be presented externally.

7. Summary

7.1. Strengths

1. Finest context-cost control design: the four rule types turn "how much to inject" into an adjustable knob, directly addressing the core tension of the L1 layer.
2. Strongest editor experience: the combination of Tab predicting the "next edit" and hunk-by-hunk diff acceptance makes tightly-supervised workflows the most efficient.
3. Complete organizational governance: SAML/OIDC, SCIM, codebase/model/MCP access controls, Auto-run controls, audit logs and the AI code tracking API form the complete closed loop an enterprise needs to delegate authority.
4. The team marketplace is a distinctive design: upgrading rules, skills and extensions into versionable, distributable team assets.
5. VS Code compatibility: low migration cost; the extension ecosystem can be reused directly.

7.2. Limitations

1. L5 evaluation layer is the thinnest: it has review and usage observability but lacks mechanical criteria and a regression set; quality assurance must depend entirely on team-built testing and CI.
2. Local execution isolation granularity is undisclosed: it cannot be compared for equivalence with the OS-level sandboxes of terminal-style tools.
3. Enterprise governance is concentrated at the top tier: small and mid-sized teams at the Teams tier lack organization-level audit trails.
4. The two-layer billing of Auto mode and the credit pool adds cognitive cost: teams that do not actively manage routing policy tend to drain credits on low-value tasks.
5. Rule bloat is the main degradation path: unbounded growth of always-on rules directly dilutes effective context.

7.3. Applicability Boundaries

7.4. Selection Recommendation

The criterion for choosing Cursor is: the team's primary workflow lives in the editor, and it is willing to pay for organizational governance. If your team works eight hours a day in the IDE and needs to review AI changes hunk by hunk, the Cursor L1 + L6 combination is the best match; if your work is dominated by long batch tasks, you should prioritize Claude Code or Codex CLI and treat Cursor as a supporting editor.

Regardless of whether you choose Cursor, this group recommends doing one thing first: write the team's engineering conventions as rule files in the repository and distribute them through the team marketplace. This step is a prerequisite for realizing the benefits of any AI IDE, and has little to do with which vendor you pick.

Information Gap Statement

1. Version number and release timing: no verifiable current version number or release notes were obtained at the time of writing, marked [To be filled]; the generation and timing of the in-house Composer model are marked [To be verified].
2. Local sandbox implementation details: OS-level isolation primitives, default write scopes and network proxy mechanisms have not been officially disclosed, marked [To be filled].
3. Exact prices of Pro+ and Ultra: the official pricing page does not show them directly in static content; third-party figures are ~$60/month and ~$200/month respectively, marked [To be verified].
4. The Hobby tier's specific quota (autocomplete count, number of slow requests) comes from third-party aggregation, marked [To be verified].
5. The annual-billing discount (~20%) and credit pool rules come from third-party interpretation, marked [To be verified].
6. Whether Bugbot supports programmatic scoring, and whether it has a regression-set concept: not confirmed by official material, marked [To be verified].
7. Enterprise deployment performance data: this group found no supporting first-hand source, and adopted none of the unverified quantitative performance figures.

8. References

1. Cursor official pricing page — Anysphere, 2026. https://cursor.com/pricing
2. Cursor official website — Anysphere, 2026. https://cursor.com/
3. Cursor official documentation — Anysphere, 2026. https://docs.cursor.com/
4. Cursor security page — Anysphere, 2026. https://cursor.com/security
5. Cursor enterprise page — Anysphere, 2026. https://cursor.com/enterprise
6. Cursor community forum — Anysphere, 2026. https://forum.cursor.com/
7. Model Context Protocol official site — MCP / AAIF, 2024–2026. https://modelcontextprotocol.io/
8. Effective context engineering for AI agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
9. Equipping agents for the real world with Agent Skills — Anthropic, 2025-10-16. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
10. 2025 Stack Overflow Developer Survey — Stack Overflow, 2025-07-30. https://survey.stackoverflow.co/2025/
11. DORA 2025 State of AI-assisted Software Development — Google Cloud / DORA, 2025. https://dora.dev/
12. Terminal-Bench official site — Stanford / Laude Institute, 2025–2026. https://www.tbench.ai/