Rivet's S3 Agent Orchestrator Acknowledges Writes From SSDs, Not S3

Rivet, a Y Combinator W23 company, launched an open-source orchestrator for AI agents on Nov. 5 under the headline "Scale and Orchestrate Agents on S3." In its own launch post, S3 is where data ends up, not where writes land: a write is acknowledged once SSDs in two of three availability zones hold it, and S3 is never on the write path.

Nathan Flurry posted the Launch HN with a second author named Nicholas, and it reached 75 points and 42 comments by Nov. 6. The code is on GitHub at rivet-dev/rivet under Apache 2.0, with about 6,700 stars, 308 forks and 46 open issues when we read the page.

What an actor is here

Rivet's unit is the Rivet Actor, a long-lived process with in-memory state, a SQLite database, WebSockets and scheduling. The pitch is one actor per agent, user or session, instead of one sandbox, meaning a container or virtual machine that can run untrusted code. Idle actors hibernate and wake on the next request. The control plane is written in Rust; the TypeScript SDK is the main client, Rust is supported, and the Python and Swift clients are marked experimental.

The launch post says the team came from multiplayer game infrastructure and built actors that served tens of millions of monthly active users. It names Amp as a customer that moved to Rivet from Cloudflare Durable Objects to orchestrate multiplayer agents.

The figures are Rivet's

Every number below comes from Rivet's launch post or README. We found no third party that had reproduced them.

Measure	Rivet's figure	Comparison it gives
Actor memory baseline	72 KB	512 MB, minimal sandbox
Start time, p99	4.9 ms	1.7 s, sandbox
Durable write, p99, three zones	1.07 ms	none
Read from SSD cache, p99	1.36 ms	none
Read from object storage, p99	138 ms	none

The 512 MB and 1.7 s sandbox figures arrive without a named product or test setup in the post. When a commenter, ATechGuy2, asked "Do you have any numbers to support?", Flurry replied that "there is no one-size-fits-all" and pointed to Compute SDK benchmarks. That is a pointer, not a method. The README adds that the benchmark section references Rivet 3.0.3.

Where S3 sits, and what the thread questioned

The design has three layers. Writes go to SSDs and are acknowledged when two of three availability zones have them. A background job batches them to S3. Reads come from the SSD cache and fall back to S3, which is where the 138 ms figure applies. Self-hosting needs only object storage: the README lists Amazon S3, Google Cloud Storage, Azure Blob Storage, S3-compatible stores and a local filesystem backend, and says no Postgres, FoundationDB or NATS is needed. The post also claims data kept on Rivet costs one-tenth of EBS gp3, a price comparison it does not itemise.

One commenter, chicagobuss, wrote that "that much data crossing availability zones might surprise people on AWS." Replicating every write across zones would normally show up as inter-zone transfer on a cloud bill, though the post gives no figure, and Flurry did not reply to that comment in the part of the thread we read. Another, serjester, wrote "I don't understand what you guys do", and a third, stiiv, asked whether it works without agents. Flurry answered that "Rivet is pure actors at its core, there's nothing inherently specific to agents."

What it does not cover

The README says actors do not run untrusted code. An agent that executes code it writes still needs a sandbox, and the project points to a separate product, agentOS, for that. Dynamic Apps are in preview. Pricing for Rivet Cloud, which runs dedicated clusters on AWS or GCP, is not in the launch post.

Rivet sits in the same crowded middle as the JetBrains ThinkRail IDE wrapper around a single agent, where the interesting claim is about plumbing, not the model. It is also another Launch HN company out of Y Combinator that ships its core under a permissive licence and sells hosting. The thing to ask for before adopting it is a published benchmark harness for the sandbox comparison; none is linked.