Rivet: open-source actors for agents, 72 KB each versus a 512 MB sandbox

Rivet, a start-up from Y Combinator's 2023 batch, launched an open-source orchestrator for agent workloads on 5 November 2026. Its founders, Nathan and Nicholas, say in a Launch HN post that each agent gets a lightweight actor instead of its own sandbox. The code is on GitHub under the Apache 2.0 licence. The figures below come from that README and post; they are the project's claims, not independent tests.

What it does

A Rivet actor is a long-lived process with in-memory state, a WebSocket server and a SQLite database. The README says you can create one for each agent, user, session or tenant. Idle actors hibernate and wake on the next request. Actors can be written in TypeScript or Rust, and the founders say self-hosting needs a single Rust binary with S3 as the only dependency.

The pitch is about where an agent's time goes. The README says most of it is spent waiting on a model, so a sandbox that holds a whole virtual machine or container per agent sits mostly idle. Rivet instead runs the agent loop outside the sandbox and exposes the sandbox as tools. The founders say that also limits the blast radius if an agent misbehaves, and that for code the agent writes they offer a V8 and WebAssembly sandbox library called agentOS.

The numbers the founders give

• Memory: 72 KB baseline per actor, against 512 MiB for a minimal sandbox.
• Start time: 4.99 ms at the 99th percentile, against 1.70 s for a sandbox, according to the README.
• Storage latency (3 availability zones, p99): 1.07 ms durable writes, 1.36 ms reads from SSD cache and 138 ms reads that fall back to S3.
• Cost: data stored on Rivet is about 10.4 times cheaper than replicated SSD storage, and the post says 10 times cheaper than EBS gp3.

The storage design explains the cost claim. The post says a write is acknowledged once SSDs in two of three availability zones have it, then batched to S3 in the background, so S3 is never on the write path. Reads come from SSD if cached and from S3 if not. The founders say they moved to S3 from FoundationDB because customers were storing large session transcripts, artifacts and whole filesystems on fast disks that sat mostly idle.

The one named customer is Amp. The founders say Amp first tried Cloudflare Durable Objects, could not launch because of the platform's limits, and moved to Rivet in a weekend and deploys it on-premises. That is the founders' account; Amp is not quoted.

What commenters said

The thread had about 105 points when I read it. Reaction was mixed.

• Support: one commenter said they moved a Cloudflare Durable Objects component into their own AWS and Vercel setup, and called it pleasant; another said they run Rivet v3 self-hosted on AWS. Neither gave numbers.
• Speed is not the problem: esafak wrote that agentic workloads have many problems but orchestration speed is not one, because you spend most of the time waiting for the model. Another reader replied that it targets people running dozens or hundreds of agents at once.
• Hidden cost: chicagobuss said that replicating data across availability zones adds at least $0.04 for every GB sent on AWS, which may surprise users. The founders' reply on this point is not in the thread excerpt I read.
• Benchmarks: ATechGuy2 noted that sandbox vendors would disagree with 'expensive, mostly idle and slow to start' and asked for numbers. The founder replied there is no one-size-fits-all and pointed to a benchmarks page.
• Clarity: several readers, including one with a PhD in computer science, said they could not tell what the product does from the opening, and asked for use cases. Others raised unanswered questions about runaway loops, hibernating with a request in flight and split-brain after a partition.

What to do with it

This is a young project with a vendor-written benchmark, so treat it as a candidate for a test rather than a recommendation. If you run many long-lived agents with a sandbox each, pull a week of sandbox billing and work out how much is idle time. If it is large, run one real agent workflow on Rivet and compare cost, cold-start time and recovery after a crash against your current setup.

Check three things before relying on it. First, whether the agent needs a full Linux environment, such as running git or compilers, because the README says the lighter sandbox is V8 and WebAssembly. Second, what the cross-availability-zone writes do to your cloud bill. Third, what happens to a request in flight when an actor hibernates, which commenters asked and I did not see answered.