Cursor Agent SDK vs Claude Agent SDK: What's the Difference?

Your team wants an engineering agent that wakes up when a pull request opens, a check fails or an incident fires. Two SDKs now carry almost the same name. Cursor's Agent SDK and Anthropic's Claude Agent SDK both give you an agent loop with tools, hooks and sessions. They hand your team very different jobs. Pick by name and you can end up running a webhook receiver, a state store and an approval flow you never planned for.

Choose by who owns five layers of your event-driven agent: the trigger, the runtime, the state, the approval and the recovery. Cursor's Agent SDK ships the trigger, hosting and durable state layers. It records who approved a needsApproval call, but the pages we read don't explain how to require one. The Claude Agent SDK is a library inside a process you operate. It gives you approval gates inside the agent loop and leaves intake, hosting and persistence to you.

TL;DR

• In this guide, "Cursor Agent SDK" means @grok/agent-sdk, GA since Oct 23, 2026. It is not the older Cursor SDK (@cursor/sdk).
• The Cursor Agent SDK supplies webhook channels, cron schedules, managed or self-hosted serving, and session state that survives redeploys.
• The Claude Agent SDK runs inside your process. You build intake, hosting and persistence. You get a callback that holds a tool call until a person answers.
• At the agent loop the two look alike. In an event-driven deployment, hook power, state durability and trigger hosting differ.
• Map one real workflow to its five owners, then run a bounded trial on one repo and one event type.

Which Cursor product this guide compares

Cursor uses "SDK" for more than one product. A search for "Cursor SDK" can return any of these:

• Cursor Agent SDK, the subject of this guide. The Agent SDK overview says it "lets you define, test, evaluate, and deploy agents as code." Cursor's launch post calls it the framework Cursor uses for its own managed agents, such as Bugbot. Cursor announced it on Oct 20, 2026, and its changelog marks 0.3.0 as the GA release on Oct 23, 2026.
• Cursor SDK (@cursor/sdk), a separate and earlier product. It "lets you call Cursor's agent from your own code," either inline in your Node process or in an isolated VM that Cursor runs. Cursor announced it on Apr 29, 2026 with token-based billing.
• Cursor CLI, which "lets you interact with AI agents directly from your terminal," with a print mode for scripts and CI.
• Cloud Agents API, an HTTP API (POST /v1/agents) that runs agents on Cursor-hosted VMs or routes them to your own workers. Cursor's help page on background agents says "In Cursor, we call these Cloud Agents."

The overview says the package was @cursor/bdk before, and the migration guide moves early-alpha @cursor/july projects with agent-sdk migrate. The launch post's code sample imports @cursor/agent-sdk, but the maintained docs and npm use @grok/agent-sdk. npm lists 0.5.0 (Oct 28, 2026), ahead of the changelog.

On Anthropic's side, the Claude Agent SDK ships as @anthropic-ai/claude-agent-sdk for TypeScript and claude-agent-sdk for Python, renamed from the earlier Claude Code SDK packages. Anthropic's overview describes it as a way to "Embed Claude Code's agent in your own Python or TypeScript application, in a process you operate." Managed Agents, where Anthropic hosts the agent, is a separate product.

How this comparison works

The criteria are the five owners of an event-driven agent: trigger, runtime, state, approval and recovery. The matrix splits them into eight rows so credentials, concurrency and cost get their own lines.

Model quality and benchmarks are out of scope. One model fact matters for policy. Cursor's agent config defaults to the grok-4.5 model, and the Claude Agent SDK runs Claude models. If your company mandates a model provider, that may decide the question first.

Product facts come from each vendor's docs, read on Oct 29, 2026. Nothing was installed or run.

Decision matrix: what each SDK supplies and what your team owns

The Cursor Agent SDK supplies most layers around the agent loop. The Claude Agent SDK supplies stronger controls inside the loop, and your team builds the rest.

Worked example: one pull request on both SDKs

This walk is illustrative. It follows each vendor's docs, nothing was installed or run, and it is not a tested recipe. The workflow: a pull request is opened, the agent reviews it and proposes a reviewable change, a person approves, and the result is posted.

(opens the full-size image in a new tab)

On the Cursor Agent SDK

1. Trigger. A GitHub channel receives the event. When you use your Cursor connection, the GitHub guide says "you don't need a public webhook URL, a GitHub App, or a personal access token." The quickstart channel starts a review when a pull request is opened, reopened or marked ready for review. GitHub can send many events for one pull request in a few seconds. The guide's sample coalesces them per pull request with a 3-second timer. Your team makes that buffer persist across restarts.
2. Review. Every wake for the same pull request resumes one session. A diff is untrusted input, so turn on the shell sandbox. The agent config says it is "off by default, so shell commands auto-approve." To propose a change, the guide's examples post reviews, comments and labels. The agent can also hand coding work to Cloud Agents, which spend the host account's cloud-agent budget.
3. Approval. Test this step first. The tools reference records who approved a needsApproval call and, on Slack, the person who clicked Approve. The reference pages we read do not explain how to require that approval, so verify it in a trial before you design around it. The fallback is the quickstart's pattern: a tool your team writes that approves the pull request or comments asking for a human review. The GitHub guide's review tool can post an approval to GitHub, so decide whether the agent may call it at all.
4. Result and recovery. The agent posts its review through those tools. On Cursor hosting, the webhooks guide says "the platform ignores whatever your handler returns," so the result goes out through a tool call. If a release misbehaves, the CLI rolls the deployment back to an earlier ready release.

On the Claude Agent SDK

1. Trigger. Your service receives the GitHub webhook. The hosting guide says "the subprocess itself does not listen on the network," so your app exposes the port. Signature checks, deduplication and queueing are your code. The alternative is Claude Code GitHub Actions, which is built on the SDK and runs on GitHub-hosted runners that consume your Actions minutes.
2. Review. A worker starts the SDK in a container you operate. The SDK runs a claude subprocess that owns a shell, a working directory and session files on disk. Run in default permission mode with allow rules for the read-only tools. In that mode, the permissions docs say a call that needs approval is denied unless something approves it, such as a canUseTool callback. The agent writes its proposed change in the working directory.
3. Approval. When the agent reaches the tool call that would push the change, canUseTool "pauses execution until you return a response." The callback can stay pending indefinitely. A permission-request hook can send a Slack, email or push notification while it waits. If the reviewer may take hours, a pre-tool-use hook can return defer so the process can exit and resume later.
4. Result and recovery. After approval, your code posts the result to the pull request. A process that resumes on a different host needs a transcript store or a copied transcript. The sessions docs say "Sessions persist the conversation, not the filesystem," so keep the working directory yourself. If a run hits its budget limit, you can resume it with a higher one.

On Cursor, the open work sits at the approval step. On Claude, it sits around the agent: intake, hosting and keeping files across hosts.

Are they both wrappers around an agent loop?

At the agent loop, the objection holds. Both SDKs expose tools, hooks, sessions, MCP and subagents. One published comparison of the earlier Cursor SDK recommends picking by existing stack and model preference, and expects teams to run several SDKs joined by MCP. For an agent a developer runs from a terminal, that rule works. It breaks down once an event starts the agent and nobody is watching.

• Hook power. Cursor's hooks reference says Agent SDK hooks "cannot change the turn, the prompt, or the reply." Cursor's IDE hooks are a separate feature. Claude's hooks can block dangerous operations and require human approval. Only the Claude Agent SDK documents an SDK hook that stops a tool call.
• State durability. On Cursor, the deployment docs say sessions and the key-value and file stores survive restarts and redeploys. On Claude, transcripts, memory and working-directory files sit on local disk by default and do not survive a container restart or a move to another node. On Claude, your team builds and runs that storage.
• Who hosts the trigger. Cursor mounts channels and runs schedules for you. Claude leaves the network port to your app, which adds a webhook service to your architecture.

Where each SDK fits

The Cursor Agent SDK fits when

• You want event intake, hosting and durable state supplied, including GitHub events through your Cursor connection, without a public webhook URL, a GitHub App or a personal access token.
• You want deploy, rollback and evals in one CLI. A failed eval or run exits with code 1, so it can gate a pipeline.

Check before you commit: how to require an approval, and whether your organization uses Privacy Mode (Legacy), under which managed hosting is not available. If Cursor caps your team, the default limits are 20 deployments and 100 deploys per 24 hours.

The Claude Agent SDK fits when

• A person must approve a tool call before it runs, and you want that gate inside the agent loop.
• You already operate containers, a queue and a database.
• Your models must come through a cloud provider such as Amazon Bedrock or Microsoft Foundry, which the quickstart lists as auth options.
• You want a per-call budget limit through maxBudgetUsd. It is enforced against the SDK's own cost estimate, so treat it as a guardrail, not a bill.

Check before you commit: the hosting guide warns that "Hosting it is not like hosting a stateless API wrapper." Anthropic's docs also direct third-party products to API key authentication: "Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products."

A CLI step in CI fits when

The job is one-shot. A third-party guide to driving agents from code says the CLI (claude -p or codex exec) is enough for one-shot CI. It says to use an SDK "when your code must branch on what the agent found."

If you already run dashboard Cursor Automations, Cursor's conversion guide warns that "Credentials, webhook registration, and Automation memory never carry over." Budget time to set those up again.

What the docs do not cover yet

• Cursor approvals: no reference page we read explains how to configure needsApproval or how a call waits.
• Cursor webhook delivery: retries, deduplication and events that arrive during a deploy are not covered in the pages we read.
• Cursor managed hosting price: not published on the pages we read.

---

Decision checklist for one workflow

Run these questions against one workflow, such as "review every new pull request in one repo":

1. Trigger: which event starts the agent, and what receives it, verifies it and absorbs bursts?
2. Runtime: who hosts the process, and can you meet its requirements (Node version, Privacy Mode, container size)?
3. Credentials: which account does the agent act as, and is the shell sandboxed when it reads untrusted input?
4. State: what must survive a restart or redeploy, and where does it live?
5. Concurrency: what happens when two events for one pull request arrive within seconds, or one event arrives twice?
6. Approval: which actions need a person's yes, where does that person answer, and does the SDK block the action until then?
7. Cost: which number do you budget against, and is it an estimate or a bill?
8. Recovery: how do you roll back a bad release, and how do you resume a run that hit a turn or budget limit?

Take one real workflow your team plans to automate. Write a name next to each of its five owners (trigger, runtime, state, approval and recovery) for each SDK. Then choose a bounded trial. A suggested shape: two weeks, one repo, one event type. Start from the Cursor Agent SDK overview and the Claude Agent SDK hosting guide.

Sources

• Cursor: Introducing the Agent SDK
• Cursor: Agent SDK overview
• npm registry: @grok/agent-sdk
• Cursor: Agent SDK changelog
• Cursor: Agent SDK migration guide
• Cursor: Build programmatic agents with the Cursor SDK
• Cursor: TypeScript SDK reference
• Cursor: CLI overview
• Cursor: Cloud Agents API endpoints
• Cursor: Background Agents help page
• Cursor: Agent SDK cloud agents guide
• Cursor: Agent SDK deployment
• Cursor: Agent SDK project layout
• Cursor: Agent SDK CLI reference
• Cursor: Agent SDK quickstart
• Cursor: Agent SDK webhooks guide
• Cursor: Agent SDK sessions reference
• Cursor: Agent SDK hooks reference
• Cursor: Agent SDK access reference
• Cursor: Agent SDK limits
• Cursor: Agent SDK tools reference
• Cursor: Agent SDK agent config reference
• Cursor: Agent SDK GitHub guide
• Cursor: Agent SDK convert-automation guide
• Anthropic: Agent SDK overview
• Anthropic: Agent SDK quickstart
• Anthropic: Migrate to Claude Agent SDK
• Anthropic: Hosting the Agent SDK
• Anthropic: Work with sessions
• Anthropic: Claude Code GitHub Actions
• Anthropic: Configure permissions
• Anthropic: Handle approvals and user input
• Anthropic: Intercept and control agent behavior with hooks
• Anthropic: Track cost and usage
• Developer Toolkit: Driving agents from code
• andrew.ooo: Cursor SDK vs Claude Agent SDK vs OpenAI Agents SDK