Agents
The Cursor SDK: Run the Agent From Your Own Code
The Cursor SDK lets you run Cursor's agent from your own code: @cursor/sdk on npm for TypeScript and cursor-sdk on PyPI for Python. One interface wraps two runtimes — local, where the agent loop runs in your process against files on disk, and cloud, where it runs in a Cursor-hosted VM with your repository cloned in. Both send inference to Cursor's hosted models.
On this page
What is the Cursor SDK?
The Cursor SDK is the programmatic way to run the same agent you use in the editor. Cursor's framing is that the SDK wraps local and cloud runtimes behind one interface, so you write the same code regardless of where the agent runs. It ships in two languages, and since release 1.0.24 they ship together from the same release and share a version number — Python no longer trails TypeScript.
- Package
- @cursor/sdk
- Registry
- npm
- Runtime requirement
- Node.js 22.13 or later
- Package
- cursor-sdk
- Registry
- PyPI
- Runtime requirement
- Python 3.10 or later
| Package | Registry | Runtime requirement |
|---|---|---|
| @cursor/sdk | npm | Node.js 22.13 or later |
| cursor-sdk | PyPI | Python 3.10 or later |
Per cursor.com/docs/sdk/typescript and cursor.com/docs/sdk/python, checked 2026-07-27.
One installation detail catches people out often enough that Cursor documents it explicitly: the npm package name starts with an @, and the bare cursor/sdk does not exist on npm. The TypeScript package is also Node-first by design — it ships per-platform @cursor/sdk-<os>-<arch> binaries for sandboxing and ripgrep.
npm install @cursor/sdk pip install cursor-sdk
This is covered hands-on in Agent Mode Foundations — 6 short modules, free to read.
What is the difference between local and cloud runs?
Both runtimes expose the same interface, and you choose between them by which key you pass to Agent.create() — local or cloud — using the same CURSOR_API_KEY either way. What changes is where the agent loop runs and where your files live.
- Runtime
- Local
- What it does
- Runs the agent loop inline in your Node process. Files come from disk
- When Cursor recommends it
- Dev scripts and CI checks against a working tree
- Runtime
- Cloud (Cursor-hosted)
- What it does
- Runs in an isolated VM with your repo cloned in. Cursor runs the VMs
- When Cursor recommends it
- When the caller doesn't have the repo, you want many agents in parallel, or runs need to survive the caller disconnecting
| Runtime | What it does | When Cursor recommends it |
|---|---|---|
| Local | Runs the agent loop inline in your Node process. Files come from disk | Dev scripts and CI checks against a working tree |
| Cloud (Cursor-hosted) | Runs in an isolated VM with your repo cloned in. Cursor runs the VMs | When the caller doesn't have the repo, you want many agents in parallel, or runs need to survive the caller disconnecting |
Runtime comparison as published at cursor.com/docs/sdk/typescript, checked 2026-07-27.
Cursor spells this out because the word invites the wrong reading: "Local" describes where the agent loop and filesystem access run, not where the model runs. All inference goes through Cursor's hosted models in both modes.
So local mode keeps your files on your machine and cloud mode runs in a Cursor environment, but the model is hosted in either case. If you are evaluating the SDK to satisfy a requirement that no code leaves your infrastructure for inference, local mode does not provide that.
How is the Cursor SDK structured?
There are three objects to learn, and the split between the first two is what makes multi-turn work straightforward: the agent holds the conversation, and each prompt gets its own handle for streaming and cancellation.
- Agent
- Durable container that holds conversation state, workspace config and settings. Survives across multiple prompts.
- Run
- One prompt submission. Owns its own stream, status, result and cancellation.
- SDKMessage
- Normalized stream events emitted during a run. The same shape across all runtimes.
Per the Core concepts table at cursor.com/docs/sdk/typescript, checked 2026-07-27.
In practice that means creating an agent once, then sending prompts against it and iterating the event stream. Cursor's own quick start is a local agent pointed at the current working directory:
const agent = await Agent.create({ apiKey: process.env.CURSOR_API_KEY!, model: { id: "composer-2.5" }, 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 Python equivalent uses a context manager and returns the text directly, which is the shorter path when you do not need to stream events:
import os
from cursor_sdk import Agent, LocalAgentOptions
with Agent.create(
model="composer-2.5",
api_key="crsr_key",
local=LocalAgentOptions(cwd=os.getcwd()),
) as agent:
print(agent.send("Summarize what this repository does").text())Which API keys work, and how are SDK runs billed?
Authentication is a single environment variable, CURSOR_API_KEY, or an apiKey option passed directly. The part worth checking before you plan a rollout is which kind of key is accepted, because one common choice is not supported yet.
- User API key
- Accepted for both local and cloud runs. From Cursor Dashboard → API Keys. Bills to that user's plan.
- Service account API key
- Accepted for both local and cloud runs. From Team settings. Bills to the team that owns the service account.
- Team Admin API key
- Not yet supported.
- Rates and pools
- SDK runs follow the same pricing, request pools and Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. Press Enter for the full definition. rules as runs from the IDE and Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition..
Per the Authentication and Usage-and-billing sections at cursor.com/docs/sdk/typescript, checked 2026-07-27.
Cursor states that SDK spend shows up in your team's usage dashboard under the SDK tag. That matters for anyone automating agent runs in CI: a script that loops over a hundred files spends from the same request pools as a developer working in the editor.
Because service account keys bill to the team and user keys bill to the individual, the key you hand your automation also decides whose budget absorbs it. Pick that deliberately rather than reusing whichever key was nearest.
What has shipped recently in the Cursor SDK?
The SDK moves quickly and the changelog is versioned, so it is worth knowing which release introduced the capability you are relying on rather than assuming it is present. The entries below are Cursor's own, newest first.
- Release
- 1.0.24
- What changed
- TypeScript and Python ship from the same release and share a version number; Python no longer trails. Long-running streams no longer drop mid-stream
- Release
- 1.0.23
- What changed
- Per-send environment variables for cloud runs via send(prompt, { cloud: { envVars } }); structured errors with message and code on failed runs; token usage in Python; local run history survives interrupted writes; streaming stalls under Bun fixed
- Release
- 1.0.22
- What changed
- Token usage on every run — per-turn usage events on run.stream() and cumulative totals on run.wait(), including for detached local handles that reattach
- Release
- 1.0.21
- What changed
- agent.send() works under Bun with the same behaviour as Node; Python list APIs and get_run accept runtime="cloud", "local" and "auto"
- Release
- 1.0.20
- What changed
- Importing @cursor/sdk no longer crashes under Bun
| Release | What changed |
|---|---|
| 1.0.24 | TypeScript and Python ship from the same release and share a version number; Python no longer trails. Long-running streams no longer drop mid-stream |
| 1.0.23 | Per-send environment variables for cloud runs via send(prompt, { cloud: { envVars } }); structured errors with message and code on failed runs; token usage in Python; local run history survives interrupted writes; streaming stalls under Bun fixed |
| 1.0.22 | Token usage on every run — per-turn usage events on run.stream() and cumulative totals on run.wait(), including for detached local handles that reattach |
| 1.0.21 | agent.send() works under Bun with the same behaviour as Node; Python list APIs and get_run accept runtime="cloud", "local" and "auto" |
| 1.0.20 | Importing @cursor/sdk no longer crashes under Bun |
Per cursor.com/docs/sdk/changelog, checked 2026-07-27.
Two things follow from that list. Bun support arrived in stages — clean import in 1.0.20, running agents in 1.0.21, no stalled streams in 1.0.23 — so pin a version rather than trusting a general claim that Bun works. And per-run token counts have only existed since 1.0.22 in TypeScript and 1.0.23 in Python, which is the floor for any cost-attribution script you write against the SDK.
Cursor's TypeScript page describes "the current package, @cursor/sdk@1.0.23", while the newest changelog entry is 1.0.24. The prose on the docs page has simply not been updated alongside the release.
Check the registry rather than either page before pinning: the version-specific claims here (self-contained .d.ts files, joint TypeScript and Python releases) are tied to whichever release you actually install.
Frequently asked questions
What is the Cursor SDK?
The Cursor SDK runs Cursor's agent from your own code, in TypeScript via @cursor/sdk on npm or Python via cursor-sdk on PyPI. It wraps two runtimes behind one interface: local, where the agent loop runs inline in your process against files on disk, and cloud, where it runs in a Cursor-hosted VM with your repository cloned in.
Does the Cursor SDK run models locally?
No. Cursor is explicit that "local" describes where the agent loop and filesystem access run, not where the model runs. All inference goes through Cursor's hosted models in both local and cloud modes. Local mode keeps your files on your machine; the model is hosted either way.
What are the Cursor SDK requirements?
The TypeScript package requires Node.js 22.13 or later and ships per-platform @cursor/sdk-<os>-<arch> binaries for sandboxing and ripgrep, making it a Node-first package. The Python package requires Python 3.10 or later. Note the npm package name starts with an @ — the bare cursor/sdk does not exist on npm.
Which API keys does the Cursor SDK accept?
User API keys and service account API keys, for both local and cloud runs. Team Admin API keys are not yet supported. Set CURSOR_API_KEY or pass apiKey directly. Service account keys bill to the team that owns the service account, and user keys bill to that user's plan.
How is Cursor SDK usage billed?
SDK runs follow the same pricing, request pools and Privacy Mode rules as runs from the IDE and Cloud Agents, and the spend appears in your team's usage dashboard under the SDK tag. For per-run token counts in code, the SDK has emitted usage events since 1.0.22 in TypeScript and 1.0.23 in Python.
Sources & last verified
- Cursor - TypeScript SDK
- Cursor - Python SDK
- Cursor - SDK changelog
- Cursor - Cloud Agents API endpoints
- Cursor - Service accounts
Cursor ships frequently. Facts verified against primary sources on July 27, 2026.
Keep reading
Rather do it than read about it? Run 11 interactive Cursor walkthroughs in a simulated editor. Free, no account needed.