kmansm27

Nothing special with caching in Omnara, works pretty much the same way as any other harness (we do pretty much what pi/opencode/goose do) since the cache lives on the provider's side. We rebuild the model request by reading from postgres instead of jsonl or sqlite, and the rest is the same as any other harness.

Yeah, even as someone building in the space, I sometimes get confused on what and who I'm actually building for.

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.

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.

> 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

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

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

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

Agree, as long as models are interchangeable, it doesn't make sense to be locked into a single lab's managed agent platform. You probably want to swap between models and own the agent state.

https://github.com/omnara-ai/omnara - this is a self hostable agent API that I'm working on. It stores the state of all agents in a postgres db you can easily query, rather than a local json file or sqlite file per agent.

I can use the same system prompt and tools to Pi or OpenCode or Codex, so I'd say they're independent of the harness.

From these comments, it seems like people still don't understand what harnesses are... The point is you shouldn't build a harness, you should use a harness and change its system prompt, the tools it has, MCPs it has, give it skills, etc, to make it work for your usecase. You aren't "building a harness on top of pi" if all you're doing is the above. You're just using the harness to connect different things to the LLM.

Just fixed this issue! Seemed to occur on web, thanks for reporting this!

Yep, you're right, we don't have E2EE period (and we don't claim to have it anywhere), for the reasons I mention above (our cloud sandbox agent and voice agent need plaintext messages, so we'd need access to the keys, which defeats the purpose of E2EE). Apologies for the incorrect wording!

We have voice support for this exact reason! Not sure if I'd want to enable people vibe coding from their car dashboard xD

Haha glad to hear that you used Omnara before. In the old version, we were directly parsing the terminal output, which was really hard to maintain. But that meant you could use the Claude Code CLI directly in your terminal, and have the same session appear in your phone.

Now we use the Claude Agent SDK (basically a headless version of Claude Code), and we make our own UI for laptop and mobile. This is way easier to maintain than the previous solution we had. You can import Claude Code CLI sessions into Omnara, but you cant see a 1:1 realtime Claude Code CLI session in Omnara anymore. But we think that a GUI is a better experience than the CLI anyways for managing a bunch of agents.

Haha yeah, we love happy, seems like you guys are popular in this thread :)

This sounds solid, similar stuff to what we do! Sounds like this setup gets you most of the way there. We also have a mobile app + notifications. And I haven't tried using a coding voice agent via MCP, I'll try that out soon!

You should be able to use Omnara for that use case, unless I'm misunderstanding something

Thanks!

Awesome, that's the exact reason we built this!

Is it possible to completely disable or not use the remote sandbox features? I would never use them and would prefer my code stays on my device.

Yes, the remote sandbox feature is disabled by default, and you have to manually enable it for the syncing to start.

For those of us that are using subscriptions, does it show our remaining usage? I would hate to run out of tokens in the middle of a session.

Currently Omnara doesn't show your usage limits, you would have to check that at claude.ai. I'll look into add that though.

One feature of the CC TUI I sorely missed on mobile is the ability to look up and directly reference files via “@“. Is any functionality like this planned?

Yes, this exists in Omnara already!

Are there any plans to offer a cheaper tier for those of us that just want to run this on our own machines?

That's a good idea, we'll think about doing this where we don't offer sandbox + voice, and just have the messaging service.

Looking into this, will fix this soon! GitHub auth should be working on the web app, if you try there (assuming you got this error on mobile). You can continue to use Omnara normally without signing into GitHub, you just won't be able to use the cloud syncning feature til you auth with GitHub.

Replying to your latest comment here:

What do you mean by syncing? Happy coder syncs sessions between all my happy coder clients. I can even see in real time how happy coder in my browser's conversations progress as well as on my phone, in parallel.

Omnara also displays realtime conversations between all Omnara clients. What I mean by syncing is syncing your conversation and code changes to a cloud sandbox, which is useful if you're using Omnara on your laptop and you close your computer (as explained in the original post). If you run your agents on a persistent cloud VM, then this is less of a value add.

I can voice chat with Happy coder.

We use https://docs.livekit.io/agents/ which runs the voice agent in the cloud (to enable the above use case, and a better experience when you're using your phone when it's off), whereas I believe happy runs a client-side voice agent.

I mean messages drop or stall, or syncing doesn't work, or I can't get through setup at all. But I'm sure all these solutions have improved greatly since I've tried them, I tried these things much earlier on. If hapi works perfectly for you, then maybe Omnara wouldn't be much of a value add. Are there any pain points you face with hapi?

Thanks! And yeah it's definitely something we think about very often, we're coming up with ways to differentiate ourselves.

Two of the main feature's we're investing heavily into are remote sandboxes + syncing, and voice agent support, wouldn't work with E2EE.

We use the Claude Agent SDK and the Codex App server, which makes it easier to maintain (we used to parse out the literal terminal when we first launched, which was not maintainable - https://news.ycombinator.com/item?id=44878650). There's also ACP (https://agentclientprotocol.com/get-started/introduction) which we'll probably integrate eventually, which should make it easier to manage all the harnesses.

Yes, they have E2EE, but it comes with some limitations in the features they're able to provide.

I haven't tried out https://hapi.run/, but I've tried similar things and in my experience Omnara is much more reliable than the other solutions, as well as I enjoy the UX of Omnara much more. Give it a try, it's one command to set up and the free tier gives you everything that the paid tier does, so you can decide if you like it before paying!

We think that terminal interfaces, especially on mobile, are not going to be the way people end up interacting with agents in the long run, which is a big reason we built Omnara.

And Omnara chats are stored in our DB, which is how we're able to enable our voice agent, cloud syncing, and ability to see all your chats while your machine is offline. Basically anything you see in the web and mobile clients is being proxied/persisted through our server, until you delete the chat.

Voice input + output sounds gimmicky (as I admit in the post), but it's quite useful for mobile coding. It's not as trivial as just printing out whatever Claude Code outputs.

"Claude Code will help you set this up using tmux" - I don't think that you can connect to tmux sessions running in Claude Code/Codex remote VMs using their mobile apps. Their mobile apps don't provide a terminal emulator afaik

Thank you! Yeah, a big selling point of Omnara is that it "just works." Let me know how it goes!