Claude Managed Agents is Anthropic's hosted runtime for long-running agent work. Use it when you want Anthropic to run the loop and session infrastructure for you. Stay on the Messages API or the Claude Agent SDK when you need tighter control over the loop or where the runtime executes.
As of April 10, 2026, the current contract is still in beta, billed on normal Claude tokens plus session runtime, and separate from Claude Code. The useful question is not whether Managed Agents sounds newer. It is whether your workload benefits more from Anthropic owning the runtime than from you keeping that control yourself.
Verification note: this guide was checked against Anthropic's current Managed Agents overview, quickstart, migration, pricing, memory preview, cookbook, and engineering pages on April 10, 2026.
TL;DR
| If you need... | Choose... | Why |
|---|---|---|
| Anthropic to host the runtime for long-running or asynchronous agent work | Claude Managed Agents | Anthropic manages the session runtime, built-in tool environment, and long-lived loop infrastructure |
| Your own custom loop, your own message history handling, or a thin low-level integration | Messages API | You keep maximum control over prompts, tool flow, state handling, and runtime behavior |
| Agent logic that runs inside your own process or deployment | Claude Agent SDK | You still use Anthropic models, but the runtime stays in your codebase and infrastructure |
| Local repository work, desktop delegation, or on-device workflows | Claude Code or other desktop surfaces | That is a different product route from Managed Agents, not another name for it |
The shortest honest answer is this:
- Choose Managed Agents when you want a hosted Anthropic runtime for work that may run for minutes or hours.
- Stay on the Messages API when you want to own the loop yourself.
- Choose the Claude Agent SDK when you want agent code and deployment to stay in your own process.
- Do not treat Claude Code as the same thing. If your real need is local coding workflow depth, the better follow-ups are Claude Code best skills and Claude Code best MCP servers.
What Claude Managed Agents actually is
Claude Managed Agents is Anthropic's hosted runtime for agentic work. The official docs describe it as a pre-built, configurable agent harness that runs in managed infrastructure and is best suited to long-running or asynchronous tasks. That is the key idea to lock in early. Managed Agents is not just a helper library, and it is not a desktop feature that reaches into your laptop. It is an API surface where Anthropic takes over more of the runtime machinery than it does on the Messages API.
In practice, Anthropic currently frames the product around four core objects: agent, environment, session, and events. The agent holds behavior and tool configuration. The environment defines what the hosted runtime can access. The session is the running unit of work. Events are how the session communicates progress and requests. Once you see those pieces together, the surface stops looking like a vague "AI agents" announcement and starts looking like a concrete runtime contract.
That contract is what separates Managed Agents from a hand-written loop. On the Messages API, you keep the conversation history, pass tool definitions, decide how the loop continues, and manage the runtime that executes tool actions. On Managed Agents, Anthropic hosts the session runtime and gives you a higher-level operating model. You still make important decisions about configuration, inputs, and custom integrations, but you no longer have to own every part of the long-running loop.
The distinction from the Claude Agent SDK is also important. Anthropic's migration guidance currently makes the difference explicit: the SDK runs in your own process, while Managed Agents runs in Anthropic-managed infrastructure. That does not make one universally better. It means they solve different runtime-ownership problems. If you want hosted runtime convenience, Managed Agents is the point. If you want your deployment to remain the runtime, the SDK is still the better route.
One more correction belongs near the top because the query often carries it in by accident: Claude Managed Agents is not Claude Code. Anthropic's own docs are explicit that partner products must not brand Managed Agents as Claude Code or Claude Cowork. If your real question is about desktop execution, browser use, or local repo autonomy, Claude Computer Use is the more relevant page.
When Claude Managed Agents is the right route
Managed Agents makes the most sense when the hard part of your problem is not model quality alone. It makes sense when the hard part is running a tool-using workflow over time without wanting to keep the whole loop and runtime scaffolding in your own code. Anthropic's public materials consistently point toward long-running, asynchronous, and stateful work as the sweet spot.
That usually means workloads like research agents, data-analysis agents, or internal automation flows that may keep working after the initial request is sent. The official cookbook's data-analyst example is useful here because it shows the product in a real shape instead of an abstract one. The value is not that Claude can call tools. You could already build that. The value is that sessions, environments, streaming events, and hosted runtime behavior are already packaged into the surface.
Managed Agents is also a strong fit when you want a hosted environment boundary rather than another self-assembled runtime. If your team wants Anthropic to manage more of the session lifecycle and built-in tooling context, the product becomes easier to justify. That is especially true when the work may sit idle, resume, or continue across a longer horizon than a simple request-response loop.
Another good fit is when your product logic needs the result of an agent run more than it needs custom ownership of every step inside the loop. If the main engineering goal is "get this hosted agent workflow to finish reliably, then react to the output," Managed Agents can reduce the amount of infrastructure you need to assemble around Anthropic models.
There is also a cost-of-complexity reason to prefer it. Many teams underestimate how much hidden engineering sits inside a serious self-managed agent loop: state management, long-running execution, tool retries, event streaming, session continuity, and environment lifecycle. Managed Agents is worth considering whenever you want to stop owning that machinery and are comfortable with Anthropic owning more of the runtime boundary.
When Messages API or the Claude Agent SDK is better
The easiest way to make the wrong decision here is to assume "more managed" automatically means "better." It does not. Managed Agents is a better route only when hosted runtime ownership is what you actually want. If you need a bespoke loop, unusual state transitions, or very specific orchestration logic, the Messages API remains the cleaner foundation.
That is because the Messages API is still the lowest-friction route for custom control. You decide how messages are stored, how tool calls are handled, how the loop advances, what fallback logic exists, and how the runtime behaves. That flexibility is expensive in engineering time, but sometimes it is exactly what the workload needs. If your product depends on a custom loop as a feature rather than as accidental plumbing, Managed Agents can feel too opinionated.
The Claude Agent SDK becomes the better route when your main requirement is not "host the runtime for me" but "let my own process remain the runtime." Anthropic's own migration guidance and cookbook make this boundary clear. The SDK is the route to prefer when you want agent logic, tool execution, deployment shape, and operational control to stay inside your own application or infrastructure.
Custom tools are another place where overclaiming hurts readers. Managed Agents does not mean "zero client logic forever." Anthropic's docs still show custom tools flowing through event handling. So if your application depends heavily on custom tool execution patterns, private services, or special event choreography, the cost of giving Anthropic the runtime may not buy you as much as it first appears.
A simpler rule works better than a long checklist:
- Choose Managed Agents when you want Anthropic to own more of the runtime.
- Choose the Messages API when you want to own the loop.
- Choose the Agent SDK when you want the runtime to stay in your own process.
If your real need is desktop coding help, file operations on your own machine, or repo workflows that stay local, that is still a separate branch. This is exactly why the page should not blur into Claude Code advice.
Pricing, beta access, and current boundaries
Managed Agents is easier to understand once you treat the current contract as a live beta surface rather than as a fully settled platform layer. Anthropic's current docs say the product is in beta and that requests require the managed-agents-2026-04-01 beta header. That detail matters, but it should stay in the right proportion. It is a current implementation fact, not the personality of the article.
The pricing model currently has two dimensions. First, you pay the normal Claude model token rates. Second, you pay session runtime while the session is in the running state. Anthropic's current pricing page lists that runtime at $0.08 per session-hour, metered to the millisecond, as of April 10, 2026. That does not sound dramatic until you notice what it means strategically: Managed Agents is not just a model choice. It is a runtime choice with its own operating cost shape.
That cost model is one reason to keep the route decision in front of the setup instructions. If your workload benefits from a hosted long-running session, the runtime fee can be worth the convenience. If your workflow is short, simple, or already well served by a custom loop in your own code, adding hosted session runtime may not buy enough.
Access and feature maturity also need careful wording. Anthropic's docs currently say Managed Agents access is enabled by default for Claude API accounts, but memory, multiagent, and outcomes remain research preview features with separate access requirements. That is a useful boundary for builders because it keeps the product from sounding more settled than it really is.
The same caution applies to rate limits. Anthropic currently documents create-endpoint limits of 60 requests per minute and read-endpoint limits of 600 requests per minute, with organization-level spend and usage tiers still applying. That is useful implementation context, but it belongs in planning and FAQ more than in the first screen.
The practical takeaway is simple: the product is real, the hosted-runtime contract is real, but some of the surrounding capability surface is still moving. Use exact dates for pricing, preview access, and beta-header details when they matter. Do not write those numbers as if they are timeless.
One practical example: a hosted data analyst workflow
The official data-analyst cookbook is the best way to make Managed Agents feel concrete without turning this page into a long tutorial. The example shows an agent working inside a hosted environment, reusing the environment, mounting files, streaming events, and producing outputs over a session. That is exactly the kind of workflow where the hosted runtime story starts to feel justified.
Why does this example matter? Because it shows the point of the product in operational terms. A data-analysis agent is often not a one-shot text completion. It may need to inspect files, run tool steps, continue over time, and return outputs after several stages. If you want Anthropic to own more of that session machinery, Managed Agents is a sensible fit.
The same example also clarifies the boundary. Anthropic explicitly says in the cookbook that if you need full control over the agent loop and deployment, the Claude Agent SDK is still the better route. That is not a footnote. It is the route-choice answer in plain English.
The fastest mental model is:
- Managed Agents when you want the hosted runtime.
- Agent SDK when you want to host and shape the runtime yourself.
- Messages API when you want the thinnest low-level path and you are comfortable assembling the rest.
If you only need one narrow setup sketch, the current Managed Agents flow looks like this: create the agent, create the environment, start the session, send events, and stream the results. That tells you almost everything important about the surface. It is not a chat-only API. It is a session runtime with a longer-lived operating model.
bashcurl https://api.anthropic.com/v1/agents \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-beta: managed-agents-2026-04-01"
That snippet is intentionally short because the bigger decision is not the curl syntax. The bigger decision is whether your workload wants this kind of hosted session runtime at all.
FAQ
Is Claude Managed Agents the same as Claude Code?
No. Managed Agents is an Anthropic API runtime surface. Claude Code is a separate local coding workflow product. Anthropic's docs explicitly warn partners not to brand Managed Agents as Claude Code or Claude Cowork.
When should I choose Managed Agents over the Messages API?
Choose Managed Agents when the main value is Anthropic hosting more of the long-running loop and session runtime for you. Stay on the Messages API when you want to keep full control over the loop, message history, and low-level orchestration.
When is the Claude Agent SDK better?
The SDK is better when you want the agent runtime to stay in your own process or deployment. Anthropic's migration material currently draws that boundary clearly: the SDK runs in your environment, while Managed Agents runs in Anthropic-managed infrastructure.
Does Managed Agents mean Anthropic handles everything, including my custom tools?
No. Managed Agents handles more of the hosted runtime, but custom tool flows can still require client-side event handling. Do not describe it as "fully managed everything."
How does pricing work today?
As of April 10, 2026, Anthropic's pricing page says you pay normal Claude model token rates plus $0.08 per session-hour while a Managed Agents session is running. Treat that number as a current verified fact, not a timeless one.
Are memory, multiagent, and outcomes generally available?
Not broadly. Anthropic's current docs treat those as research preview features with separate access requirements. That means the core runtime is usable now, but some surrounding capabilities are still preview-only.
Are there current rate limits I should know about?
Yes. Anthropic currently documents 60 requests per minute for create endpoints and 600 requests per minute for read endpoints on Managed Agents, with organization-level limits still applying. That matters for production planning, but it should not be the reason you choose the surface.
The real decision is who should own the runtime
Claude Managed Agents is worth your attention because it is not just another naming layer on top of Anthropic's existing APIs. It is Anthropic's current hosted-runtime answer for long-running agent work.
That still does not make it the default answer for every builder. If your advantage comes from custom loop control, keep the Messages API. If your deployment must stay in your own process, keep the Agent SDK. If you want Anthropic to own more of the session runtime and you are comfortable with the current beta boundaries, Managed Agents is the right route.
Once you frame the product that way, the topic gets much simpler. The useful question is no longer "What are managed agents?" The useful question is "Do I want Anthropic to own this runtime, or do I need to keep that ownership myself?" That is the decision this page exists to solve.