All guides
By Kartik Sarangmath

Migrating from Claude Managed Agents to Omnara

What you're really moving, how each concept maps, and what to test before you switch

Claude Managed Agents is Anthropic's hosted service for running Claude as an agent. You define an agent once, start a session for each task, and Anthropic runs the loop, the sandbox, and the event stream. For a Claude-only prototype, that's a lot of work you never have to do yourself.

Teams start looking elsewhere for a few recurring reasons. The service only runs Claude 4.5 and later, so a second model provider is off the table. Sessions live on Anthropic's servers, and self-hosted sandboxes move only the commands to your machines. Running the whole service yourself takes a request to Anthropic's account team.

Cost and control come up too. The $0.08 runtime fee becomes most of the bill for long-running agents on small models. Once a session starts, its model, system prompt, and skills can't change.

None of this means starting over. Agents on any platform share the same shape, so most of a migration is renaming concepts and rewriting a handful of API calls.

What You're Actually Moving

In Claude Managed Agents, an agent is a versioned config with a model, a system prompt, tools, MCP servers, and skills. A session is that config running in an environment, and everything it does is recorded as events in its history. If you think of a session as its log, the move gets simpler, because you're bringing over configs and, where you need them, logs.

Omnara is built from the same two pieces under slightly different names. What Anthropic calls a session, Omnara calls an agent, which is one durable conversation with its config, tool calls, and history. You launch one per customer, ticket, or thread.

What Anthropic calls an agent becomes a config, written as immutable YAML or JSON, plus a profile that gives the current config a stable name. The rest of the vocabulary maps closely:

Claude Managed AgentsOmnara
Agent, with versionsConfig, named by a profile
SessionAgent
EnvironmentMachine sources in the config
user.message and user.interruptInputs, and stopping current work
Event streamEvent timeline, with a stream that resumes after a reconnect
Agent toolsetBuilt-in tools such as run_command, web_search, and web_fetch
Custom tools, MCP servers, skills, memory storesThe same four, declared in the config
VaultsSecrets granted to projects
Permission policies and tool confirmationsPermissions and approvals
MultiagentSubagents
Scheduled deploymentsCron triggers
WebhooksEvent webhooks
Session budgetsUsage and cost per agent, project, and organization

Where the Work Runs

An environment in Claude Managed Agents describes a sandbox. In Omnara, machines are separate from the agent, and a config lists where its commands can run. That can be a machine pool of sandboxes from providers like E2B, Daytona, and Modal, or your own computers connected through omnarad, a daemon that only makes outbound connections.

The daemon plays the part of a self-hosted sandbox. Because a config can list several machine sources, an agent keeps going when one of them goes offline. On Omnara Cloud, a default-pool of managed sandboxes is ready from the start, so most teams begin there and connect their own machines later.

Tools, Credentials, and Approvals

Custom tools carry over almost field for field. Each keeps its name, description, and input schema, gains type: custom, and runs in your own backend, which answers the call through the API. The agent toolset becomes Omnara's built-in tools, where run_command handles shell work, including reading and editing files on the agent's machine.

MCP servers move into the config's mcp: block, and servers that use OAuth connect through a built-in OAuth flow. Their credentials stay on Omnara's workers, so they never reach the agent's machine. Skills upload as folders with a SKILL.md, and memory stores become project stores the agent reads and writes with its file tools.

Vaults are the piece that changes shape the most. Anthropic attaches a vault to each session, so one agent definition can act for many users. In Omnara, a config references secrets by ID, so your backend launches each customer's agent from a config that points at that customer's secrets. Vault values are write-only, so take each credential from its original source rather than from Anthropic.

Permission policies copy straight across. always_allow and always_ask exist on both platforms, a tool set to auto becomes one or the other, and Omnara adds always_deny. Omnara also applies permissions to custom tools, so the platform can hold a call into your own system until a person approves it.

Schedules, Webhooks, and Spend

A scheduled deployment becomes a cron trigger, which can launch a fresh agent from a profile or message one that already exists. Subagents are declared under subagents: in the config, each launched from a profile or a copy of the parent.

Webhooks get richer. Claude Managed Agents sends an event's type and ID for you to fetch, while Omnara's event webhooks carry the whole event, signed if you set a secret and retried for up to ten minutes.

Spending limits move from the session to the customer. A session budget stops one session at a limit Anthropic enforces. Omnara's usage API reports tokens and provider-reported cost per agent, profile, project, and organization, so your app sums it per customer and stops agents at the limits your plans set.

The Loop and the Models

Omnara runs its own agent loop instead of Anthropic's harness. On Terminal-Bench 4.0 with Claude Opus 5.5, Omnara scored 69.6% to 65.8% for Claude Code, Anthropic's own harness. It also ran 12% faster and 5% cheaper. Terminal-Bench's own runner graded every run, and the traces and harness are public.

You can keep Claude through your own Anthropic key or Amazon Bedrock, and add models from OpenAI, OpenRouter, or any compatible endpoint, including models you host. Each subagent can use a different one, so a small model can triage while Claude handles the hard steps.

Moving One Agent

Move one agent end to end before the rest. Create an Anthropic model provider with your own key, store each credential as an encrypted secret, and then write the agent's config. Here's a support agent with web search and one custom tool:

yaml
version: v1instruction: You help customers with their orders.model:  provider_config: anthropic-prod  name: claude-opus-5-5tools:  web_search: {}  get_order:    type: custom    description: Look up an order by its ID.    input_schema:      type: object      properties:        order_id: { type: string }      required: [order_id]machine_sources:  - machine_pool_name: default-pool

There's no separate environment to create, because the config names its machine pool, and listing one adds run_command and the other machine tools. With the config saved, the calls your app makes most often look like this in Omnara's TypeScript SDK:

ts
const config = await sdk.createAgentConfig({  client, path: { orgID, projectID },  body: { source: await readFile('agent.yaml', 'utf8'), source_format: 'yaml' },})const profile = await sdk.createAgentProfile({  client, path: { orgID, projectID },  body: { name: 'Order Support', config: config.data.id },})
// One agent per ticket, where you used to create a sessionconst launched = await sdk.createAgent({  client, path: { orgID, projectID },  headers: { 'Idempotency-Key': 'ticket-1042' },  body: { profile: profile.data.id, message: 'Where is order 1042?' },})const agentID = launched.data.agent.id
// Follow-up messages and the event streamawait sdk.createAgentInput({  client, path: { orgID, projectID, agentID },  body: { content_blocks: [{ type: 'text', text: 'It was due Tuesday.' }] },})for await (const frame of openAgentEventStream({ client, path: { orgID, projectID, agentID } })) {  render(frame)}

The launch carries the first message, and an Idempotency-Key such as your ticket ID makes a retried launch return the same agent. To correct an agent while it works, send an input with delivery_mode: 'steering', and it arrives at the next model call.

Custom tools and approvals are where your backend changes the most. Instead of watching the stream for agent.custom_tool_use, a custom tool worker picks up calls that are waiting for you, runs your function, and posts the result. Omnara accepts only the first result for each call, and approvals arrive as interactions your app lists and resolves, from your own UI or from Slack.

What to Test Before You Switch Traffic

The failure behavior is where the two platforms differ most, so break things on purpose before real users arrive.

Start by changing a running agent. In Claude Managed Agents a session's model and prompt are fixed, while in Omnara you post a new config to a running agent and it applies at the next model call. Updating a profile leaves running agents alone, the same way a new agent version leaves running sessions alone.

Then kill a worker mid-task. Every step is saved to Postgres, and another worker continues from the last saved step. A call to an MCP server or the web that the crash cut off isn't rerun, and the agent is told its outcome is unknown, so watch it check the call before it acts again.

Drop the stream in the middle of a turn, too. A Claude Managed Agents stream only carries events emitted after it opens, so reconnecting means listing the history and skipping what you've seen. An Omnara stream resumes from the last saved event, and live text previews aren't replayed, so confirm your app re-reads any tool calls still waiting on it.

Finally, check the separation between customers. Pass an actor with each input to record which of your users spoke. For a hard boundary, give each customer a project and an org API key with a role on only that project, then confirm the key can't read another customer's agents.

Keeping Your Session History

Export before you delete anything, because deleting a session removes its events, its sandbox, and the files it produced. GET /v1/sessions/{id}/events returns a session's full history, and ant beta:sessions:events list --session-id "$SESSION_ID" --format jsonl writes it as JSON lines. Keep the exported events in your own storage for audits and support.

Download output files from the session's file list as well. A sandbox's state is kept for only 30 days after it's created, so copy out anything else the agent left there before then.

Memories can be read and exported through the API, so you can copy each one into a project memory store. To continue an old conversation, launch a new agent with a summary of the session, or its last few turns, in the first message. From then on, the agent's timeline holds its whole history.

Where to Run It

On Omnara Cloud, there's nothing to operate and no platform fee, and your own model keys and machines cost nothing. Models bought there cost the provider's token rates, and managed machines are billed by usage. Both are paid with credits that carry a 5% service fee covering provider costs.

Self-hosting is free under Apache 2.0 and runs the whole platform, including the agent loop and transcripts. It runs on Postgres, Redis, S3-compatible storage, and a shared filesystem. Anthropic's own self-hosted version comes by request and runs only Claude, while Omnara is a public download that runs any model.

Omnara's team can also deploy and manage it in your own cloud (BYOC) or on premises, with SSO, audit logs, and custom SLAs. To set that up, book a call with the founders.

You can export all your data at any time, including every agent's full history, and run it on your own self-hosted Omnara by emailing [email protected].

If you're moving for model choice, your own infrastructure, cost, or control, choose Omnara. It runs any model and self-hosts in full, including the agent loop. You can also change a running agent without restarting its conversation, and approvals can guard your own tools.

Claude Managed Agents Alternatives compares the other options.

FAQ

How much code changes when I migrate?

You rewrite the API calls, but each concept has a close counterpart. Sessions become agents, agent definitions become configs and profiles, vaults become secrets, and scheduled deployments become cron triggers. Most of the work is mechanical.

What does a Claude Managed Agents session become in Omnara?

It becomes an agent, which is one durable conversation with its config, tool calls, and history. You launch it from a profile or a config, and it can use several machines without being tied to any of them.

Can I keep using Claude after migrating?

Yes. Connect your Anthropic key or Amazon Bedrock as a model provider and name a Claude model in the config. Other agents and subagents can use models from OpenAI, OpenRouter, or any compatible endpoint.

How do I keep my Claude Managed Agents session history?

List each session's events through GET /v1/sessions/{id}/events or the ant CLI, download its files, and copy memories out through the API before deleting anything. Keep the export in your own storage. To continue a conversation, launch a new agent with a summary in its first message.

Is there an open-source alternative to Claude Managed Agents?

Yes. Omnara is an open-source managed agent platform under Apache 2.0 that covers the same concepts on any model. You can use Omnara Cloud, or self-host all of it for free.