Cursor SDK

Overview

Cursor SDK turns the Cursor coding harness into a programmable runtime. Where Cursor itself is an IDE, the SDK is the same engine without the editor surface — exposed as a TypeScript API that you wire into CI/CD pipelines, internal automation platforms, or customer-facing products. The strategic shift is that Cursor is no longer just a developer tool; it’s a runtime substrate that engineering teams deploy on.

The launch context matters. The Codex /goal primitive collapsed the agent-harness category into a CLI feature in late April. Two days later, Cursor responded by exposing its harness as a paid SDK. The signal: when the loop becomes commodity, the surface that monetizes is the runtime — sandboxed compute, codebase indexing, skill discovery, subagent orchestration — not the loop itself.

Key Capabilities

Programmatic agent creation: npm install @cursor/sdk, instantiate an agent, give it a goal, and it runs against your codebase with the same context engine that powers Cursor’s IDE features. No need to recreate codebase indexing, semantic search, or grep tooling.

MCP-first tool integration: Agents pick up MCP servers configured for the project automatically. The same MCP definitions that power your IDE workflow are available to programmatic agents — no duplicate config.

Skills and hooks: .cursor/skills/ (markdown skill files following the SKILL.md spec) and .cursor/hooks.json (lifecycle observers and gates) are loaded automatically. Skills written for Cursor SDK are largely portable to Claude Code via the cross-runtime skills format.

Subagents: Named subagents accept custom prompts and per-task model selection. Useful for splitting a large task across specialist agents — one for refactoring, one for test generation, one for documentation.

Sandboxed cloud VMs: Agents run on the same Cloud Agents infrastructure backing Cursor’s hosted offerings. Each agent gets a siloed environment with controlled file, tool, and code access.

Pricing

Token-based billing. Composer 2 Standard (the default model) runs $0.50 per million input tokens and $2.50 per million output tokens. There is no per-seat surcharge — you only pay for the tokens agents actually consume. This is the structural advantage Cursor is pressing against seat-priced incumbents: a thousand parallel CI agents do not require a thousand Cursor seats.

Production Use Cases

• Ticket-to-PR (Rippling, Notion): Agents pick up Linear or Jira tickets, understand requirements, generate implementations, write tests, and open draft PRs for engineer review.
• CI/CD root-cause analysis (Faire): Agents triage CI failures, identify root causes, and update PRs with fixes inline.
• Internal platforms (C3 AI): Agent-powered platforms for non-technical teams to query product data without writing SQL or hitting analyst queues.
• Embedded customer agents: Cursor SDK can be embedded inside customer-facing products, exposing an agent UX where the host application is the chat surface.

Lock-In Profile

Skills (SKILL.md files) port cleanly to Claude Code and other harnesses that follow the open spec. Subagent and hook configurations are Cursor-specific — moving off Cursor SDK requires replacing .cursor/hooks.json with the equivalent in your target harness. The exit ramp via cc-switch and the broader cross-runtime tooling layer is real but costs ~1–2 weeks of adapter work per major flow.

Where It Fits

Cursor SDK is the right substrate when your distribution graph is engineers and your deployment shape is asynchronous CI/CD work. It is not the right substrate when your value lives on the consumer side (use the OpenAI Apps SDK) or when your agent has to operate inside an authenticated browser session (compose with Browserbase Skills).