No idea. ABC bought it and slowly has been shutting down the parts of it. They got rid of the projects page, then laid off all the folks working on it after the election, and now have gotten rid of all of the articles.
That would prolly work for simple sites, but you still need the dedicated scraping service with a browser to render sites that are more complex (i.e. SPAs)
Sandboxing, which is an optional, opt-in feature, requires persistent access to the code via our github integration + us syncing certain refs to our backend.
However, even if you don't opt into syncing, tool calls will end up sending pieces of code from your codebase to our backend. That's just the nature of how we handle persistence of chats. Though messages/chats are retained until you delete them.
> We don't have E2EE yet (it's on the roadmap), so some level of trust in Omnara is required today. All repo operations happen locally on your machine. For messages/chat history: we store those encrypted at rest because we need access to sync across devices, send notifications, and resume agents. Cloud sandboxing is opt-in and would require syncing codebase state.
Yeah, we have parallel agent functionality, sort of like conductor. This allows you to create worktrees for your repo and run any number of chats per worktree. On your local machine, we don't have any unique sandboxing capabilities, but we reuse your sandboxing settings from Claude or Codex if you have them set. The cloud sandboxing is more isolated, but still has access to the internet.
When I say harness agnostic, I more mean we're agnostic to what harness is running, sort of like Zed with ACP: https://agentclientprotocol.com/overview/introduction. It still necessitates bringing the SDK and us writing an adapter for the SDK, but you still get to use the same chat interface for all the agent SDKs.
We've seen a decent amount of comparisons to Happy, but anecdotally from some Omnara users who have used both, I've heard that reliability and latency when sending messaages is much better in Omnara
We try to provide more features on top as well, including (but not limited to):
Our goal is building infrastructure around the agent tools, which I think is how we'll build up a moat and provide automation value. I agree that competing with the labs on general tools is probably a bad business decision, but I'd argue that just means we should compete on the infrastructure, not the harness/model.
When we started out, people were asking "Why would you want to continue coding on your phone". There's obviously a ton of competition now, but I think it's also validation for us.
Even though this might be "the obvious thing", I think there is a non-obvious way to build it.
OpenCode is great and `opencode serve` in particular is very cool. Though I think the main thing is that you need to manage the OpenCode server yourself and expose it via tailscale or something like that. Our goal is to provide managed infrastructure around the coding agent harness with features like mobile, sandboxes, preview urls, etc.
Our goal is to be harness agnostic as well, so eventually we will be adding support for running OpenCode sessions in Omnara.
IMO feels sorta like Simon Willison's definition of agents. "LLMs in a loop with a goal" feels super obvious, but not sure if I would have described it that way in hindsight
They had a good article about how their predictions were much better than you'd expect, but obviously I can't link it anymore because ABC removed it.