cmsparks

I think a lot of people are building their harnesses this way more recently, but last year, Claude, Codex (and other harnesses) were storing everything on a big json file on disk.

Our primary focus is a stateful API for you to manage / interact with agents. We manage all of the complicated parts (conversation persistence, sandboxes, MCPs, etc), which allow users to focus on building their product-specific agents on top.

On our managed platform, you can buy credits which you can spend on tokens and on sandboxes (which are priced at cost + a 5% fee). If you want to self host, you can also do that.

> A detailed I noted on permissions - looks like they're all prefixed with "always" - I think allow/deny/ask make more sense ?

Yeah, the wording can probably be improved here, thanks for the feedback!

538 was actually pretty accurate!

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.

If my read of this is correct, this means that Agent SDK orchestrator tools don't get subsidized usage.

This seems to intentionally be trying to kill the other (much better IMO) interactive Claude Code desktop apps...

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.

Reposting part of what Ishaan said elsewhere:

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

We're not a fork, and from what I've heard from users our architecture is more reliable

they're free up to a limit, just like us!