NathanFlurry

WASM- & V8 isolate-based operating system that's (almost) POSIX-compliant, including its own network stack, VFS, process tree, etc.

Allows you to compile most C or Rust programs to run in it without modification. Also can run Claude Code, Codex, Pi, and OpenCode unmodified.

Working on polishing, security, and documentation so I can share an in-depth deep dive on HN.

https://github.com/rivet-dev/agent-os

Cheers!

Yep, everyone seems to reinventing the actor model from first principles right now.

We're taking a different approach of building the best actor primitive for mainstream languages and letting people build a thin AI layer on top. We did not set out out build for AI when we started it, it was a happy accident.

Thanks! Any questions in particular on the comparison?

Cheers!

Hey! This is a common question.

In our experience, most apps don't need cross-tenant queries outside of BI. For example, think about the apps you use on a daily basis: Linear, Slack, ChatGPT all fit well with an actor-per-workspace or actor-per-thread model.

To be clear, we're not trying to replace Postgres. We're focused on modern workloads like AI, realtime, and SaaS apps where per-tenant & per-agent databases are a natural fit.

Using SQLite for your per-tenant or per-agent databases has a lot of benefits:

- Compute + state: running the SQLite database embedded in the actor has performance benefits

- Security: solutions like RLS are a security nightmare, much easier to have peace of mind with full DB isolation per tenant

- Per-tenant isolation: important for SaaS platforms, better for security & performance

- Noisy neighbors: limits the blast radius of a noisy neighbor or bad query to a single tenant's database

- Enables different schemas for every tenant

- AI-generated backends: modern use cases often require AI-generated apps to have their own custom databases; this model makes that easy

A few other points of reference in the space:

- Cloudflare Durable Objects & Agents are built on this model, and much of Cloudflare's internal architecture is built on DO

- https://neon.com/use-cases/database-per-tenant

- https://turso.tech/multi-tenancy

- https://www.thenile.dev/

- Val.town & Replit

> Better usage of resources

I'd be curious to hear more about what you mean by this.

> always allows a parent style agent do complex queries

Do you have a specific use case in mind where agents need to query other agents' data?

We built everything with this architecture internally already at Rivet. It's less common than you might expect to have to query cross-DB in practice.

However, we are planning on building a query engine that can operate over multiple databases. One option we're considering is exposing Rivet SQLite as a DuckDB datasource: https://duckdb.org/docs/stable/data/data_sources

What does this mean for Bun (recently acquired by Anthropic)?

OpenCode supports:

- TUI (I prefer this for most programming)

- Web UI (negligible difference than VS Code)

- Mobile support (via web UI)

- TypeScript SDK to automate

Been using it for a bit now, it's very convenient if I may say so myself. We're shipping a big stability update in a few minutes – would love feedback!

Thanks!

Yes. We want to support ACP. They have a spec for HTTP transport in the works, but there is nothing public on it. Trying to backchannel to the right folks.

Hit the nail on the head.

(Sprites.dev in the works already.)

Thank you!

Posted this morning an overview of the project: https://x.com/NathanFlurry/status/2018366627021291699

That's correct.

As you said – in terms of project goals, the biggest difference is:

- ACP seems to be focused on providing a universal API for the subset of features required for editors

- Sandbox Agent SDK is focused on automating agents, so aims to provide a much more comprehensive API coverage for niche agent-specific features

We maintain a feature coverage matrix (https://sandboxagent.dev/docs/session-transcript-schema#cove...) – it's early, much more coming soon.

Love it

Hacked together an SF parks ranking system based on current weather

https://sfparks.nathanflurry.com/

We’re doing this on https://rivet.dev now. I did not realize how much context bloat we had since we were using Tailwind.

I’ve been building an open-source alternative at https://github.com/rivet-dev-engine

It’s the only bit of the Cloudflare stack (afaik) that did not have an open-source alternative for the JS ecosystem. I built heavily with DO on another OSS project, but realized it was incredibly problematic that our customers couldn’t truly self-host.

A 1 CPU + 2 GB of RAM + 50 GB ephemeral storage on Cloudflare Containers is $74.90.

The same on Fly Machines is $31.00 (performance-1x, varies by region). Fly Machines has the same sleeping functionality as Cloudflare.

Rivet Containers also has a similar price point of $29.40, but takes a different approach to sleeping (opts for optimizing coldstarts + autoscaling over snapshotting). (I work at Rivet)

They stated on the livestream they're considering TCP, but I suspect UDP is not coming soon since Workers themselves don't support UDP. All traffic going to Cloudflare Containers must be "proxied" through the Workers platform.

We published an in-depth comparison between Cloudflare Containers, Fly Machines, and Rivet Containers: https://rivet.gg/blog/2025-06-24-cloudflare-containers-vs-ri...

(I work at Rivet)

Our self-hosting docs are very rough right now – I'm fully aware of the irony given my comment. It's on our roadmap to get them up to snuff within the next few weeks.

If you're curious on the details, we've put a lot of work to make sure that there's as few moving parts as possible:

We have our own cloud VM-level autoscaler that's integrated with the core Rivet platofrm – no k8s or other orchestrators in between. You can see the meat of it here: https://github.com/rivet-gg/rivet/blob/335088d0e7b38be5d029d...

For example, Rivet has an API to dynamically spin up a cluster on demand: https://github.com/rivet-gg/rivet/blob/335088d0e7b38be5d029d...

Once you start the Rivet "seed" process with your API key, everything from there is automatic.

Therefore, self-hosted deployments usually look like one of:

- Plugging in your cloud API token in to Rivet for autoscaling (recommended)

- Fixed # of servers (hobbyist deployments that were manually set up, simple Terraform deployments, or bare metal)

- Running within Kubernetes (usually because it depends on existing services)

I hope this isn't the case here with Rivet. I genuinely believe that Kubernetes does a good job for what's on the tin (i.e. container orchestration at scale), but there's an evolution that needs to happen.

If you'll entertain my argument for a second:

The job of someone designing systems like this is to decide what are the correct primitives and invest in building a simple + flexible platform around those.

The original cloud primitives were VMs, block devices, LBs, and VPCs.

Kubernetes became popular because it standardized primitives (pods, PVCs, services, RBAC) that containerized applications needed.

Rivet's taking a different approach of investing in different three primitives based on how most organizations deploy their applications today:

- Stateless Functions (a la Fluid Compute)

- Stateful Workers (a la Cloudflare Durable Objects)

- Containers (a la Fly.io)

I fully expect to raise a few hackles claiming these are the "new primitives" for modern applications, but our experience shows it's solving real problems for real applications today.

Edit: Clarified "original cloud primitives"