# How an AI agent can buy compute

_By Apoorv Khanna, August 20, 2026_

Compute is the purchase an agent most needs and is least equipped to make. A coding agent wants to run the tests somewhere that is not your machine. A research agent wants to execute the script it just wrote. A data agent wants a container with the right libraries for ten minutes. Every one of those is a purchase from a compute provider, and every one of them has historically required a person to open an account, attach a card, generate a token, and then never look at the bill again. This post is an agent buying compute for itself: the providers, one real sandbox from create to terminate with the price at each step, and the controls that stop the meter running after the agent has forgotten about it.

## The providers and their shapes

Five providers in the network sell compute to agents, and they come in two shapes.

**One-off sandboxes** are for a single execute-and-read. Modal is the primary one: a container comes up, runs a command, and is gone after its timeout, three hundred seconds by default. A CPU sandbox is a few cents to create, with a cap of five, and a cent per command after that. It is also the GPU path, with T4 through H100 available by parameter, each tier under its own price cap that the agent has to set explicitly. This is the right shape when the agent wants to run one thing and read the output.

**Persistent sessions** are for stateful work. E2B, Daytona, Runloop, and Fly.io keep a box alive across commands, so an install in the first call is still there in the tenth, and a run can outlast Modal's five minutes. They are metered by uptime, roughly five cents per vCPU-hour on E2B, and they keep billing until the agent closes them. This is the right shape for anything that needs a filesystem to persist, and the wrong shape for an agent that might forget to hang up.

## One sandbox, priced

The task: the agent has written a data-cleaning script and wants to run it against a sample file without touching the machine it is on.

**Create.** The agent asks for a Python container:

```json
{
  "service": "modal",
  "action": "sandbox-create",
  "params": { "image": "python:3.12" },
  "max_cost_cents": 5,
  "intent": "run a cleaning script on a sample"
}
```

The quoted price is under five cents, so it runs. The agent receives a sandbox id and a receipt for what was actually charged, about three cents for a CPU box at the time of writing. If the agent had asked for an A100 with a five-cent ceiling, the call would have been refused before anything started, with the actual price returned, because GPU tiers have their own caps and an agent has to mean it.

**Run.** The agent executes its script:

```json
{
  "service": "modal",
  "action": "sandbox-exec",
  "params": { "sandbox_id": "sb-abc123", "command": "python clean.py sample.csv" },
  "max_cost_cents": 2
}
```

One cent. The agent gets stdout, stderr, and the exit code. It reads the output, spots a bug, fixes the script, and runs it again. Another cent.

**Terminate.** The agent is done:

```json
{
  "service": "modal",
  "action": "sandbox-terminate",
  "params": { "sandbox_id": "sb-abc123" },
  "max_cost_cents": 2
}
```

One cent. Total for the job: about six cents, four calls, each one priced before it ran and billed only on success. The agent opened no account with Modal, holds no Modal token, and there is nothing Modal-specific anywhere in its environment. If it had needed a persistent box instead, the E2B path is `create_session`, then commands against the session, then `close`, and the meter runs from create to close.

## The controls that matter for compute

Compute has one failure mode that search does not: the meter that keeps running. Three controls address it, and the first is the one most people should set and do not.

**Take Compute out of the key's categories** if the agent does not need it. A research agent, a writing agent, a GTM agent has no business starting a container, and a key restricted to Search and Data will have every compute call refused before it runs, at no cost, no matter what the agent was talked into. This is a one-line policy and it eliminates the entire class of surprise.

**Set the per-call ceiling on every create.** For an agent that does need compute, the ceiling is what stops it accidentally provisioning a GPU. CPU creates cap at five cents; GPU tiers cap higher, and the agent has to state the tier's cap explicitly to get one. An agent that always writes `max_cost_cents: 5` on a create will never start anything more expensive than a CPU box, by construction.

**Prefer one-off sandboxes for one-off work.** A Modal sandbox dies on its own after its timeout. An E2B session bills until closed. An agent that opens persistent sessions has to be one you trust to close them, and the monthly limit on its key is the backstop if it does not: when the limit is reached, the next call is refused and the recorded reason tells you what happened.

Every create, exec, and terminate, with its price, sits in the agent history attributed to the key, which is where you will find the session that was opened on Monday and closed on Thursday.

## What this is not

This is not your IDE's cloud agent, your model provider's compute, or any vendor's usage credits. Those pay for the model that is thinking. This pays for the container the model asked for while it was thinking, and the two bills are separate, with separate controls. It is also not a way to buy a reserved instance or a monthly plan; every unit here is metered, per create, per command, or per second of uptime, and settled on machine rails, x402, Stripe's Machine Payments Protocol on Tempo, which is what makes a one-cent command economic in the first place.

The end-to-end workflow for choosing a box, getting data in and out, and cleaning up is in the [compute recipe](/recipes/compute). The controls are set as described in [how to give an AI agent a budget](/blog/give-an-ai-agent-a-budget).

```bash
npx @vaaya/mcp install
```

## Questions

**Can an AI agent start a sandbox and pay for it?**

Yes. Through Vaaya an agent can create a sandbox on Modal, E2B, Daytona, Runloop, or Fly.io, run commands in it, and terminate it, each step priced before it runs. A one-off Modal sandbox is a few cents to create and a cent per command; a persistent E2B session is metered by uptime.

**Is agent compute billed per second?**

Persistent sessions are metered by uptime and settle when the agent closes them. One-off sandboxes are billed per create and per command. Either way the agent states a maximum cost on each call and the account is billed only on success.

**Can I stop an agent from starting expensive compute?**

Yes. Restrict the agent's key so Compute is not in its categories and every compute call is refused before it runs. If the agent should have compute, the per-call ceiling caps each create, and GPU tiers carry their own caps that the agent must set explicitly.