Oleksandr Kuzmenko, EditorPublished 6 min readAI-assisted · editor-reviewed
TL;DR
- Each Rivet actor requires 72 KB RAM and reaches 4.99 ms p99 cold starts in shared Node.js, Bun, or Rust processes.
- State is persisted using embedded SQLite backed directly by S3-compatible object storage, avoiding external database dependencies.
- agentOS provides isolated execution for agent-generated code with granular filesystem, network, and resource restrictions.
Key facts
- Memory Footprint
- 72 KB per Actor
- Cold Start Latency
- 4.99 ms p99 (self-reported)
- Storage Latency
- 1.07 ms write / 1.36 ms read p99 (self-reported)
- Cost Advantage
- 10.4x cheaper than replicated EBS gp3 (self-reported)
- License
- Apache 2.0
Source: Key facts — Memory Footprint
Source: Key facts. Memory Footprint: 72 KB per Actor. Each figure is copied from the story.
- Memory Footprint72 KB per Actor
Breaking Free from MicroVM Overhead
Rivet shifts away from running complete Linux environments for routine agent interactions. An individual Rivet Actor shares a native Node.js, Bun, or Rust process instead of booting a full container, taking up 72 KB of RAM compared to the 512 MiB typical of sandboxes. According to benchmark figures released alongside the project, cold starts drop to 4.99 ms at the 99th percentile, bypassing image pulls and virtualization handshakes.
SQLite Persistence on Object Storage
Instead of requiring external Postgres instances or NATS brokers, Rivet actors use embedded SQLite instances backed by Amazon S3, Google Cloud Storage, or any S3-compatible API like MinIO or Cloudflare R2. Persistent writes complete at 1.07 ms and reads at 1.36 ms (p99), which Rivet reports is 10.4 times cheaper than replicated Amazon EBS gp3 volumes. When an actor sits idle, it hibernates and incurs zero compute cost until the next HTTP or WebSocket request arrives.
Running Untrusted Code via agentOS
For agent tasks requiring execution of generated scripts, Rivet provides agentOS. It is built to run the code your agent writes securely, providing granular control over network access, filesystem access, and resource limits without requiring traditional full-sandbox initialization.
Try it in 2 minutes
await db.execute(`CREATE TABLE IF NOT EXISTS messages (role TEXT, content TEXT)`);
await c.db.execute("INSERT INTO messages VALUES (?, ?)", "user", text);
const messages = await c.db.execute("SELECT role, content FROM messages");When to use
- Massive high-density deployments with thousands of concurrent long-lived agents.
- Multi-tenant stateful AI workflows where cold start latency under 10 ms is crucial.
When NOT to use
- When agents require fully customized Linux kernel modules or raw host device drivers.
- When you cannot rely on S3 or S3-compatible APIs for storage persistence.
What to do today
- Evaluate Rivet Actors for stateful agent workflows that need low-latency startup and cheap hibernation.
- Try running Rivet locally using an S3-compatible storage backend such as MinIO or Cloudflare R2.
Step names are taken from What to do today.
Step names are taken from What to do today. Evaluate Rivet Actors for stateful agent workflows that need low-latency startup and cheap hibernation.. Try running Rivet locally using an S3-compatible storage backend such as MinIO or Cloudflare R2.
- Evaluate Rivet Actors for stateful agent workflows that need low-latency startup and cheap hibernation.
- Try running Rivet locally using an S3-compatible storage backend such as MinIO or Cloudflare R2.