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.

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.

Fortunately the Github is still up: https://github.com/fivethirtyeight

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.

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'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!

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

* improved web interface

* worktrees

* sandboxing

* richer git management (richer diffs, checkpoints, git operations)

* preview URLs

Thanks, we try to make it much easier than self hosting and managing your own tunnels! Let us know how it goes.

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.

> branching not from main

This is actually a PR that I have open right now, it'll be out soon!

> automatic capitalization

We'll get this fixed

> automatic worktree names

definitely on our roadmap, probably will do that this week

Yeah we've definitely taken some inspiration from everyone who building an agent orchestrator/delegation app right now!

Anecdotally from some Omnara users who have used both, I've heard that reliability and latency when sending messaages is better in Omnara

We try to provide a decent chunk of features on top as well, including (but not limited to):

* web support

* worktrees

* sandboxing

* richer git management (richer diffs, checkpoints, git operations)

* preview URLs

FWIW, we'll definitely add OpenCode support soon!

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

"How many times does 'r' appear in the word strawberry?"

> It has some support, but it got merged into A2A, which I don't hear anyone talking about, so it seems like it's going to die on the vine.

I'm not sure this is true, do you have a source? Maybe conflating this with the recent Agentic AI Foundation & MCP news?

Frankly, it's pretty difficult. Though, I've found that the actor model maps really well onto building agents. An instance of an actor = an instance of an agent. Agent to agent communication is just tool calling (via MCP or some other RPC)

I use Cloudflare's Durable Objects (disclaimer: I'm biased, I work on MCP + Agent things @ Cloudflare). However, I figure building agents probably maps similarly well onto any actor style framework.

>There when would one update the tools? You can’t “trigger” an event which causes a tool change without some hacky workarounds

Tool calls can trigger tool changes. Consider an MCP server exposes a list of accounts and tools to manage resources on those accounts:

1. MCP session starts, only tool exposed to the client is the `select_account` and `list_accounts` tools

2. MCP Client selects an account with `select_account` tool

3. MCP Server updates tools for the session to include `account_tool_a`. This automatically dispatches a listChanged notification

4. MCP Client receives notification and updates tools accordingly

IME this is pretty ergonomic and works well with the spec. But that’s assuming your client is well behaved, which many aren’t

MCP isn't static. It explicitly includes support for dynamically modifying tools, resources, etc via it's client notifications[0]. Sure, context is usually opaque to the server itself (unless you use the sampling feature[1]), but there's nothing preventing MCP clients/hosts from adjusting or filtering tools on their own.

[0] https://modelcontextprotocol.io/specification/2025-03-26/ser...

[1] https://modelcontextprotocol.io/specification/2025-03-26/cli...

Oof not a fun incident, this is my nightmare as someone who works on this type of stuff.

As an aside, GitHub’s security model for apps/integrations is extremely puzzling to reason about and enables a lot of foot guns. Add the fact that it’s very obtuse to audit integrations (especially within an organization) makes them pretty scary to use sometimes.

I think this project runs on the QuickJS engine

If you want to try out Cloudflare Pages again, you aren't required to have github integration. If you want to just upload and host some static assets you can use direct upload. You can basically just drag and drop/manually upload a zip file containing some HTML, JS, or other static assets and create a static site that way. (See: https://developers.cloudflare.com/pages/get-started/direct-u...)

(Disclaimer: I'm an engineer on Cloudflare Pages)