Show HN: Omnara – Open-source alternative to Claude Managed Agents
Posted by kmansm27 18 hours ago
Hey all, Kartik from Omnara (https://omnara.com) here. We're building an open-source API for running durable agents. You create an agent with an API call, and Omnara runs the agent loop, gives the agent sandboxes to run commands in, and handles secrets, permissions, and RBAC. Each agent's state is stored in Postgres, so agents survive restarts and cost nothing while idle. You can message them and stream their events over the API.
You may remember us from our early days, when we made a remote-control phone app for Claude Code and Codex. Since the harness ran on a laptop back then, we had to build a relay to reach it, it stopped when the laptop closed, and moving it to a cloud sandbox meant syncing code and agent state between machines. We didn't think remote-controlling a local agent was end-game for how people would run agents, so we built a new product where the agent runs in the cloud, any client can talk to it through an API, and it can still use your laptop as one of its machines.
Anthropic and OpenAI are building hosted versions of this, like Claude Managed Agents and the OpenAI Agents API. Omnara is an open-source version you can run on your own servers and use your own models. It's basically a harness server like the opencode or codex servers, but durable, scalable, with the usual harness features like file and shell tools, subagents, compaction, permission prompts, MCP, skills, memory, yada yada yada.
Here's some interesting architectural decisions we made while building this out:
Most harnesses, like Claude Code, Codex, OpenCode, Pi, Goose, etc, run the agent loop in one long-lived process that keeps its log in a JSONL or SQLite file. In Omnara, the log is an append-only event log in Postgres, with inputs, model outputs and tool calls stored as typed rows in their own tables. The loop runs on stateless workers in the control plane. A worker runs one iteration of the loop, either a model call or the tool calls it produced, then releases the agent and puts the next iteration on a queue in Postgres. Whichever worker is free picks it up, so each iteration of an agent's loop can run in a different process on a different machine. Each iteration's result commits in one transaction, so the model output, its tool calls, usage and the next wakeup are saved together or not at all. If a worker dies mid-iteration, nothing commits, its lease expires, and another worker retries it. Agents waiting on a user, a tool or a retry don't hold a worker, so one worker can multiplex thousands of agents.
Also unlike other harnesses, the machines that the workers (our agent loop) run on aren't where the agent runs its commands. Instead, any macOS or Linux machine with an internet connection, like your laptop or any cloud sandbox, can run a small daemon (omnarad) that connects out to Omnara, so it doesn't need any open inbound ports. The agent then gets tools for that machine, like running a command or editing a file. An agent can have any number of machines connected to it. A fun thing I like to do is I have my laptop and a cloud sandbox connected to the same agent, so when my laptop is on, my agent codes there and I can interact with it, and I have it often push to Github. When I close my laptop, my agent sees the laptop went offline, pulls the latest changes to its cloud sandbox, and continues there.
The entire codebase is open source at https://github.com/omnara-ai/omnara, and it’s self hostable, even on a single machine with docker compose. You can also use the hosted version at https://omnara.com. Let me know what you think!
Comments
Comment by piterrro 4 hours ago
This setup is so plain and simple that it just works, and it works wonders. I feel like I’ve been running a dev team who actually communicates through issuess and keeps it up to date!
Comment by daitangio 3 hours ago
Comment by piterrro 2 hours ago
Do you think it would make sense to create a blog post out of it?
Comment by rbarrosoPT 1 hour ago
Comment by swyx 11 hours ago
Comment by asherdale1 11 hours ago
Comment by kmansm27 11 hours ago
Comment by Nischalj10 7 hours ago
Comment by isehgal 4 hours ago
Comment by asar 6 hours ago
There's also a typescript SDK to connect a durable agent/harness to the app, still experimental though.
Comment by renegat0x0 6 hours ago
I started thinking is it something like 'ruflo', or 'mirofish', or is it something else totally
Comment by kmansm27 4 hours ago
What we've settled on is that Omnara is a tool for building agents. It's for people putting agents into their own products or workflows using the API. If you're not going to use the API, you probably don't need Omnara. Think of it like Supabase, Supabase gives you a Postgres database behind an API, and the dashboard is there for convenience, but your app talks to the API. Omnara does the same for agents. The UI is handy for watching and poking at agents, or visual analytics, but the API is the main product.
Or more directly, you can think of it like the codex app server or opencode server. Their clients (e.g. the TUI and desktop apps) talk to that server to start and interact with agents. Omnara is the same kind of server, except it runs in the cloud or on your own servers instead of your laptop. We don't provide a client though, you build that.
Comment by barries11 4 hours ago
Comment by kmansm27 4 hours ago
Comment by ksajadi 7 hours ago
Comment by kmansm27 5 hours ago
Comment by aquark 6 hours ago
> The loop runs on stateless workers in the control plane. A worker runs one iteration > of the loop, either a model call or the tool calls it produced, then releases the > agent and puts the next iteration on a queue in Postgres. ... > Also unlike other harnesses, the machines that the workers (our agent loop) run on aren't > where the agent runs its commands.
It's late but don't think I am grokking this.
Isn't running the commands the heavier part of the work? The agent loop itself is mostly waiting for a remote model and then running the commands?
Why would I need a pool of workers for the loop when the constraining resource is likely to be the machines I am running the commands against (which can't be stateless like the workers are?)
Comment by kmansm27 5 hours ago
You don't! You can have a single worker running thousands of agents at once, since they're mostly waiting on the model. You can add more workers for scaling to even more agents, and for redundancy (if one worker goes down, another one can keep the agents going)
The machines are the expensive part (after tokens, of course), which is why we split the execution environment machine from the agent loop. Most harnesses run the loop on the same machine as the shell tools, so every agent needs its own VM for its entire life, even though it spends most of that time waiting on the model or tools or external inputs. Because they're decoupled in Omnara, an agent can use 0, 1, or n machines. Agents whose workloads don't need a machine can go without one entirely, and an agent's machine can sleep or go offline without stopping the agent.
Anthropic has a good post on this architecture: https://www.anthropic.com/research/managed-agents
Comment by rohan_joshi 10 hours ago
Comment by isehgal 10 hours ago
Comment by rohan_joshi 8 hours ago
Comment by divamgupta 9 hours ago
Comment by tapeo 44 minutes ago
Comment by khalidsaidi 5 hours ago
Comment by singh_abinashi 11 hours ago
Comment by alexcodebytes 7 hours ago