When to Use ORB

Use ORB when

Your workload is a persistent process that needs to stay alive across tasks.

An AI agent needs a full environment — files, packages, running processes, network. It works on tasks, waits for new ones, and picks up where it left off. ORB gives each agent its own computer that costs nothing when not actively working.

Good fits:

Don't use ORB when

Your workload is short-lived or stateless.

If you run a script, get a result, and you're done — you don't need a persistent computer. A simpler tool is better:

WorkloadBetter optionWhy
Run a script, return outputDocker, Lambda, ModalNo state to preserve. Run and discard.
Stateless API callCloud functionNo persistent process needed.
One-shot code executionE2B, DockerSandbox spins up, runs, tears down.
Batch processingLambda, Fargate, ModalScales horizontally, no per-process state.
CI/CD pipelineGitHub Actions, BuildkitePurpose-built for build/test workflows.

The key question: does your process need to stay alive between tasks?

If yes — ORB. Your agent keeps its state, sleeps when idle, wakes when needed.

If no — use something simpler. Docker, Lambda, or a plain VPS.

ORB vs alternatives

ORBVPSDockerLambdaE2B
Persistent processYesYesYesNoNo
Sleeps when idleYesNoNoN/ANo
State survives idleYesYesYesNoNo
Cost at 1,000 idle agents~$500/mo~$30,000/mo~$30,000/mo$0 (but no state)~$10,000/mo
Full Linux environmentYesYesYesNoLimited
Sub-second wakeYesN/A (always on)N/ACold start 1-10s~200ms boot
API-managedYesNo (SSH)Docker APIYesYes

The exec trap

If you're only using ORB's exec endpoint to run one-off commands (run script → get output → done), you're not getting ORB's value. That's just a remote shell — any VPS does it.

Deploy your agent as a persistent process inside the computer. That's where ORB's advantage kicks in.


Wrong: exec "python3 review.py --pr 123" → get result → computer sits idle
Right: deploy review agent → agent receives tasks → agent sleeps between tasks → wakes instantly