kmansm27
Joined 1 year ago
Karma
289
Submissions
72
Member since
Mar 21
Recent submissions
Comment · 9 days ago
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.
Comment · 9 days ago
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.
Comment · 10 days 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.
Comment · 10 days ago
> 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
Comment · 10 days 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...)
Comment · 10 days ago
haha yes! this was the reasoning for making durability native in our harness
Comment · 1 month ago
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.
Comment · 2 months ago
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.
Comment · 2 months ago
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.
Comment · 8 months ago
Just fixed this issue! Seemed to occur on web, thanks for reporting this!
Comment · 8 months ago
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!
Comment · 8 months ago
We have voice support for this exact reason! Not sure if I'd want to enable people vibe coding from their car dashboard xD
Comment · 8 months ago
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.