---
title: Machines
description: A fresh computer per run, and how your own agent reaches it.
---

Every run gets its own container, of the shape the experiment chose, and gives
it back when the run and its judging are over.

## The shapes

A new project starts with three:

| Shape | vCPU | Memory | Disk |
|---|---|---|---|
| **Standard** (default) | 2 | 4 GB | 20 GB |
| **Performance** | 4 | 8 GB | 40 GB |
| **Max** | 8 | 16 GB | 80 GB |

You can add your own on the **Machines** page: a name and the three numbers. A
machine is a *size* and nothing else — every run boots the same machine image,
with the selected agent's CLI installed on top of it, so there is nothing else
to choose.

A machine shape that experiments have run on cannot be deleted, and the default
one cannot be deleted until another is made the default.

## What the agent gets

Ubuntu, with node, python3, git and sudo, starting in `/workspace`. Everything
the experiment attached is placed there before the agent's first token, and a
summary of it is written to `CONTEXT.md`.

The container is given a few environment variables that say nobody is watching —
`CI=1`, `TERM=dumb`, `NO_COLOR=1` — because agents behave differently when they
think there is a terminal in front of them.

Nothing on the machine is shared with anything else. Everything the agent does
happens inside the box, and nothing it does can reach the computer hosting it.

## Lifetime

1. **Created for the run**

    Provisioned after the credential check, from the image the agent's CLI is
    installed in.

2. **Kept through judging**

    The evaluator works on the same box, still running, exactly as the agent left
    it. That is what lets a verdict rest on the file rather than on the claim.

3. **Destroyed**

    Immediately after the verdict. Nothing survives to the next run, which is why
    a result belongs to its experiment rather than to what happened before it.

A run that exceeds its time limit — twenty minutes per attempt by default — has
its machine killed and is recorded as errored.

## `machine_run`, for your own agent

A catalog agent lives on the machine. Your own agent does not — it runs in your
process. So when an experiment attaches something that has to exist somewhere,
the SDK gives your agent a `machine_run` tool:

```ts
machine_run({ command: "npm test", cwd: "billing-api" })
```

A real bash line on the run's container, starting in `/workspace`. `cwd` may be
relative; it resolves against the workspace.

It appears in your tool list automatically, and only when the experiment
attached a repository, an upload, a CLI, an SDK package or a plugin — skills are
text and MCP servers are connections, and neither needs a computer. The box is
built lazily on the first call and destroyed once the run is over, so a run that
never touches its machine never provisions one.

> **Tip**
>
> `machine_run` exists for the same reason MCP does: a capability the agent
> reaches out to, rather than something installed underneath it. It is not the
> same thing as an MCP server you attached, and it is not something you
> configure — the SDK injects it for the run that needs it.