Claude Managed Agents

With the Agent SDK, the agent loopThe repeating cycle where the model reads context, calls a tool, reads the result, and decides what to do next until the task is done runs in your process, on your machine. Claude Managed Agents flips that. You define the agent once, and Anthropic runs the loop, the sandboxAn isolated, locked-down environment where the agent can run code and edit files without affecting your real systems, and the tools server-side. You send it messages and stream results back over a REST APIA web API style where you act on resources like agents and sessions using standard HTTP requests. This guide covers when that trade is worth making and how the pieces fit.

Managed Agents is a beta product and moves quickly. Treat the specifics here as the shape of the thing, and confirm exact fields, headers, and pricing against the current API docs before you build.

What is the difference between self-hosted and managed agents?

The two approaches answer different questions.

The Agent SDK runs the loop in your code. You own the process, the file system it works on, and the session files. It is the right call for local development, CI, and automation where you want the data to stay with you.

Managed Agents runs the loop in Anthropic's infrastructure. There is no loop to operate and no sandbox to run; you make API calls and stream events. It is the right call for long-running, autonomous work in production where you would rather not run the machinery yourself.

What are the core concepts of a managed agent?

A managed agent is built from four pieces:

• Agent · the persisted configuration: model, system promptThe always-on instruction that sets the agent's role and rules before any user message arrives, and the tools it can use. You create it once and reuse it.
• Environment · the sandbox the agent runs in, cloud-managed or self-hosted, with its own networking rules.Common gotchaThe unrestricted networking in the example is fine for a demo but risky in production: a prompt-injected agent can reach internal services or send data out.Scope the environment to only the hosts it needs before you ship.
• Session · a running instance of an agent in an environment. It holds the conversation, the sandbox file system, and the event log, and it can be paused, resumed, or interrupted.
• Events · the two-way messages. You send user events in; you stream the agent's messages, tool calls, and status back out.

A session moves through a small set of states over its life:

How do I define and run a managed agent?

The flow is: create the agent, create the environment, open a session, then stream events. Using the Python SDK it looks roughly like this:

from anthropic import Anthropic
 
client = Anthropic()
 
agent = client.beta.agents.create(
    name="Coding Assistant",
    model="claude-opus-4-8",
    system="You are a careful coding assistant.",
    tools=[{"type": "agent_toolset_20260401"}],
)
 
env = client.beta.environments.create(
    name="cloud-sandbox",
    config={"type": "cloud", "networking": {"type": "unrestricted"}},
)
 
session = client.beta.sessions.create(agent=agent.id, environment_id=env.id)
 
with client.beta.sessions.events.stream(session.id) as stream:
    client.beta.sessions.events.send(
        session.id,
        events=[{"type": "user.message",
                 "content": [{"type": "text", "text": "Write a Fibonacci script."}]}],
    )
    for event in stream:
        if event.type == "agent.message":
            print(event.content[0].text)
        elif event.type == "session.status_idle":
            break

The toolset gives the sandboxed agent file operations, a shell, and web access, and you can connect MCPModel Context Protocol, an open standard for plugging external tools and data sources into an agent servers for anything else, the same protocol from the previous phase.

Scheduling and events

Because the session lives server-side, two things become easy. An agent can run long: minutes or hours of autonomous work, paused and resumed without you holding a process open. And it can run on a schedule: managed deployments can fire sessions on a cronA time-based schedule, like run every hour or every night at 2am, named after the classic Unix scheduler without you operating a scheduler. You create one session per user and resume by id to keep their contexts separate.

How much do Claude Managed Agents cost?

Cost has two parts: the usual per-token model charges, plus a charge for the time a session is running. That runtime charge is the thing to watch, because a long-lived idle session still costs. Stop sessions when they are done, set budgets, and delete sessions and uploads you no longer need.Common gotchaComing from the token-billed Messages API, it is easy to assume "no requests means no bill" and leave sessions open between turns.A managed session keeps its sandbox alive and charges for that wall-clock time even while it sits idle, so a forgotten session can quietly run up hours of runtime. Pause or stop the session as soon as a turn finishes, and resume by id when the user comes back.

The full event log is persisted, so you fetch a session's history through the API and stream its events live to your own logging or alerting. There is no built-in dashboard; you build observability on the event stream.

Which option should I use?

A quick way to choose across the three options in this phase:

• Messages API · you implement the loop yourself. Most control, most work. Good for simple request and response.
• Agent SDK · the loop runs in your process. Good for local development, CI, and keeping data on your side.
• Managed Agents · the loop runs in Anthropic's cloud. Good for long-running, scheduled, autonomous production agents you would rather not host.

Pick the lightest one that does the job. That is the same instinct the final phase applies to whole systems at scale.