Start Debugging

Cursor Ships a TypeScript SDK That Turns Its Coding Agent Into a Library

Cursor's new @cursor/sdk public beta exposes the same runtime, harness, and models that drive the desktop app, CLI, and web UI as a TypeScript package. You get sandboxed cloud VMs, subagents, hooks, MCP, and token-based pricing in a few lines of code.

On April 29, 2026, Cursor opened the public beta of @cursor/sdk, a TypeScript library that wraps the same runtime, harness, and models that power the desktop editor, CLI, and web app. The pitch is simple: the agent that has been hiding inside Cursor’s UI is now a programmable component you can call from your own services. Same Composer model, same context engine, same tool surface, addressable from a Node process.

This is the same shift the Anthropic and OpenAI SDKs went through years ago, but for a coding-specialized agent rather than a raw chat model.

What ships in @cursor/sdk

Install it like any other package:

npm install @cursor/sdk

The minimal “create an agent and run a prompt” looks like this in the official docs:

import { Agent } from "@cursor/sdk";

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2" },
  local: { cwd: process.cwd() },
});

const run = await agent.send("Summarize what this repository does");

for await (const event of run.stream()) {
  console.log(event);
}

The interesting field is local. Pass it and the agent operates against your filesystem in the current working directory. Drop it and replace with cloud: { ... } and the same call now runs inside a sandboxed VM that Cursor provisions for you, complete with codebase indexing, semantic search, and grep on the remote side. The contract for Agent.create, agent.send, and the run stream is identical between the two.

That symmetry is the main feature. CI scripts that need to keep results local can stay local. Hosted agents that need to run untrusted prompts against ephemeral clones can move to the cloud runtime without rewriting the harness.

Subagents, hooks, MCP, and skills

The SDK does not stop at one-shot prompts. It surfaces the same primitives the desktop app uses:

Errors are typed: AuthenticationError, RateLimitError, ConfigurationError, and friends. No more parsing message strings.

Why this matters for .NET shops too

The SDK is TypeScript-only today, but the cloud runtime is language-agnostic, so you can spawn it from a small Node sidecar that a .NET service shells out to. Combined with the Microsoft Agent Framework on the C# side, the realistic 2026 pattern is starting to look clear: orchestrate from .NET, push code-editing tasks into a hosted Cursor agent over the SDK, and consume the results through MCP.

Pricing is standard token-based consumption with no separate seat for SDK use, so the experiment cost is whatever the model burns. The catch you have to keep an eye on is the cloud VM lifecycle. Long-running runs can stack up real money, and the SDK does not auto-cancel idle agents for you.

The full beta documentation lives at cursor.com/docs/sdk/typescript, and the launch post is cursor.com/blog/typescript-sdk.

Comments

Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.

< Back