Hacker News

kmansm27
Show HN: Omnara – Open-source alternative to Claude Managed Agents github.com

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!


piterrroa minute ago

My setup is Hermes on a beefy machine with running a swarm of pi.devs - connects to GH issues via bot app so I can call it @xxxx in the issue. It can create PR, run actions and all. If I want to see the code I just run kilo code in VS locally.

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!

renegat0x0an hour ago

There is so much stuff in AI space. AI orchestrators, automations, harnesses. I often can't tell what is the difference between projects.

I started thinking is it something like 'ruflo', or 'mirofish', or is it something else totally

swyx7 hours ago

isehgal7 hours ago

thanks swyx! the log is the agent is a core insight behind this

swyx7 hours ago

you beat pi-durable to it!

kmansm27op7 hours ago

haha yes! this was the reasoning for making durability native in our harness

asar2 hours ago

I've built sth similar that acts as a mobile interface to your desktop setup via the multiplexer of your choice (herdr/tmux/zellij). https://github.com/AltanS/collie

There's also a typescript SDK to connect a durable agent/harness to the app, still experimental though.

asherdale17 hours ago

feels like everyone is converging on durable agents lately: pi durable, cloudflare agents on durable objects, vercel's durable harness

kmansm27op7 hours ago

Yep, I think that all harnesses will require native durability, and pi-durable is a step in the right direction. I'm skeptical of bolted-on durability, like vercel's durable-harness, because they have to neuter the harness for things they can't reliably make durable (e.g. https://github.com/vercel-labs/durable-harness/blob/fb056a3c...)

aquarkan hour ago

It's late, but I'm not grokking this:

> 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?)

kmansm27op11 minutes ago

[dead]

Nischalj102 hours ago

been following you guys from distance over x. congrats on the launch! excited to see where this goes

ksajadi3 hours ago

looks cool. how's that different from things like markbase dispatch where you can fire up the agent remotely with some given context. i mean what is the advantage of having the agent run always vs start and stop when you need it but give it a long-term memory context? maybe i'm missing something.

kmansm27op6 minutes ago

not sure I fully understand the question, but in Omnara, the agent isn't always "running". When it's idle (e.g. waiting for user input, or tool results), the agent is just rows in postgres with nothing happening to them. When a tool result returns or a new input comes in through the API, then a worker is allocated to the agent and starts "running" the agent again.

rohan_joshi6 hours ago

i was looking for good self-hostable durable agents to automate a persistent keyword watcher across sm. gonna give this a go. any pointers you recommend?

isehgal5 hours ago

nice, this is close to something we run ourselves. we put up examples of sm agents that scan socials daily for keywords and DMs us (docs here https://docs.omnara.com/examples/x-signal-agent). probably the fastest starting point is to point your agent to it and ask it to swap in your keywords

rohan_joshi4 hours ago

looks great

divamgupta4 hours ago

Wow Literally what I was looking for.

khalidsaidian hour ago

[flagged]

alexcodebytes3 hours ago

[flagged]

singh_abinashi7 hours ago

[flagged]

hn-front (c) 2024 voximity
source