If you build only on Claude, Claude Managed Agents is the hosted harness to use. Here are the five cases where you need something else, checked against Anthropic's docs.
Disclosure: I work on Gobare, one of the alternatives below. I've quoted Anthropic's documentation rather than paraphrasing it, and there's a section on where we're weaker.
When to stay
Claude Managed Agents gives you a lot that is hard to build yourself:
- Versioned agent configurations.
- Sandboxes that run in "an Anthropic-managed cloud sandbox, or a self-hosted sandbox on your own infrastructure".
- Scheduled deployments for cron-style runs, and per-session spend budgets.
- Full checkpoints. When a session goes idle, "its sandbox is checkpointed, preserving the full sandbox state, including the filesystem, installed packages, and any files the agent created."
- Published pricing: "$0.08 per session-hour", and "Runtime is measured to the millisecond and accrues only while the session's status is
running."
If none of the checks below applies to you, stop reading and stay.
Check 1: does the model have to be something other than Claude?
Anthropic describes the product as the harness "for running Claude as an autonomous agent", and the setup guide says "Claude 4.5 and later models are supported."
If your evals pick DeepSeek for bulk turns, a customer mandates a provider, or you route by cost, the harness can't run it. This is the most common reason people search for an alternative, and the simplest to test: list the models your product needs in a year.
Check 2: do you need to read or change the agent loop?
You configure the system prompt, tools, MCP servers and skills. How tool calls are dispatched, how errors are recovered and how context is compacted runs on Anthropic's side.
Most teams never need to see that code. If you've ever had to step through a harness to understand why an agent looped, you'll know whether you're one of the teams that does.
Check 3: can your webhooks afford to drop an event?
This one surprised me. Anthropic's webhook docs say: "Anthropic makes up to three delivery attempts", and after the last one "the event is dropped: it isn't queued for later delivery and there's no signal that it was lost." They also recommend reconciling by listing or fetching the resource through the API.
That's a reasonable design, and it's documented honestly. It does mean that if a webhook triggers billing, a database write or a user notification, you need a polling reconciler next to it. Check whether you've built one.
Check 4: will someone need a shell in the running machine?
When a long agent run gets stuck on a broken native dependency or a hung background process, the event stream often isn't enough. I didn't find a documented way to get an interactive shell into an Anthropic-managed cloud sandbox. With a self-hosted sandbox the machine is yours, so you can get in, but then you run the compute.
Check 5: does compliance require Zero Data Retention?
Anthropic is direct: "Managed Agents is not currently eligible for Zero Data Retention or HIPAA Business Associate Agreement (BAA) coverage", because sessions store their history, sandbox state and outputs.
No hosted alternative I know of fixes this, including ours. If ZDR is a hard requirement, self-host.
If you hit one: three routes
| Who runs it | Models | Fixes | |
|---|---|---|---|
| Stay on Claude Managed Agents | Anthropic | Claude 4.5+ | None of the five, but it's the best at everything else |
| Self-host open source (OpenMA, open-managed-agents, AstraBox) | You | Any | Any of the five, because the code, the machines and the data are yours; you run the platform |
| Hosted runtime with your own key (Gobare) | Gobare | Nine providers plus any OpenAI- or Anthropic-compatible endpoint | 1, 3 and 4; for 2 you can read the loop but not change it |
For the self-hosted route, OpenMA (Apache-2.0) describes itself as "an open-source alternative to Claude Managed Agents and OpenAI Agents API" and also offers a hosted version. open-managed-agents (AGPL-3.0) adds org, team and RBAC governance.
On the hosted route, what Gobare does for checks 1 to 4: you connect a key from any supported provider and it never enters the sandbox. The harness is pi, which is open source and runs unmodified. Webhooks are retried six times over roughly nine hours, with dead-letter tracking. An engineer can ssh -p 2222 s-$SESSION@ssh.gobare.dev into the session's machine, after registering a key in the Console.
Where Gobare is weaker
Before you switch to us, know what you give up:
- No self-hosted sandboxes, no scheduled runs, no per-session budgets, no multi-agent threads.
- Saved agents aren't versioned.
- Snapshots are best-effort: no
.git, nonode_modules, skipped above 300 MB, and running processes aren't kept. - A sandbox is reclaimed two hours after it was created, paused time included, and a running turn is interrupted. Sessions with a published address or an open SSH connection are exempt, and the next input starts a fresh sandbox from the snapshot.
- 10 session creations per minute per token; 25 concurrent sessions per organisation by default.
- We also store the transcript, so we're not ZDR either.
- Pricing isn't published yet. It's free while in alpha, with no margin on tokens.
The short version
Run the five checks. If none applies, stay on Claude Managed Agents. If check 5 applies, self-host. If only checks 1, 3 or 4 apply and you'd rather not run a platform, a hosted runtime on your own key is the middle route.
The full comparison, with a concept map from Managed Agents primitives to another runtime and side-by-side requests, is on gobare.dev.
Which of the five made you look for an alternative, or is there a sixth I've missed?
Top comments (0)