Claude Agent SDK

What it is

The Claude Agent SDK is Claude Code with the terminal taken off. The same agent loop, the same file and shell tools, the same context management, exposed as something you import and call from your own program. It is the answer to the question every team reaches eventually: the CLI does what we want, but we need it running inside our service, with our tools, without a human at a prompt.

Note what it is not. It is a proprietary library from Anthropic, not an open-source framework, and it talks to Claude models only. You are buying the harness, not a portable abstraction over model vendors.

How the loop works

You construct a session with a system prompt, a set of tools and a permission policy, then send it a task. The library runs the turn cycle — model call, tool call, tool result, repeat — until the model stops asking for tools or one of your limits trips. What you get back is a stream of structured events rather than a blob of text, so you can log each tool call, render progress, or interrupt part-way through.

The parts worth paying for are the ones nobody enjoys writing. Compaction, so a long session does not die at the context limit. A built-in file and shell toolset with error messages written for a model to recover from. Subagents, so a research step can burn its own window and hand back a conclusion. MCP support, so external tools plug in without bespoke glue. You can add your own tools as ordinary functions, and you can turn the built-ins off when you do not want an agent that can run shell commands at all.

Isolation and permissions

The spec line is the important one: it inherits the host process. There is no sandbox in the box. The agent's file access is your process's file access, its network reach is your process's network reach, and its environment variables are your environment variables — including the credentials you did not think about. That is the correct design for a library, and it moves the entire isolation problem onto you.

In practice that means running agent sessions in a container, a VM or a dedicated worker with a scoped service account, not in the same process as your web application. The permission callback is genuinely useful — you can approve, deny or rewrite each tool call programmatically, which is how you encode policy rather than trusting a prompt. But policy applies to the tools the SDK mediates; anything your own code does around it is unguarded.

Who it is for

Teams building a product on top of an agent loop rather than using one at a keyboard: a review bot, a scheduled maintenance job, an internal tool with a web front end. Python and TypeScript are first class. Anything else drives the CLI as a subprocess and parses its structured output, which works but leaves you owning process lifecycle, back-pressure and crash recovery.

Limits

• Single vendor, twice over. Claude models and an Anthropic library. If model portability matters, a framework such as Pydantic AI or LangGraph is the right layer instead.
• Closed source. You debug against documented behaviour, not against the implementation.
• You own the operations. Sandboxing, concurrency, retries, cost caps and observability are all yours. That is real work, and it is the work Managed Agents exists to remove.
• It tracks the CLI. The loop improves when Claude Code does, and behaviour can shift under you between versions. Pin the dependency and read release notes.
• Autonomy is not free. Removing the human from the loop removes the last check on a confidently wrong turn. Budget for evaluation harnesses, not just prompts.

Alternatives on this board

• Claude Code — the same loop with a human at the prompt; use it until you genuinely need the library.
• Managed Agents — hand the sandbox and the session infrastructure back to the vendor.
• OpenAI Agents SDK — the same shape from the other large vendor.
• Pydantic AI — when typed, model-agnostic plumbing matters more than a ready-made coding loop.