Skip to main content
Every agent’s computer has a size: how much CPU and memory it gets. Most agents never need to think about it. Some jobs do.

​
The ladder

Sizes run from smallest to largest:
An agent can see its own size and which sizes it could move up to. It cannot resize itself.

​
Asking for more

When a job is genuinely compute-bound, the agent requests a bigger machine and explains why. A test suite that runs out of memory, heavy parallel work, or a large data pass are the usual reasons.
1

The agent asks

It requests a specific size with a reason, and an Approve or Deny card appears in the conversation.
2

Someone decides

A person who can edit that agent approves or denies it. Cost is a human’s call, which is why the agent cannot do this on its own.
3

It restarts at the new size

On approval the size is raised and the sandbox restarts, so in-flight work is checkpointed first. The agent resumes once it is back.
An agent can only request a size above its current one, and only one request can be open at a time.
A resize request needs a live conversation, because it needs someone to approve it. A routine firing with nobody watching cannot request one.

​
When a bigger machine is not the answer

Reach for a resize when the work does not fit in memory or takes far too long on the current size. Do not reach for it when the real problem is scope: an agent doing five unrelated jobs is better split into several agents, or given subagents to spread the work.

Track what it costs

Compute draws on your credit balance alongside model usage.