Resource Limits

Cap per-VM resources, JavaScript CPU/wall-clock time, Python execution, and WASM runtime work so guest code can never exhaust the host.

Every agentOS VM runs with per-VM resource and runtime caps. These caps contain runaway or malicious guest work to its VM and give the host an explicit failure instead of silent data loss.

• Secure defaults: unset fields fall back to built-in defaults that match the runtime’s historical constants. Optional execution budgets such as WASM fuel explicitly document when their default has no additional budget.
• Per-VM: every VM gets its own budget. Limits are not shared across VMs.
• Enforced by the sidecar/runtime: a guest that exceeds a cap fails inside the VM (out-of-memory, EMFILE, EAGAIN, runtime timeout, etc.) instead of consuming past the configured budget.
• Operator-raisable: the operator (the trusted process that creates the VM) may raise any cap for trusted workloads. Guest code can never raise its own caps.

Setting limits

Set caps on the limits object in the agentOS config. Limits are grouped by subsystem (resources, process, jsRuntime, python, wasm, and more). Omitted limits keep their secure default.

import pi from "@agentos-software/pi";
import { agentOS, setup } from "@rivet-dev/agentos";

const vm = agentOS({
	software: [pi],
	limits: {
		resources: {
			maxProcesses: 64, // concurrent processes
			maxOpenFds: 256, // open file descriptors
			maxSockets: 128, // open sockets
			maxFilesystemBytes: 256 * 1024 * 1024, // VFS storage budget
			maxWasmFuel: 30_000, // WASM execution budget
			maxWasmMemoryBytes: 128 * 1024 * 1024, // WASM linear memory
			maxWasmStackBytes: 4 * 1024 * 1024, // WASM call-stack ceiling
		},
		process: {
			pendingStdinBytes: 64 * 1024 * 1024, // stdin waiting on a kernel pipe
			pendingEventCount: 10_000, // queued process/runtime events per stage
			pendingEventBytes: 64 * 1024 * 1024, // queued event payload per stage
		},
		jsRuntime: {
			v8HeapLimitMb: 128, // JS isolate heap
			cpuTimeLimitMs: 30_000, // active JS CPU time
			wallClockLimitMs: 0, // 0 disables elapsed wall-clock cutoff
			importCacheMaterializeTimeoutMs: 30_000, // Node import-cache setup
			syncRpcWaitTimeoutMs: 30_000, // host sync-RPC wait
		},
		python: {
			executionTimeoutMs: 300_000, // Python wall-clock execution
			maxOldSpaceMb: 0, // 0 keeps the Pyodide runner default
		},
		wasm: {
			prewarmTimeoutMs: 30_000, // WASM compile-cache warmup
			runnerHeapLimitMb: 2048, // trusted WASI runner V8 heap
		},
	},
});

export const registry = setup({ use: { vm } });
registry.start();

Available caps

Behavior at the limit

• WASM stack: deep recursion throws a stack-overflow error in the guest, never a host crash.
• JavaScript CPU time: CPU-bound loops terminate with a CPU-budget error once active JS CPU exceeds jsRuntime.cpuTimeLimitMs.
• JavaScript wall time: awaiting or blocked JS terminates only when you set jsRuntime.wallClockLimitMs; the default is disabled for long-lived adapters.
• Filesystem bytes: writing past the VFS budget fails with a no-space error to the guest.
• Counts (fds / processes / sockets): hitting a table cap returns the standard POSIX errno appropriate to that cap (EMFILE/ENFILE, EAGAIN, etc.).
• Durable ACP collections: session, prompt, pending-permission, and terminal-outcome caps fail atomically with typed errors naming the exact limits.acp.* field to raise. Per-session caps are validated not to exceed their corresponding per-VM cap.

WASM memory residency calls

V8 owns the physical backing pages for WASM linear memory, and the runtime cannot currently pin those pages against host swapping. Nonempty mlock() and valid mlockall() requests therefore return ENOTSUP rather than falsely claiming that secrets or other guest memory were pinned. munlock() and munlockall() succeed because no guest lock can be established and the memory is already unlocked.

Non-destructive madvise() access-pattern calls are accepted as best-effort hints, which Linux is also permitted to ignore. Advice that would discard data or change fork, core-dump, or host VM mapping policy returns ENOTSUP because the runtime cannot apply it.

Sidecar liveness

Separate from the guest caps above, the host detects a dead or wedged sidecar process by silence, not by per-request deadlines. The sidecar emits a liveness heartbeat every 10 seconds from a dedicated thread — so it keeps beating even mid-way through a long turn — and the host treats 30 seconds with no inbound frames at all as a dead sidecar: it kills the process and fails in-flight requests with a typed SidecarSilenceTimeout error.

Because liveness is silence-based, individual requests have no time limit of their own: an agent turn may legitimately run for many minutes without being torn down. Neither the heartbeat cadence nor the silence window is configurable — they are fixed protocol constants.

Warnings & observability

Limits are observable, not just enforced. Live resource gauges and internal bounded queues are tracked in a central limit registry that:

• Warns before the limit is hit. As usage crosses ~80% of a cap, the runtime emits a structured warning (once per crossing, re-armed only after it recovers), so a slow consumer or a runaway guest is visible before it fails.
• Never drops data silently. Internal queues either apply backpressure or fail with a typed error naming the exhausted limit and the setting used to raise it. A rejected event is not popped and forgotten.
• Surfaces through logs. The agentOS sidecar logs to stderr (stdout is the wire protocol); set AGENTOS_LOG=warn (the default) to see near-limit warnings or AGENTOS_LOG=debug for live per-limit usage snapshots.

See Limits & Observability for the full architecture.