Developer guide
How to host the Claude Agent SDK in production
Deployment patterns, sizing, session storage, credential proxies, where to run it, and when to go managed instead.

What does it take to run the Claude Agent SDK in production?
The Claude Agent SDK is a library that spawns and supervises a claude CLI process with its own shell, working directory, and session files. Running it in production means giving each agent a container, a place to keep its sessions, a safe path out to the network, and a way to start, stop, and watch it.
Anthropic's hosting guide describes the shape plainly: the SDK spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk. You need Python 3.10 or later for the Python SDK, or Node.js 18 or later for TypeScript, and both bundle the CLI binary. The container needs outbound HTTPS to api.anthropic.com, or to your cloud provider's endpoint.
That makes each running agent a long-lived process with local state, closer to a small server than a function call. A session doesn't time out on its own, so set a turn limit, and plan for what happens to its files when the container goes away.
Decide on authentication early. The subprocess reads ANTHROPIC_API_KEY, or uses Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry credentials. Use of the SDK falls under Anthropic's Commercial Terms, and unless Anthropic has approved it, a product can't offer claude.ai login or subscription rate limits to its users.

Which deployment pattern fits your agent?
Anthropic describes four patterns: an ephemeral container per task, long-running containers that host several agents, a hybrid that rehydrates sessions on demand, and a multi-agent container for agents that work closely together. Match the pattern to how long your sessions live and how often they sit idle.
Ephemeral containers are the simplest and safest place to start: create one for each task and destroy it when the task completes. Long-running containers suit agents that take autonomous action, serve content, or handle high-volume message streams, but they need careful per-session memory limits and isolation between tenants.
The hybrid pattern is for conversations that last days but sit idle most of the time. Containers start, load the session from a SessionStore, and save it back, and Anthropic is explicit that the store is required for this pattern, because shutting a container down without one loses the transcript.

| Pattern | How it runs | Best for | Watch out for |
|---|---|---|---|
| Ephemeral | A new container for each task, destroyed when it finishes | One-off jobs: a bug fix, an invoice extraction, a translation | Anything you need later must be exported before teardown |
| Long-running | Persistent containers, often several SDK processes each | Autonomous agents, Slack bots, email agents, message streams | Per-session memory ceilings and tenant isolation |
| Hybrid | Ephemeral containers that load and save sessions from a SessionStore | Long conversations with idle time between messages | A SessionStore is required, not optional |
| Multi-agent container | Several SDK subprocesses inside one container | Agents that must collaborate closely | A shared filesystem means a shared blast radius |
How big should the container be, and what does it cost?
Start at 1 GiB of RAM, 5 GiB of disk, and 1 CPU per agent, then size hosts by the memory ceiling you set per session. Budget mostly for tokens: Anthropic says a minimal container runs about $0.05 an hour while a long session can spend dollars in tokens.
Anthropic calls 1 GiB of RAM, 5 GiB of disk, and 1 CPU per agent a reasonable starting point for a freshly started instance. That's a starting point for a fresh instance, so measure your own agents under real load before packing more onto a host.
Compute is rarely the big line. Anthropic says token cost typically dominates container cost by an order of magnitude or more. Track it per run: the SDK's total_cost_usd and costUSD fields are client-side estimates, the modelUsage field gives whole-run token totals, and the Claude Console's Usage and Cost API is the authoritative bill.
agents per host = (host RAM - overhead) / (per-session RAM ceiling)
example: (16 GiB - 2 GiB) / 1 GiB = 14 agentsHow do you keep sessions when containers come and go?
Sessions are files on the container's disk, and they're lost when the container restarts, scales down, or moves. Mirror them to shared storage with a SessionStore adapter, and save any working files the agent creates separately.
The CLI stores each session as a JSONL file under ~/.claude/projects, and resuming works only on a machine where that file still exists. To resume across machines or in serverless environments, mirror transcripts with a SessionStore. Both SDK repositories include runnable reference adapters, including S3, Redis, and Postgres, plus a conformance suite for your own.
Know what the store doesn't cover. It mirrors the conversation, not the filesystem, CLAUDE.md memory files, or other working-directory artifacts, so anything the agent writes to disk needs its own persistence. Mirror writes are best-effort: the subprocess writes locally first, so a store outage doesn't stop the agent, but you should alert on mirror errors.
How do you secure a hosted Claude agent?
Run each agent in an isolated container with no direct network access, send all outbound traffic through a proxy that enforces an allowlist and adds credentials, put authentication in a gateway in front, and set permissions explicitly.
Anthropic's secure deployment guide recommends a proxy outside the agent's security boundary that injects credentials into outgoing requests, so the agent never sees them. For production, the hosting guide adds a domain allowlist and request logging to that egress proxy. Even the Anthropic key can stay outside: set ANTHROPIC_BASE_URL to route model calls through a proxy that adds the key after the request leaves the container.
Lock the network down. A container with no network access that can reach only the proxy over a Unix socket can't send data to arbitrary servers, even if a prompt injection compromises the agent, and cloud firewall rules should block all egress except to the proxy. For stronger isolation than containers, Anthropic points to gVisor and Firecracker.
If one host serves several customers, keep their settings and memory apart: pass an empty settingSources list so user and project settings aren't loaded, disable auto memory, and give each tenant its own config directory. Then set permissions explicitly, since a matching deny rule blocks a tool even in bypassPermissions mode. For the credential patterns in more depth, see how to give AI agents access without exposing credentials.

Where can you run the Claude Agent SDK?
Anywhere you can run a container: your own Docker or Kubernetes, a sandbox platform such as Modal, Daytona, or Vercel Sandbox, or a managed cloud runtime such as Amazon Bedrock AgentCore, Google Agent Runtime, or Microsoft Foundry hosted agents.
Anthropic's cookbook walks through local Docker, Modal, and Kubernetes, and its appendix shows the same Dockerfile deployed to other platforms. Some vendors publish their own SDK guides: Daytona and Modal both show a proxy that keeps the API key out of the sandbox, and Vercel has a guide to installing the SDK in Vercel Sandbox.
The cloud runtimes run any framework in a container. AWS publishes an AgentCore sample for the Claude Agent SDK, and Microsoft's Foundry samples include one that uses Foundry credentials. Google's Agent Runtime and Cloud Run accept any framework that follows their container contract, though we found no Claude-specific guide from Google. Note each runtime's session limits, and pair it with a SessionStore: AgentCore, for one, says its session state is ephemeral.
| Option | What you get | Limits to know | Pricing basis |
|---|---|---|---|
| Your Docker or Kubernetes | Full control; Anthropic's cookbook examples | You operate everything | Your own compute |
| Modal | Sandboxes; an SDK example with an API-key proxy | You build sessions and access | Per-second CPU and memory |
| Daytona | An SDK guide; real key added at egress | You build sessions and access | $0.0504 per vCPU-hour plus memory, billed per second |
| Vercel Sandbox | A guide to installing the SDK | Sessions up to 45 minutes on Hobby, 24 hours on Pro | Active CPU $0.128 an hour plus memory, in iad1 |
| Amazon Bedrock AgentCore | A microVM per session; an AWS SDK sample | Sessions up to 8 hours; 15-minute idle default | $0.0895 per vCPU-hour and $0.00945 per GB-hour by default |
| Google Agent Runtime or Cloud Run | Any framework in a container | No Claude-specific guide found | $0.085 per vCPU-hour and $0.009 per GiB-hour; idle not billed |
| Microsoft Foundry hosted agents | Per-session VM sandboxes; a Microsoft SDK sample | Python and C#; idle timeout up to 60 minutes | CPU and memory during active sessions |
When should you use Claude Managed Agents instead?
When you don't need to run the agent loop on your own infrastructure. Anthropic's hosting guide says exactly that, and its cookbook suggests looking at Claude Managed Agents first for a customer-facing chat product.
Claude Managed Agents, in beta, runs the agent loop and a sandbox for you, in Anthropic's cloud or your own. It charges model tokens plus $0.08 per session-hour, and time a session spends idle, waiting for your next message or a tool confirmation, isn't billed. Its cloud sandbox offers up to 8 GB of memory and 10 GB of disk. It isn't eligible for zero data retention or a HIPAA business associate agreement, and it runs Claude models only.
Self-hosting the SDK still wins when you need programmatic control. Anthropic's cookbook lists batch and job-shaped agents, internal tools, agents embedded in your own backend, and regulated environments. For a side-by-side of Managed Agents and the other hosted runtimes, see our guide to Claude Managed Agents alternatives.
Do you need to host an agent at all?
Not if the agent does your team's own recurring work rather than powering your product. A managed agent platform such as type.com runs a managed Claude or Codex agent with your connections, triggers, and run history, so there's nothing to host.
Many teams reach for the SDK to automate internal work: a weekly pipeline review, triage of new issues, research on inbound leads. Hosting it means running everything above for jobs that aren't your product.
type.com is built for that work. Each managed agent automation runs a managed Claude or Codex agent with the Space's connections, skills, and memory, plus an isolated Linux sandbox. Runs start from a schedule, Slack, GitHub, Linear, a webhook, email, or RSS, and each one leaves a thread the team can read. Connections stay on type.com's servers, and a scheduled instruction automation pauses after three failed runs in a row. Plans start at $50 a month for two members, including $100 of AI usage at provider rates.

Frequently asked questions
Can you self-host the Claude Agent SDK?
Yes. The Claude Agent SDK is a Python and TypeScript library that runs in a process you operate, usually one container per agent. Anthropic's hosting guide suggests starting at 1 GiB of RAM, 5 GiB of disk, and 1 CPU per agent, and its cookbook has examples for Docker, Modal, and Kubernetes.
How much does it cost to host the Claude Agent SDK?
Anthropic says a minimal container costs roughly $0.05 an hour and that token costs usually dominate by an order of magnitude or more. Managed cloud runtimes bill compute by the hour, for example $0.0895 per vCPU-hour by default on Amazon Bedrock AgentCore, plus your model usage.
Where are Claude Agent SDK sessions stored?
By default, as JSONL files under ~/.claude/projects on the machine running the agent. They don't survive a container restart, scale-down, or move to another node, so production deployments mirror them to shared storage with a SessionStore adapter. Anthropic ships reference adapters for S3, Redis, and Postgres.
Can I use a Claude Pro or Max subscription with the Agent SDK?
Not for a product you offer to others. Anthropic says that, unless previously approved, third-party developers can't offer claude.ai login or rate limits in their products, including agents built on the Agent SDK. Use an API key or Amazon Bedrock, Google Cloud, or Microsoft Foundry credentials.
Should I use Claude Managed Agents or self-host the Agent SDK?
Anthropic's own guidance is to consider Managed Agents if you don't need to run the agent loop on your own infrastructure. Self-host the SDK when you need programmatic control, such as batch jobs, internal tools, agents embedded in your backend, or regulated environments.
Do I need to host an agent to automate my team's work?
Usually not. Hosting the SDK makes sense when the agent is part of your product. For a team's own recurring work, a managed agent platform such as type.com runs a managed Claude or Codex agent with your team's connections, triggers, and run history, so there's no agent host to run.
