> 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.
As someone who is not incredibly deep in the agent space, but works a lot on scientific and distributed computing, this really caught my eye. Seems like this is primarily part of the cloud offering, but a true posix compatible filesystem that interops cleanly with S3 on the backend would be an incredibly interesting product (especially if it were open-sourced).
A brief sidenote: I did a triple take when I saw the name because Rivet is the internal name of our long-running job queue service. You all have great taste.
I hate to be that guy, but celld does essentially the same thing, no? It waits until persisted to another node OR stored in S3, but unless something has gone horribly wrong, this will essentially always be replicating to the other node first. (Admittedly, I recall it used to be just replicating to 1 node was considered stored, and if that went down it could be lost. I think it's two now, or at least the bug is filed. Prob how the write time was so low in celld, but perhaps wasn't sustainable)
Regardless, glad for more stateful serverless options, even if I am partial to what CloudFlare folks build :)
I'm not super familiar with celld, but my understanding is that its not a full posix filesystem. We work with lots of dynamically created and queried duckdb and netcdf files. My impression of celld is its meant for more lightweight storage and that objects live in SQLite files.
I could be totally mistaken but that's my current understanding.
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.
Fascinating architecture—treating agent turns as persistent lightweight actors backed by tiered SQLite/S3 rather than spinning up dedicated VMs makes a lot of sense for latency and cost.
For workflows that inevitably require arbitrary shell execution or local compiler tools (like coding agents running tests), do you envision delegating just the side-effect execution out to ephemeral runners while keeping the stateful actor long-lived, or is Rivet primarily focused on API/tool-calling agents?
How does hibernation decide an actor is idle? In my agent runtime actors run in XS. Messages are queued and only handled once the current handler returns, so a synchronous handler is never cut in half. But while a handler waits on an async call, an HTTP request say, other messages still get handled. So “no message being processed” isn’t the same as “nothing in flight”. Does Rivet hibernate an actor with an outstanding request, and if so, what happens when the response comes back?
Distributed actors are also good platforms to run graph algorithms. We're evaluating Rivet as a potential substrate to run page rank and clustering algorithms on large graphs, while supporting cypher queries over the result.
Moving state persistence to write-ahead SQLite tiered into S3 is a very clean answer to the latency-cost trap of raw object storage. The big operational win with decoupled actor state like this is avoiding zombie locks when an agent execution times out mid-turn. Curious how you handle split-brain fencing if an actor network partition occurs while a batched write is still draining to S3.
Even as someone who’s very involved in the space, I don’t understand what you guys do. It’d be helpful if your website led with the problem you’re solving instead of technical benchmarks.
I also don’t really understand the distinction between an actor and an agent. I’ve never heard anyone call them actors, and I doubt you’ll win that mindshare as a small startup.
Man I was just coming here to say the same thing. I have a Ph.D. in CS and should be the target audience for this as a guy doing startup stuff that could easily try out a new architecture or tool.
I read "Rivet (https://rivet.dev) – a fast, high-density, and scalable orchestrator for agentic workloads using the actor model" and I think "I have no idea what this means, except it's a new way to make a backend service of some kind??"
I've reached an age where, if I don't understand what it is from your description, I'm not the problem.
I’m likely not much farther ahead than you are in understanding exactly what Rivet does, as I learn by banging my head against the thing I’m trying to use, and so far all I’ve done is read.
“Actor” comes from established CS terminology [1], and agents-in-actors make sense in principle.
Agree with others in this thread that a few use-cases in the README would help me decide whether this is worth banging my head against or not.
Hey Nathan! You build a fantastic product and your tech seems rock solid. I think you would benefit from more use-case specific tutorials and how-to guides so that people find and use your product for the applications that it's a great fit for. Multi-agent systems, code review agents, software factories, etc.
More so than ever, folks are choosing to build rather than buy -- you should emphasize that your product lets teams avoid having to choose by handling the "boring" parts for them and letting them focus on the parts that are unique to their business.
Love the actor model approach here. Hibernating idle agents while keeping state durable in S3 is a huge win for cost.
Curious how Rivet handles the runaway loop problem though. When you have long-lived actors passing messages to each other, a simple state bug can cause them to ping-pong the exact same payload indefinitely.
Because the actors stay alive and keep responding (returning 200s), your infra looks perfectly healthy, but the developer's OpenAI bill just exploded in the background.
Are you leaving loop detection entirely to the devs building on top of Rivet, or is there any native circuit breaker at the orchestrator level to kill an actor that's stuck in a cyclic state?
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...
> 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/
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.
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.
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.
Congrats on the launch! The explanation of keeping S3 off the write path made the storage model much easier to understand. For someone starting with a small self-hosted deployment, what tends to be the first operational challenge as usage grows?
Congratz on the launch! I love how efficient this is - I'm pretty sure more agents will be built this way than having the heavy sandbox.
Quick note, in the README on GH there's a link to https://github.com/rivet-dev/rivet/blob/main/engine/packages... which doesn't lead anywhere.
Keeping S3 off the write path is the design choice that makes the whole pitch click for me: acknowledging a write once two of three availability zones have it on SSD, then batching to object storage in the background, gets durability without paying object-storage latency on every turn. That also explains why separating the agent loop from the sandbox matters, since a long-running turn shouldn't have to keep a heavyweight environment warm just to hold its state. My main question is how that tiering behaves when an actor wakes after a long idle period and its data has fully cooled to S3: is that 138 ms read the typical cost, or does it get worse with larger session transcripts and filesystems?
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.
Got it. This is the og confluent cloud architecture, then. That much data crossing availability zones might surprise people people on AWS since that will add at least $0.04 for every gb sent in
I'm curious if it actually needs to be across AZs versus if it just needs a few instances but yes as written there is a trade off happening.
The other route for fast S3 writes others have used (Turso springs to mind) is express S3 zones but those have a lot of region specific fine print still.
> 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.
As someone who is not incredibly deep in the agent space, but works a lot on scientific and distributed computing, this really caught my eye. Seems like this is primarily part of the cloud offering, but a true posix compatible filesystem that interops cleanly with S3 on the backend would be an incredibly interesting product (especially if it were open-sourced).
A brief sidenote: I did a triple take when I saw the name because Rivet is the internal name of our long-running job queue service. You all have great taste.
Lots of ways to use S3 as a filesystem. FUSE is one. AWS even offers it as a service now.
Those don’t actually give you things like fsevents/inotify. If say you needed to run git or build something, it would not work.
I hate to be that guy, but celld does essentially the same thing, no? It waits until persisted to another node OR stored in S3, but unless something has gone horribly wrong, this will essentially always be replicating to the other node first. (Admittedly, I recall it used to be just replicating to 1 node was considered stored, and if that went down it could be lost. I think it's two now, or at least the bug is filed. Prob how the write time was so low in celld, but perhaps wasn't sustainable)
Regardless, glad for more stateful serverless options, even if I am partial to what CloudFlare folks build :)
I'm not super familiar with celld, but my understanding is that its not a full posix filesystem. We work with lots of dynamically created and queried duckdb and netcdf files. My impression of celld is its meant for more lightweight storage and that objects live in SQLite files.
I could be totally mistaken but that's my current understanding.
Not using the actor model, and yet massively parallel: https://gnosh.ai/swarm.html
I wonder when one approach will be used over the other. Actually, I can imagine both approaches working together.
Just filed two provisional patents on this stuff today; build on gno.land and let's talk shop, I see symbiosis.
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.
Appreciate the kind words, would love to hear feedback on v3 in our Discord when you upgrade!
fairy tale land?
The rest of our infra is AWS + Vercel, so the CF DO stuff was in its own weird isolated space that had to be maintained and cared about separately.
Fascinating architecture—treating agent turns as persistent lightweight actors backed by tiered SQLite/S3 rather than spinning up dedicated VMs makes a lot of sense for latency and cost.
For workflows that inevitably require arbitrary shell execution or local compiler tools (like coding agents running tests), do you envision delegating just the side-effect execution out to ephemeral runners while keeping the stateful actor long-lived, or is Rivet primarily focused on API/tool-calling agents?
How does hibernation decide an actor is idle? In my agent runtime actors run in XS. Messages are queued and only handled once the current handler returns, so a synchronous handler is never cut in half. But while a handler waits on an async call, an HTTP request say, other messages still get handled. So “no message being processed” isn’t the same as “nothing in flight”. Does Rivet hibernate an actor with an outstanding request, and if so, what happens when the response comes back?
Distributed actors are also good platforms to run graph algorithms. We're evaluating Rivet as a potential substrate to run page rank and clustering algorithms on large graphs, while supporting cypher queries over the result.
https://github.com/orgs/Latentpedia/discussions/4
Related work:
https://sigmodrecord.org/publications/sigmodRecord/1712/pdfs...
https://arxiv.org/abs/2301.01395
Moving state persistence to write-ahead SQLite tiered into S3 is a very clean answer to the latency-cost trap of raw object storage. The big operational win with decoupled actor state like this is avoiding zombie locks when an agent execution times out mid-turn. Curious how you handle split-brain fencing if an actor network partition occurs while a batched write is still draining to S3.
Even as someone who’s very involved in the space, I don’t understand what you guys do. It’d be helpful if your website led with the problem you’re solving instead of technical benchmarks.
I also don’t really understand the distinction between an actor and an agent. I’ve never heard anyone call them actors, and I doubt you’ll win that mindshare as a small startup.
Man I was just coming here to say the same thing. I have a Ph.D. in CS and should be the target audience for this as a guy doing startup stuff that could easily try out a new architecture or tool.
I read "Rivet (https://rivet.dev) – a fast, high-density, and scalable orchestrator for agentic workloads using the actor model" and I think "I have no idea what this means, except it's a new way to make a backend service of some kind??"
I've reached an age where, if I don't understand what it is from your description, I'm not the problem.
I’m likely not much farther ahead than you are in understanding exactly what Rivet does, as I learn by banging my head against the thing I’m trying to use, and so far all I’ve done is read.
“Actor” comes from established CS terminology [1], and agents-in-actors make sense in principle.
Agree with others in this thread that a few use-cases in the README would help me decide whether this is worth banging my head against or not.
[1] https://en.wikipedia.org/wiki/Actor_model
Hey Nathan! You build a fantastic product and your tech seems rock solid. I think you would benefit from more use-case specific tutorials and how-to guides so that people find and use your product for the applications that it's a great fit for. Multi-agent systems, code review agents, software factories, etc.
More so than ever, folks are choosing to build rather than buy -- you should emphasize that your product lets teams avoid having to choose by handling the "boring" parts for them and letting them focus on the parts that are unique to their business.
Love the actor model approach here. Hibernating idle agents while keeping state durable in S3 is a huge win for cost.
Curious how Rivet handles the runaway loop problem though. When you have long-lived actors passing messages to each other, a simple state bug can cause them to ping-pong the exact same payload indefinitely.
Because the actors stay alive and keep responding (returning 200s), your infra looks perfectly healthy, but the developer's OpenAI bill just exploded in the background.
Are you leaving loop detection entirely to the devs building on top of Rivet, or is there any native circuit breaker at the orchestrator level to kill an actor that's stuck in a cyclic state?
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.
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
Congrats on the launch! Rivet seems neat; will definitely give it a spin.
> Sandboxes are expensive, mostly idle, and slow to start.
Many sandboxing startups would disagree. Do you have any numbers to support?
Appreciate it! Would love to hear feedback when you do: https://rivet.dev/discord
> 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/
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.
Let us know how it goes! We're active in our Discord: https://rivet.dev/discord
We're big believers in lightweight sandboxing approachs akin to Durable Objects in addition to existing x86 sandboxes.
Congrats! How is the security posture? Without really comparing isolation and sandboxing etc.. comparing with E2B is not the same.
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.
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...
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.
Exactly this.
> 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.
This is a very helpful explanation, thank you. The part about basically duck-typing an Agent's environment and tool access is particularly insightful.
Hey!
> 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.
Congrats on the launch! The explanation of keeping S3 off the write path made the storage model much easier to understand. For someone starting with a small self-hosted deployment, what tends to be the first operational challenge as usage grows?
Hey! We’ve invested heavily in making self-hosting simple compared to the standard. Scaling up is just a matter of adding nodes.
We also provide guides for every major cloud, and no special tuning is required as you add nodes.
If you’re self hosting and have questions, please let us know on Discord or GitHub! https://rivet.dev/discord
Congratz on the launch! I love how efficient this is - I'm pretty sure more agents will be built this way than having the heavy sandbox. Quick note, in the README on GH there's a link to https://github.com/rivet-dev/rivet/blob/main/engine/packages... which doesn't lead anywhere.
Thanks Tim! Will get that fixed.
Keeping S3 off the write path is the design choice that makes the whole pitch click for me: acknowledging a write once two of three availability zones have it on SSD, then batching to object storage in the background, gets durability without paying object-storage latency on every turn. That also explains why separating the agent loop from the sandbox matters, since a long-running turn shouldn't have to keep a heavyweight environment warm just to hold its state. My main question is how that tiering behaves when an actor wakes after a long idle period and its data has fully cooled to S3: is that 138 ms read the typical cost, or does it get worse with larger session transcripts and filesystems?
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.
Been running Rivet v3 self-hosted on AWS and it's dope!
Love to hear it! Don't hesitate to share feedback in our Discord: https://rivet.dev/discord
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?
I would have lead with the durability aspect.
this is for people/products that run dozens/hundreds of agents concurrently.
looks cool - I'm curious how this is similar / different from celld
..and how you're doing anything with s3-backing durably and safely with latency numbers less than several hundred ms
In OP
> 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.
Got it. This is the og confluent cloud architecture, then. That much data crossing availability zones might surprise people people on AWS since that will add at least $0.04 for every gb sent in
I'm curious if it actually needs to be across AZs versus if it just needs a few instances but yes as written there is a trade off happening.
The other route for fast S3 writes others have used (Turso springs to mind) is express S3 zones but those have a lot of region specific fine print still.
Ooh, so mod_rivet is getting funding? That's great. Tcl does not get enough love these days.
Ah, another rivet. I initially thought it was a pivot of:
https://rivet.ironcladapp.com/
Me too... the Rivet from Ironclad was amazing for its time (when GPT3 came out). I don't think the developer realised how huge it could have been.
<insert spiderman meme here>