Skip to main content
The runtime is the metered infrastructure Vetta runs your agent on — the durable loop and scheduler, sandboxed computers and the managed browser, model routing across completion windows, and the ledger. It is not a parameter and there is nothing to select: using Vetta’s managed agents is the runtime. The layer you do select is the harness — the agent loop — which sits on top of everything on this page. This page is about the durability half of the runtime, which is where most of the cost behaviour on long-horizon work comes from.

​
Wake → turn → commit → sleep

The loop is an alarm, not a call stack. Each cycle:
  1. Wake on a trigger — a user message, a scheduled deployment, a tool result, or — coming soon — an inbound event (inbound messages are received and stored today; the wake is not yet wired).
  2. Take one turn — a single, bounded slice of work: one harness turn (a model call plus the tool calls it requests).
  3. Commit what it learned — the transcript and cursor are written to durable storage at a fixed commit boundary.
  4. Sleep — the runtime releases compute and sets the next alarm.
Because state lives in storage rather than a live process, a run that spans hours survives a crash, a restart, and a machine change, losing one turn rather than the whole run.

​
Idle costs storage, not compute

Between turns there is no process to pay for. A session waiting on a nightly schedule, a human reply, or a long external job costs only what its stored transcript and its paused computer occupy — a paused micro-VM meters its stored disk and no vCPU at all. This is the mechanism behind Vetta’s low cost on tasks measured in hours: most of that wall-clock time is spent waiting, and waiting is nearly free.

​
Bounded slices

Each turn runs inside a slice with explicit bounds — a step budget, a wall-clock budget, and the spend budget. When a slice hits a bound, the runtime checkpoints mid-task and reschedules the next slice. Nothing is lost; the task simply continues on the next wake.
The commit boundary is a small, fixed set of synchronous writes per turn. Recovery always resumes from the last committed turn, so at-most-one-turn is the worst-case loss under any failure.

​
How the pieces fit

Next: model router & inference

How each call is routed to inference, and how model tokens are metered.