Same problem here. Internally we simulated it with just-bash plus whatever
filesystem was handy. For production we went with DO
after surveying their agent ecosystem, but it has since split into two paths
(@cloudflare/agents or think vs. @cloudflare/computer) with real trade-offs. Rivet's s3 setup looks like a much closer fit for us — I'd want to try it on the
next project.
Rivet is very cool. Switched a Cloudflare Durable Object piece of our infrastructure that lived in its own little fairy tale land to our own infra within the rest of our VPC. Was a very pleasant experience.
Haven't had the chance to try Rivet v3 yet but hoping to get to it soon.
> Many sandboxing startups would disagree. Do you have any numbers to support?
There is no one-size-fits-all, but we're finding Rivet's benefits fit well for most agent workloads. I don't believe sandboxes are going away, but I think different workloads will move to specialized architectures.
Regarding cost, there are F500 companies using Rivet's tools for saving cost for use cases like RL.
Regarding coldstarts, it depends heavily on the use case, and there's not a one-size-fits-all.
Benchmarks are pulled from Compute SDK sandbox benchmarks, more here: https://rivet.dev/docs/benchmarking/
Hey! Rivet includes a library for running untrusted user code called agentOS: https://rivet.dev/agentos/
It provides Linux-compatible sandboxing using V8 / WebAssembly. Supports full POSIX filesystems, networking stacks, and process trees. Security-wise, it's the same model as Cloudflare Workers & Chromium.
Hey Nathan! I remember Rivet from Playflow, back when you guys did game server orchestration. Great to see you guys grow!
Have you had agents like claude code , codex etc all fully running in agent-os? Trying to understand the use case a bit better here. For context, I've recently built our own pipeline which spins up ephemeral linux vms for claude code, codex, etc which do their work & the state always persists but frees up resources when finished. Is the idea pretty much similar for agent-os here?
Also with the s3 backing changes, it reminds me a lot of the work done on celld, good to see more self-hostable durable objects out there.
Been a minute since the gaming days, thanks for reaching out!
> Have you had agents like claude code , codex etc all fully running in agent-os?
We have gotten them all working inside of agentOS. However, we found it's a better architecture to run the agent loop outside of agentOS and expose it as tools. The trust boundary & blast radius of running the agent inside the sandbox makes it difficult.
Also, the memory overhead of running individual Claude Code instances is nuts, it's better to run the agents in a single process using tools.
> Also with the s3 backing changes, it reminds me a lot of the work done on celld, good to see more self-hostable durable objects out there.
Appreciate it!
Rivet has a much different architecture than most S3-backed databases. Having an object-per-actor doesn't scale well with cost and performance, so we built a SSD tiered storage engine instead: https://rivet.dev/changelog/2026-10-26-introducing-rivet-3-0...
Wouldn't an agent in any capacity need a sandbox runtime to do agentic work? When you say "sandboxes are too slow" do you mean needing to boot the sandbox to get back Agent state? Is the idea that state/memory/context and runtime env are separate concepts in rivet?
(I'm a professional developer but don't do any orchestration so trying to understand from basic mental model pov)
There is a notion right now of decoupling the agent loop from the sandbox, so the sandbox isn't waiting for request-response from the agent. This would probably be 90+% of all the agent work.
If you combine this with products like Sprites from Fly.io (or OSS version - agent substrate), where you pay only per execution request in a sandbox, you can have huge savings compare to the event loop inside the sanbdox. You will be billed only for request executions (tens of milliseconds per read/write, hundreds of milliseconds per search, etc.) and zero for all the waiting time during the the inference phase.
Also, if you don't require a real Linux sandbox — you might actually emulate the environment, e.g. just-bash idea with linux-like environment to give agents something that looks like their native habitat, but under the hood, it can be just CF Durable Objects SQLite or whatever else.
Probably(?) almost all knowledge work doesn't require a Linux sandbox. You can just build a document reading and editing agent that does tool calls and connects to other products via MCPs, APIs, etc. And lightweight actors make a lot of sense to me in these cases.
> Wouldn't an agent in any capacity need a sandbox runtime to do agentic work?
Developers on Rivet use 3 different patterns:
- Just agents: many agents just need tools, such as customer support or personal agents
- Agents with lightweight sandbox: Rivet provides a V8 / WebAssembly sandboxing library for running JS & Python with a filesystem, which covers most workloads like data analysis, file processing, evals, and code mode (https://rivet.dev/agentos/)
- Agent outside of the sandbox: expose the sandbox to the agent as tools, which is better for blast radius, trust boundary, and orchestration (see below)
> Is the idea that state/memory/context and runtime env are separate concepts in rivet?
Exactly, Rivet Actors support running the harness outside of the sandbox. It's often referred to "separation of head from the hands."
> When you say "sandboxes are too slow" do you mean needing to boot the sandbox to get back Agent state?
Specifically coldstarts. As LLMs are getting faster and have more realtime use cases, sandboxes are become the bottleneck on time to interactive for an agent.
What if I just want self-hostable TypeScript actors _without agents_? I'm a long-time fan of Akka et. al., but to my knowledge Node never got a proper framework.
Hey! Rivet is pure actors at its core, there's nothing inherently specific to agents.
Instead, we provide an optional agent library that runs Pi Durable on top of actors (https://rivet.dev/agents/docs/quickstart/) or you can write your agent from scratch if you choose.
Interesting idea, horrible ux atm though, my codex/claude whatever is just as confused as me what and how are we supposed to use it exactly and all the edge cases. Hope you folks can figure out some interesting ideas to improve it though.
Hey! Can you share a bit more about what your agent is saying so we can fix this? Would love to chat with you in Discord too: https://rivet.dev/discord
My first reaction: this is weird; agentic workloads have many problems but orchestration speed ain't one of them. You spend most of the time waiting for the model! Is this for small models?
> It’s not as simple as writing data straight to S3. Lots of PUTs for tiny blobs of data are slow and expensive. Instead, we use an SSD tier to optimize speed and cost:
> When you write data to an actor’s SQLite database, the write is acknowledged once SSDs in 2 of 3 availability zones have it. Then, the data is batched to S3 in the background. This means that S3 is never on the write path, which lowers latency and cost. When reading data or waking an actor, Rivet reads from SSDs if already cached and falls back to S3 if not. SSD caches can be tuned to meet your needs, giving you configurable tiered storage for your actors.
We're big believers in lightweight sandboxing approachs akin to Durable Objects in addition to existing x86 sandboxes.
Haven't had the chance to try Rivet v3 yet but hoping to get to it soon.
> Sandboxes are expensive, mostly idle, and slow to start.
Many sandboxing startups would disagree. Do you have any numbers to support?
> Many sandboxing startups would disagree. Do you have any numbers to support?
There is no one-size-fits-all, but we're finding Rivet's benefits fit well for most agent workloads. I don't believe sandboxes are going away, but I think different workloads will move to specialized architectures.
Regarding cost, there are F500 companies using Rivet's tools for saving cost for use cases like RL.
Regarding coldstarts, it depends heavily on the use case, and there's not a one-size-fits-all. Benchmarks are pulled from Compute SDK sandbox benchmarks, more here: https://rivet.dev/docs/benchmarking/
It provides Linux-compatible sandboxing using V8 / WebAssembly. Supports full POSIX filesystems, networking stacks, and process trees. Security-wise, it's the same model as Cloudflare Workers & Chromium.
Rivet is frequently used for running the harness outside of the sandbox. Wrote a bit about why here: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...
Have you had agents like claude code , codex etc all fully running in agent-os? Trying to understand the use case a bit better here. For context, I've recently built our own pipeline which spins up ephemeral linux vms for claude code, codex, etc which do their work & the state always persists but frees up resources when finished. Is the idea pretty much similar for agent-os here?
Also with the s3 backing changes, it reminds me a lot of the work done on celld, good to see more self-hostable durable objects out there.
> Have you had agents like claude code , codex etc all fully running in agent-os?
We have gotten them all working inside of agentOS. However, we found it's a better architecture to run the agent loop outside of agentOS and expose it as tools. The trust boundary & blast radius of running the agent inside the sandbox makes it difficult.
Also, the memory overhead of running individual Claude Code instances is nuts, it's better to run the agents in a single process using tools.
I wrote a bit more on it here: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...
> Also with the s3 backing changes, it reminds me a lot of the work done on celld, good to see more self-hostable durable objects out there.
Appreciate it!
Rivet has a much different architecture than most S3-backed databases. Having an object-per-actor doesn't scale well with cost and performance, so we built a SSD tiered storage engine instead: https://rivet.dev/changelog/2026-10-26-introducing-rivet-3-0...
Ping me on Discord if you give it a try, would be fun to catch up: https://rivet.dev/discord
(I'm a professional developer but don't do any orchestration so trying to understand from basic mental model pov)
If you combine this with products like Sprites from Fly.io (or OSS version - agent substrate), where you pay only per execution request in a sandbox, you can have huge savings compare to the event loop inside the sanbdox. You will be billed only for request executions (tens of milliseconds per read/write, hundreds of milliseconds per search, etc.) and zero for all the waiting time during the the inference phase.
Also, if you don't require a real Linux sandbox — you might actually emulate the environment, e.g. just-bash idea with linux-like environment to give agents something that looks like their native habitat, but under the hood, it can be just CF Durable Objects SQLite or whatever else.
Probably(?) almost all knowledge work doesn't require a Linux sandbox. You can just build a document reading and editing agent that does tool calls and connects to other products via MCPs, APIs, etc. And lightweight actors make a lot of sense to me in these cases.
> Also, if you don't require a real Linux sandbox — you might actually emulate the environment
We built agentOS for this: https://rivet.dev/agentos/
It provides Linux-compatible sandboxing using V8 / WebAssembly. Supports full POSIX filesystems, networking stacks, and process trees.
> Wouldn't an agent in any capacity need a sandbox runtime to do agentic work?
Developers on Rivet use 3 different patterns:
- Just agents: many agents just need tools, such as customer support or personal agents
- Agents with lightweight sandbox: Rivet provides a V8 / WebAssembly sandboxing library for running JS & Python with a filesystem, which covers most workloads like data analysis, file processing, evals, and code mode (https://rivet.dev/agentos/)
- Agent outside of the sandbox: expose the sandbox to the agent as tools, which is better for blast radius, trust boundary, and orchestration (see below)
> Is the idea that state/memory/context and runtime env are separate concepts in rivet?
Exactly, Rivet Actors support running the harness outside of the sandbox. It's often referred to "separation of head from the hands."
I wrote a bit about why a while back: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...
> When you say "sandboxes are too slow" do you mean needing to boot the sandbox to get back Agent state?
Specifically coldstarts. As LLMs are getting faster and have more realtime use cases, sandboxes are become the bottleneck on time to interactive for an agent.
Instead, we provide an optional agent library that runs Pi Durable on top of actors (https://rivet.dev/agents/docs/quickstart/) or you can write your agent from scratch if you choose.
I would have lead with the durability aspect.
..and how you're doing anything with s3-backing durably and safely with latency numbers less than several hundred ms
> It’s not as simple as writing data straight to S3. Lots of PUTs for tiny blobs of data are slow and expensive. Instead, we use an SSD tier to optimize speed and cost:
> When you write data to an actor’s SQLite database, the write is acknowledged once SSDs in 2 of 3 availability zones have it. Then, the data is batched to S3 in the background. This means that S3 is never on the write path, which lowers latency and cost. When reading data or waking an actor, Rivet reads from SSDs if already cached and falls back to S3 if not. SSD caches can be tuned to meet your needs, giving you configurable tiered storage for your actors.
https://rivet.ironcladapp.com/