The agent's computer

The isolated Linux environment every agent owns and operates inside, and how the warm pool keeps boot times under a second.

Every agent comes online with its own persistent Linux computer — fresh at boot, fully isolated, destroyed when the run ends. It exists for the lifetime of the agent and shares nothing with any other agent or your laptop.

What's inside

| | | | --- | --- | | OS | Ubuntu 24.04, current security patches | | Languages | Python 3, Node.js, plus the standard Linux tooling | | Workspace | /workspace — empty at boot, persistent until the agent terminates | | Network | Egress only; no inbound ports, no peer container access |

The computer has access to the reasoning model, built-in tools, and your persistent memory — but cannot read another agent's files, another agent's memory, or any other user's data.

Per-plan resources

| Plan | CPU | Memory | Region | | --- | --- | --- | --- | | Free | 0.5 vCPU | 512 MB | iad (US East) | | Pro | 1 vCPU | 1 GB | iad | | Scale | 2 vCPU | 2 GB | iad |

Multi-region containers ship soon.

The warm pool

Cold-booting an agent's computer takes 10-15 seconds (image pull, network, language runtime init). For interactive agent UX that's far too slow, so Jettson maintains a warm pool: a small number of pre-booted environments per region, always ready, fully isolated, with zero user context attached.

When you start an agent:

  1. The API tries to claim a warm environment from the pool atomically.
  2. If one is available, the agent's context (task, memory tokens, callback URL) is injected and it comes online — typically in 500-1500ms.
  3. If the pool is empty, the start falls through to a cold path — never blocks waiting.
  4. Either way, the replenisher tops the pool back up within ~30 seconds.

You'll see warmHit: true on the agent doc when the run was served warm. See the warm pool card on the Console overview for live pool status and your 24h hit rate.

Lifecycle

text
warm claim ─► boot ─► activate ─► run task ─► cleanup
              (10s)    (1-2s)      (variable)   (~5s)

Cold path skips the warm-pool claim and pays full boot cost up front.

Isolation guarantees

  • Process isolation — agents run in separate kernels (Fly Machines under the hood). No shared memory or processes.
  • Filesystem isolation — /workspace is per-agent. Tearing down the agent's computer destroys it.
  • Network isolation — agents see public internet only. They can't address your other agents, the Jettson server, or each other.
  • Token isolation — the HMAC tokens injected at boot are scoped to the specific agent ID. A leaked token can only do things for that single agent.

Hard limits

| | | | --- | --- | | Max agent duration | 30 min / 2 hr / 4 hr by plan — enforced in-container and as a server-side safety net | | Workspace size | 1 GB | | Stdout/stderr per tool call | 10 MB | | Tool iterations per run | 20 |

When an agent hits a hard limit it transitions to error with a structured reason; its computer is force-destroyed and the agent doc gets a clean error message.