Flue now supports agentOS
A lightweight alternative to sandbox VMs for your Flue agents, running on V8 isolates and WebAssembly.
Today, Flue officially supports agentOS.
Cloudflare Workers proved you don’t need a container to run untrusted code. By running your backend in a V8 isolate instead of a virtual machine, a Worker starts in milliseconds and costs almost nothing while it waits on a database or an API.
agentOS brings that to the sandbox. An agent spends almost all of its time waiting on inference or a tool call, yet the sandbox behind it is a full virtual machine sitting mostly idle and costing you money.
Against a best-in-class sandbox provider, agentOS is:
- 92× faster to cold start: 4.8 ms p50 vs. 440 ms
- 47× smaller in memory: about 22 MB vs. a 1 GiB sandbox
- 254× cheaper to run: self-hosted AWS ARM vs. per-second sandbox billing
Why agentOS: the isolate model for sandboxes
A sandbox isolates the agent by booting a virtual machine, and that boot is the whole cost: a kernel, a hypervisor, and hundreds of milliseconds before the first command runs.
agentOS gets the same isolation without a virtual machine. It comes from WebAssembly and V8, the same sandboxing that isolates every Chrome tab and every Cloudflare Worker. It’s small, and its security has been hardened for years.
A Worker only runs JavaScript, but an agent needs a shell, a filesystem, and languages like Python. agentOS goes one step further than a bare isolate: it’s a lightweight, Linux-compatible VM running on WebAssembly. JavaScript, Python, and Bash run in a secure runtime, so the agent gets a real scripting layer instead of a chain of tool calls.
The agent becomes part of your application, not another service:
- Library, not extra infrastructure: install from npm and run it in the backend process you already operate.
- Direct function calls, not extra APIs: connect agents to your application with ordinary JavaScript instead of another network service.
- Scoped access, not exposed credentials: bind trusted host functions without ever giving the agent your raw secrets.
You get Flue’s developer experience on an OS built for agents.
Building a Flue agent with agentOS
Install Rivet’s Flue preview builds and the three integration packages:
npm add "@flue/runtime@npm:@rivet-dev/labs-flue-runtime"
npm add --save-dev "@flue/cli@npm:@rivet-dev/labs-flue-cli"
npm add @rivet-dev/flue @rivet-dev/agentos @rivet-dev/agentos-flue rivetkit
@rivet-dev/labs-flue-*provides preview builds of Flue’s proposed extension APIs.@rivet-dev/flueruns Flue agents and workflows as durable Rivet Actors.@rivet-dev/agentosand@rivet-dev/agentos-flueprovide the isolated VM actor and connect Flue’s sandbox API to it.
Register the VM, point Flue’s Rivet target at it, and attach it as the agent’s sandbox:
// Register the agentOS VM into a RivetKit registry.
import { agentOS, setup } from "@rivet-dev/agentos";
export const vm = agentOS({
/* Software, permissions, limits, mounts, and bindings go here. */
});
export const registry = setup({ use: { vm } });
// Point Flue's Rivet build target at the registry.
import { defineConfig } from "@flue/cli/config";
import { rivet } from "@rivet-dev/flue";
export default defineConfig({ target: rivet({ actors: "./actors.ts" }) });
// Attach the agentOS sandbox to a Flue agent.
import { createAgent } from "@flue/runtime";
import { agentOSSandbox } from "@rivet-dev/agentos-flue";
import { registry } from "../actors";
const sandbox = agentOSSandbox({ actor: "vm", registry });
export default createAgent(() => ({
model: "anthropic/claude-sonnet-5",
instructions: "Help the user work in the sandboxed repository.",
sandbox,
}));
Then connect to it:
npx flue connect assistant local
Each agent instance and each workflow run gets its own durable Rivet Actor and SQLite database, so accepted work recovers after an interruption.
Giving it a filesystem
Most of what an agent does is read and write files, so the filesystem is where a sandbox earns its keep.
Every Flue context gets a persistent /workspace filesystem that survives sleep and wake with no setup, backed by Rivet Actors’ storage. The adapter derives a stable VM key from the Flue context ID, so reusing a context reconnects to the same files. Anything else you want the agent to see gets mounted at a path, the same way you’d mount a disk:
import { agentOS, setup } from "@rivet-dev/agentos";
export const vm = agentOS({
mounts: [
{
path: "/mnt/data",
plugin: {
id: "s3",
config: { bucket: "my-bucket", prefix: "agent-data/", region: "us-east-1" },
},
},
],
});
export const registry = setup({ use: { vm } });
Escalating only when you have to
The vast majority of agent work never needs more than the VM. Desktop automation, heavy compilation, and full browsers do.
Instead of provisioning a heavy sandbox for every agent on the chance that one task needs it, agentOS starts one on demand and tears it down when the task finishes. The common path stays a 22 MB isolate, and you pay sandbox cost and sandbox cold starts only for the small slice of work that actually requires one.
It’s the same execution ladder Workers developers already reach for. Escalate to a container only when you’re limited by the isolate itself, or call out to an external service such as image resizing or a browser for work that doesn’t fit in a lightweight isolate.
Mounting a full sandbox takes two extra packages:
npm add @rivet-dev/agentos-sandbox modal
import { agentOS, setup } from "@rivet-dev/agentos";
import { modal } from "@rivet-dev/agentos-sandbox/modal";
export const vm = agentOS({
sandbox: {
// Also supports Vercel, Cloudflare, and other sandbox providers.
provider: modal(),
},
});
export const registry = setup({ use: { vm } });
Browsers arrive the same way, as a software package such as Browserbase:
import browserbase from "@agentos-software/browserbase";
import { agentOS, setup } from "@rivet-dev/agentos";
export const vm = agentOS({
software: [browserbase],
});
export const registry = setup({ use: { vm } });
Deploy anywhere your backend runs
Most sandboxes are extra infrastructure: a service the provider hosts for you, reached over an API, with its own latency and its own bill.
agentOS is just a library. The same code that manages your agent runs inside the backend you already operate, and that backend runs both your agent and its sandbox. There’s no hypervisor, no nested virtualization, and no provider sandbox API to code against.
So it runs anywhere JavaScript does, whether Node.js, Bun, or Deno, on platforms such as Rivet, Railway, Kubernetes, or Vercel. (agentOS doesn’t run on Cloudflare Workers yet, since the isolate relies on OS-level APIs, but the same WebAssembly target we use to run agentOS in the browser makes it possible.)
Working upstream with Flue
This integration currently runs on Rivet’s Flue fork. We’re opening upstream pull requests soon to merge its generic target-authoring and runtime extension APIs into Flue, so Flue can support actor-model runtimes without taking a Rivet dependency.
