Skip to content

Isolated microVMs · bare metal

Give the agent root.
Keep the receipts.

Caged runs Claude Code, Aider, Codex and your own MCP agents inside isolated microVMs, each with its own Linux kernel. Every file write, every command and every LLM call is recorded, priced and replayable.

  • OWN LINUX KERNEL
  • 128 GB HOST
  • PER-MINUTE METERING
  • FULL SESSION REPLAY
Cross-section of one Caged microVMAn exploded orthographic stack, drawn bottom to top: a slab labelled bare metal, a narrow band labelled KVM, and above them a box with double-line walls labelled microVM. Inside that box sit a slab labelled kernel and a gridded workspace labelled rootfs holding a small glyph for the running agent. One line runs from the agent straight out through a single opening in the microVM wall, labelled egress proxy, and past a short graduated scale labelled metered.KVMBARE METALMICROVMEGRESS PROXYROOTFSKERNELAGENTMETERED

Runs

  • Claude Code
  • Aider
  • OpenAI Codex CLI
  • Grok CLI
  • Cline
  • Continue CLI
  • Goose

A container is a shared kernel with good manners. A microVM is a wall.

Namespaces and cgroups are scheduling and accounting features of one kernel that every tenant shares. Code an agent wrote an hour ago does not need an exotic exploit to matter there — it needs one bug in a syscall you have never heard of. A Caged sandbox boots its own Linux kernel and its own root filesystem on KVM, so the thing an agent can break is the machine you gave it.

A shared kernel compared with one kernel per sandboxTwo panels of equal size. On the left, five small boxes labelled container sit above one wide slab labelled host kernel, with lines from every box converging into that single shared slab. On the right, five boxes each hold their own small slab labelled kernel, each box fully enclosed by a double wall, and no line passes between them.SHARED KERNELCONTAINERHOST KERNELONE SHARED SURFACEOWN KERNELKERNELNO SHARED SURFACE
Five containers share one kernel. Five sandboxes do not share anything.

How it works

From caged run to a session you can scrub through.

  1. 01 BOOT

    A machine of its own

    Allocate, kernel, rootfs, ready: every sandbox is a microVM with its own Linux kernel, its own root filesystem and its own network interface on KVM. No kernel is shared with another tenant.

    The order a Caged sandbox boots inA staggered bar chart of four stages in sequence — allocate, kernel, rootfs, ready — above an unlabelled baseline. The last bar ends in a small double-walled square marking the booted microVM. The axis carries no timings: the bars show the order of the stages and not their duration, which has not been measured.COLD BOOTALLOCATEKERNELROOTFSREADYMICROVMSTAGE ORDER · NOT TO SCALE · NO TIMING MEASURED
  2. 02 OBSERVE

    Everything is on the record

    File operations, commands, tool calls, LLM calls, network requests, desktop actions, errors and lifecycle changes — eight event types, one append-only stream, written as they happen.

    Every sandbox action joins one append-only event streamA box labelled sandbox with three taps on its right boundary, labelled FS write, exec and LLM call. A line leaves each tap and the three merge into a single band labelled event stream, which ends in a stack of five identical records carrying consecutive sequence numbers. One record is drawn with a heavier outline to mark the current event.ON THE RECORDSANDBOXFS WRITEEXECLLM CALLEVENT STREAM01410142014301440145APPEND-ONLY
  3. 03 PRICE

    Tokens and minutes, as they burn

    LLM spend is metered at the egress proxy against a per-model token table. Compute is metered per minute against the tier you booted. The dollar figure exists during the session, not at the end of the month.

    Tokens and compute minutes summed into one running totalTwo horizontal meters. The upper one, headed input and output tokens, is divided into uneven segments carrying token counts; the lower one, headed compute minutes, into even segments. Both feed rightward through two summing junctions into a framed panel showing a running dollar total over a rising step line, with a dashed line across the panel marked budget. Every figure shown is illustrative, as the panel states.COST, METEREDINPUT / OUTPUT TOKENS12K4K31K9KCOMPUTE MINUTESBUDGET$1.24ILLUSTRATIVE
  4. 04 JUDGE

    Behaviour moves a score

    Reading a secrets file, escalating privilege, calling an unknown host, running something destructive: each is a shipped rule with a fixed deduction, applied as the event arrives, before you read the diff.

    A session's trust score and the rules that moved itA tall gauge graduated from zero at the bottom to one hundred at the top. A dashed line at one hundred marks where the session started; a solid line lower down marks where it stands now. Three leader lines point at it from three entries: minus twenty-five for sensitive file access, minus twenty for privilege escalation, minus fifteen for a suspicious egress host. Those three deltas sum to sixty, which is why the current line sits at forty from a starting hundred. The deltas are the shipped rule values; the session itself is an example, as the drawing notes.TRUST SCORE100806040200STARTCURRENT-25SENSITIVE FILE ACCESS-20PRIVILEGE ESCALATION-15SUSPICIOUS EGRESS HOSTILLUSTRATIVE SESSIONDELTAS FROM SHIPPED RULES

Isolation

The blast radius is the VM.

One sandbox failing inside a host full of sandboxesA plan view of one bare-metal host holding a grid of nine sandboxes, each ringed by its own double wall. The interior of one cell is drawn broken and scattered, while that cell's own wall stays unbroken and every neighbouring cell is intact. A single shared channel along the bottom edge is labelled egress proxy, with one line entering it from each cell.BLAST RADIUSBARE METAL HOSTSANDBOXSANDBOXSANDBOXSANDBOXSANDBOXSANDBOXSANDBOXSANDBOXFAILEDEGRESS PROXYONE SANDBOX FAILS · WALL HOLDS · NEIGHBOURS INTACT
  • Own kernel per sandbox

    A microVM on KVM with its own kernel image and its own rootfs drive. A VM boundary, not a namespace.

  • No sandbox reaches another

    Traffic addressed to the guest subnet is dropped in every network mode, ahead of any allowlist rule. No dev server, debug port or agent socket is reachable from a neighbour.

  • LLM egress goes through one proxy

    The egress proxy is the first accepted destination in every sandbox's chain, and it is where tokens are counted and policy is applied.

  • Destroy is destroy

    Teardown removes the packet-filter rules, the TAP device, the API socket and the VM directory with its rootfs overlay. The event record outlives all of it.

  • 1

    Kernel per sandbox

  • 0

    Routes between sandboxes

  • 3

    Network modes

Observability

Scrub back to the command that broke it.

A session is an ordered event stream, so it replays. Read the commands in the order they ran, the files as they changed, and the LLM calls that asked for them — after the fact, from the record, not from a log you hoped someone kept.

A session replay laid out as four parallel event lanesA wide timeline. Four lanes labelled files, terminal, LLM and policy each carry small event marks at uneven positions, with a few marks lining up vertically to suggest one action causing another. A playhead stands about two thirds along, above a scrubber track with timecode graduations. One terminal event is enlarged into a callout holding a single line of command text.REPLAY TIMELINEFILESTERMINALLLMPOLICY00:0005:00$ go test ./internal/trust/...
A session replay, drawn. Files, terminal and LLM are recorded event types; the policy lane is a view over verdicts carried on those same events.

Workforce

You don’t start a session. You hire someone.

A sandbox lasts as long as the work in it. A Persona is the thing that keeps a name, a role, a harness and a record across all of them — and the thing an autonomy tier is attached to.

  • A Persona outlives the session

    A name, a job title, the harness it runs, an autonomy tier, a trust score. It is hired, it can be paused, and once it is offboarded it does not come back — you hire another one.

  • A Shift is a session with a badge

    Starting one opens a session bound to that Persona and mints a credential that expires. Ending the Shift revokes it; so does destroying the sandbox. Only an active Persona gets one.

  • A Team is an org chart, not a tag

    Every member has at most one manager, cycles are refused when the edge is written, and the depth of any chain is capped — so asking for someone's reports or their manager chain always terminates.

  • The tier decides what needs a human

    Probation, supervised, trusted, autonomous. Each compiles to a policy the tool gate evaluates on every call, and a tool that is not in the table is refused at every tier — including autonomous.

A team of Personas with one manager edge eachAn org chart inside a box labelled team. One node at the top, a lead at the trusted tier, with a line dropping to a horizontal bus and three lines from that bus down to three nodes: an analyst at the supervised tier, an engineer at the trusted tier, and a researcher at the probation tier. The manager lines are the only part of the drawing in the accent colour, because they are what a team adds over a list of Personas. Each member has at most one manager and cycles are rejected when the edge is written. Below the chart, the four tiers in order — probation, supervised, trusted, autonomous — and a note that the tier decides which tool calls need a human. The roles and names are an example; the tiers are the shipped set.TEAMLEADTRUSTEDANALYSTSUPERVISEDENGINEERTRUSTEDRESEARCHERPROBATIONPROBATION · SUPERVISED · TRUSTED · AUTONOMOUSTHE TIER DECIDES WHICH TOOL CALLS NEED A HUMANEXAMPLE CHART · ONE MANAGER PER MEMBER · NO CYCLES

Pipelines

A run that can wait for a human.

A pipeline is a directed graph of stages, checkpointed to Postgres at every step and cancellable while it is in flight. Here is one, in the order it ran.

  1. 01 COMMAND

    clone

    A command stage gets a microVM of its own. Caged creates it, runs the command inside it, and destroys it before the next stage starts — so one stage cannot leave state behind for the next one to trip over.

  2. 02 COMMAND

    test

    A stage that fails retries on the policy the pipeline declared: three attempts by default, ten at the ceiling, and the wait between them capped at thirty seconds. A retry loop cannot run away.

  3. 03 AWAIT_APPROVAL

    review

    Here the run stops and waits for a person. It holds no sandbox and no worker: the stage is checkpointed as paused, the goroutine returns, and a server restart leaves it exactly where it was — still waiting.

  4. 04 COMMAND

    ship

    Approval lands, the run picks up where it stopped. Stages run in dependency order, and a stage whose dependencies can never be satisfied ends the run naming the edges that stalled it rather than polling forever.

  5. 05 A2A

    hand-off

    The last stage delegates to an agent outside Caged over the Agent-to-Agent protocol. If a deployment has no delegator wired, the stage fails closed — it will not report a success it never had.

A pipeline run resolving stage by stageA vertical run sheet. Five stages hang off one spine, top to bottom: clone, test, review, ship, hand-off. Each stage's node shape says what kind of stage it is — a circle for a command, a diamond for the approval gate, a square for the hand-off to an external agent. The three command stages each carry a small double-walled square in the left column, marking the microVM created and destroyed around that command; the approval gate and the hand-off carry none, because neither creates one. The test stage has a loop drawn on the spine and is labelled attempt 2 of 3. The review stage is labelled resumed, because the run paused there for a person. Every stage ends succeeded and the run ends succeeded. A playhead in the left margin marks how far the run has got; it rests on the final stage. The stage names and the retry are an example; the stage types and statuses are the ones the API ships.PIPELINE RUNSUCCEEDEDMICROVMSTAGESTATUSCLONECOMMANDSUCCEEDEDTESTCOMMAND · ATTEMPT 2 / 3SUCCEEDEDREVIEWAWAIT_APPROVAL · RESUMEDSUCCEEDEDSHIPCOMMANDSUCCEEDEDHAND-OFFA2A · DELEGATEDSUCCEEDEDEXAMPLE RUN · STAGE TYPES AND STATUSES AS SHIPPED

The stage names and the retried attempt are an example. The stage types, the statuses, the retry ceilings and the pause are the ones the API ships. Two stage types Caged can express are deliberately not drawn: eval gates and trust/cost gates are built without their evaluators on this deployment, and a gate with no evaluator passes by default — so it is not a gate.

Role templates

Hire from a template. Or publish one.

Nine categories, from engineering to finance to security. Private or public. Fork it, version it, rate it — and pin the version you hired, so the employee you onboarded is the one that keeps turning up.

Installing a role template as a PersonaOn the left, a card labelled role template listing the six things a template's definition holds: harness config, tool grants, guardrails, KPIs, budget and autonomy tier. Beside it a column of three version cells, V1 to V3; V2 is held in a square bracket to mark the version this install pins. An arrow labelled install runs right from that version — the only line in the accent colour — into a box on the right labelled Persona, which contains a smaller box labelled harness and two lines reading tier probation and budget inherited. Notes below: a published version never changes, an install pins one, and a harness config that does not validate is rejected when the template is published rather than when it is installed.ROLE TEMPLATEDEFINITIONHARNESS CONFIGTOOL GRANTSGUARDRAILSKPISBUDGETAUTONOMY TIERV1V2V3INSTALLPINS V2PERSONAHARNESSTIER · PROBATIONBUDGET INHERITEDA PUBLISHED VERSION NEVER CHANGESAN INSTALL PINS THE VERSION IT READAN INVALID HARNESS CONFIG IS REJECTED AT PUBLISHEXAMPLE LISTING · FIELDS AS SHIPPED
  • A template is a job, packaged

    The harness it runs, the tools it may call, its guardrails, the KPIs it is measured on, a budget it inherits, and the tier it starts at. Installing one hires a Persona wired to a harness built from exactly that.

  • A published version never changes

    Editing mints the next version and snapshots it. An install pins the version it read, so a Persona hired in March is not quietly rewired in June because somebody improved the listing.

  • An unsafe config cannot be published

    The bundled harness config is validated when the template is published, not when it is installed — by the same validator the engine uses, not a second copy of it. A marketplace is how one bad config would travel.

  • The marketplace metadata is honest

    Install counts are incremented in the same transaction as the install they count. Forks record what they came from. The verified badge is set by curation and never by the account that published the template.

Start with one sandbox. Or wire the whole fleet.

  • 01 SOLO

    I want one agent off my laptop

    One sandbox, one agent, a dollar figure while it runs and a session you can replay when it stops.

  • 02 TEAM

    I have a team running agents all day

    Budgets, policies, approval gates and trust scores, with every session on the record in one place.

  • 03 PLATFORM

    I'm building on top of agents

    The REST API, the MCP tool surface over a WebSocket, and the CLI. Bring your own agent; keep the isolation and the ledger.

Pricing

The plan is the concurrency. The meter is separate.

A plan buys how many sandboxes run at once, how long they may live and how far back the history goes. Compute minutes and LLM tokens are metered per session on top — the estimator below prices those from list rates.

  • Free

    Free

    Experiment freely

    • 5 sandboxes / day
    • 1 concurrent
    • 30-min timeout
    • 7-day history
    • 1 API key
    • Community support
  • Pro

    Recommended

    $29

    per month

    Ship with AI daily

    • Unlimited sandboxes
    • 5 concurrent
    • 4-hour timeout
    • 90-day history
    • Unlimited keys
    • Priority support
  • Team

    $99

    per seat per month

    Agents at scale

    • Everything in Pro
    • 15 concurrent (shared)
    • Shared dashboards
    • Team key mgmt
    • Dedicated support

What are your agents costing you?

Price a week of agent work.

$3.00 in / $15.00 out per 1M tokens

$0.002 per minute

Estimated list cost · per week

$63.90

90 sessions · LLM is 93% of it

LLM tokens
$59.40
Compute minutes
$4.50

An estimate, not a quote: it multiplies the list rates published in Caged's billing code as of 20 September 2026 by the numbers you typed. Disk is not billed and network egress is not billed, so neither appears above. Your real figure comes from the meter on a real session.

Trust

Behaviour, scored. Not vibes.

Every session starts at 100. As events arrive, each one is put to a fixed set of rules, and a match moves the score by a fixed amount — the same amount, every time, for every agent. The score is arithmetic over what happened, not a judgement about what an agent meant.

  • −50crypto_miningMining binaries or pool addresses in a command
  • −30destructive_commandDestructive command — recursive delete, dropping a database
  • −25env_secrets_accessRead of a secrets or .env file
  • −20sudo_chmodPrivilege escalation — sudo, chmod 777, chown root
  • −15suspicious_networkRequest to a host outside what the sandbox was given
  • +5Commit, branch, push
  • +3Running the tests
  • +1An ordinary code file written

A score is clamped to 0–100. The deductions and credits above are the built-in rules; a policy can add its own.

A session's trust score and the rules that moved itA tall gauge graduated from zero at the bottom to one hundred at the top. A dashed line at one hundred marks where the session started; a solid line lower down marks where it stands now. Three leader lines point at it from three entries: minus twenty-five for sensitive file access, minus twenty for privilege escalation, minus fifteen for a suspicious egress host. Those three deltas sum to sixty, which is why the current line sits at forty from a starting hundred. The deltas are the shipped rule values; the session itself is an example, as the drawing notes.TRUST SCORE100806040200STARTCURRENT-25SENSITIVE FILE ACCESS-20PRIVILEGE ESCALATION-15SUSPICIOUS EGRESS HOSTILLUSTRATIVE SESSIONDELTAS FROM SHIPPED RULES

Developers

Three lines, then it's running.

caged login
caged run --template node-20 --budget 5.00
caged connect sbx_7f3a9c21
  • Config as code

    caged up reads a .caged.yaml, so a sandbox definition lives in the repo it works on.

  • A budget is an argument

    --budget 5.00 is a ceiling on the session, set at the point you start it.

  • Tools, not a shell wrapper

    The MCP surface exposes filesystem, terminal, git, process, screen and HTTP tools, each one an observed event.

Read the docs

Questions people actually ask.

  • How is this different from running the agent in a container?

    A container shares the host kernel with every other container on the machine; isolation is namespaces and cgroups inside one kernel. A Caged sandbox is a Firecracker microVM on KVM with its own kernel image and its own root filesystem, so the boundary an agent would have to cross is the virtual-machine boundary rather than a syscall filter.

  • What exactly gets recorded?

    Eight event types: file operations, commands, tool calls, LLM calls, network requests, desktop actions, errors and lifecycle changes. They are appended in order against the session, which is what makes a session replayable afterwards rather than only observable live.

  • Which agents can I run?

    The catalogue is Claude Code, Aider, OpenAI Codex CLI, Grok CLI, Cline, Continue CLI and Goose. Anything that speaks MCP can also drive a sandbox through the sandbox's own MCP WebSocket, which is how a custom agent gets the same recording and the same metering.

  • How does the cost model work?

    Two meters. LLM tokens are priced per model against a published input/output table as calls pass the egress proxy. Sandbox compute is priced per minute against the size you booted, across six vCPU-and-memory tiers. Disk is not billed, and network egress is not billed. A session can carry a budget ceiling set when you start it.

  • Can one sandbox reach another?

    No. Traffic addressed to the sandbox subnet is dropped in every network mode, and that rule sits ahead of any allowlist a sandbox was given, so neither a mode nor an operator's allowlist can open a path between two sandboxes. Outbound internet access is a separate question, and it depends on the network mode you choose: full, allowlist or none.

  • What happens when I destroy a sandbox?

    The packet-filter rules, the virtual network interface, the hypervisor socket and the VM directory with its root filesystem overlay are all removed. The session record does not go with it — that is the point of recording it somewhere the sandbox cannot reach.

Cage your agents. Free your machine.

Let them cook. In a cage.