Claude Agent SDK

This is Claude Code's loop inside your own program, with file reads, edits, grep and a shell already wired, so the first useful agent is a query() call away and the second one is a permissions decision. You will not love that it is Claude or nothing: every design choice assumes one model, and the day you want to compare providers you are rewriting.

Pick it for a coding agent, a repository bot, or anything that has to read and change files on day one. Pick the OpenAI Agents SDK if you need to swap providers or care more about handoffs than file tools.

The risk is a single vendor at every layer. No bring-your-own model, no local models, Claude and only Claude. Both packages ship a native Claude Code binary underneath the Python or TypeScript surface, so the loop you depend on is not the code you installed, and a behavior change in the binary is a behavior change in your product without a diff you can read.

Pin versions and test the binary like a dependency, not a library. What it does right: permissions decide which tools run automatically and which wait for approval, so the blast radius is a setting you own.

1. Built-in tools: Read, Write, Edit, Glob, Grep, Bash, WebSearch, WebFetch, so edits are explicit file operations, not diffs the caller must apply. 2. Subagents run subtasks in isolated context, which bounds what each one can confuse. 3. Hooks run user code at lifecycle points, which is where verification belongs. 4. Sessions resume or fork. Other languages drive the CLI with -p and --output-format json, so the harness is language-independent in practice.

No benchmark is published for the SDK as such. The consequence is that the loop's quality is the CLI's, whatever that is. The observation: this is the harness, published.

A Claude Code SDK is a feature of a terminal tool; a Claude Agent SDK is a platform play, and the rename is the whole thesis. The docs already position Managed Agents as the hosted tier above it, which is the classic ladder: give away the library, sell the runtime. The moat is the model plus the harness that made it famous.

No acquirer applies; the question is whether the SDK stays the default surface or becomes a stepping stone to the hosted one. Position: long the platform, price in a hosted upsell, keep your agent loop behind an interface of your own.

The demo is an agent that fixes a bug in an existing repository, built in an afternoon. As a dependency: maintained by Anthropic, callable through Bedrock, Vertex AI and Foundry, so it lands on an invoice we already pay; sixty engineers add $0 in seats and whatever the tokens cost, which is the number nobody budgets. Products may not use claude.ai subscriptions or be called Claude Code, so legal reads the terms once.

Onboarding is a package install and a key from the cloud contract. Approved with conditions: API spend caps per team and a review of any product that ships it externally.

The wrapper is MIT and readable; the loop is a native binary inside the package governed by Anthropic's Commercial Terms, so the license is a courtesy on the part that does not matter. No other model, nothing offline, and a fork would be a fork of the wrapper around a binary I cannot rebuild.

What I can bend: MCP servers in a mcpServers JSON block or in-process, hooks around every tool call, and it reads skills and memory from .claude/ and ~/.claude/ like the CLI, so my existing config carries over. Rented, with good plumbing. Grudging respect for the in-process MCP, which is the right way to add a tool.