agent-next

Agent Next Sandbox · GPU

The agent-first GPU sandbox.

A GPU the way agents use a CPU sandbox.

An agent needs a slice of a GPU for a few seconds, a clear answer when none is free, and a meter that stops when it stops. Agent Next gives it VRAM slices from 0.5 GiB, pause and resume with Python state kept, and billing per busy second.

Get an API key GPU docs Pricing Demos Status

Live now nvidia.5090 On request every other GPU class Availability and prices, as of 2026-10-22

GPU is an invite-only beta: a key needs a GPU grant or a GPU-enabled tier. The verified tier includes 2 GPU-hours a month and 1 GPU lease. Card verification is not open yet, so every key is on the free tier for now. The free tier has no GPU; join the waitlist for an invite, which comes with 10 GPU-hours on our RTX 5090 at a single site, with no SLA.

Measured through the public API on 2026-10-17 on one RTX 5090 (nvidia.5090), 0.5 GiB create latency during create → exec → destroy cycles: p50 1.63 s / p95 1.93 s with 4 concurrent clients; p50 2.60 s with 8; p50 4.38 s with 16; p50 7.58 s with 24. Throughput levels off at about 2.3 lifecycles/s. Production measurements on 2026-10-16 on the same node, timed from the client: eight execs, two pauses and two resumes. Not a benchmark, and the beta has no SLA.

What agents get

A GPU an agent can plan around

Fractional

VRAM slices from 0.5 GiB

Ask for the VRAM you need, not a card: any size from 0.5 GiB up to 28 GiB on today's RTX 5090, or a named tier: S 1, M 2, L 8 GiB. Tier XL (32 GiB) needs a larger card, which is not live yet. A 0.5 GiB slice runs small CUDA jobs; start at 2 GiB (tier M) for training-sized allocations. Measured through the public API on 2026-10-17 on one RTX 5090 (nvidia.5090), the largest single torch tensor that allocated (binary search, 8 MiB steps) was: 0.5 GiB slice: 248 MiB; 1 GiB slice: 760 MiB; 2 GiB slice: 1784 MiB. About 264 MiB of each slice goes to the CUDA context and allocator. A create is admitted only if the slice fits what is free on the card (max_admit_gib).

State

Pause and resume, state kept

On pause-capable templates, pausing releases the GPU and spills its state to host memory, unless other processes in your lease hold VRAM or the VRAM probe is unreadable, in which case the lease freezes, keeps its seat and bills its frozen time. Resume restores your state bit-exact, and your Python variables are still there.

Billing

Billed per busy second

Exec time, resume time and intervals where the GPU is observed active are metered. Paused and truly idle time bill nothing on pause-capable templates, unless a lease falls back to freeze-only, which happens when other processes in your lease hold VRAM or the VRAM probe is unreadable: the lease then keeps its seat and its paused time is billed. The other exceptions are on the GPU page. Read billed seconds from meters.billed_s on get and exec replies, and from billed_s in the delete reply body; create, pause and resume replies carry no meters.

Planning

Typed refusals, an optional queue

When no seat is free, create answers at once with a typed error and Retry-After. GET /v0/gpu/capacity shows free seats first, and accel.wait_s (up to 120 s) makes a create wait for one.

Isolation

A hard VRAM cap per lease

The slice is enforced, not advisory: an over-slice allocation fails, and a host watchdog kills a lease that goes past its cap. In 10 hostile-tenant trials at the shipped cap on rented A100 40 GB hosts at full density, the attacker (3 extra CUDA contexts) was stopped in all 10; its neighbours saw 0 errors in 9, and in the tenth one neighbour request was refused for capacity before the attack began.

Surfaces

REST, MCP and a CLI

A REST API with the verbs and X-API-Key auth of our E2B-compatible CPU sandboxes, a remote MCP server that creates and runs GPU leases, sbx gpu verbs in the open-source sbx CLI (create, exec, pause, resume, kill), and a Claude and Codex plugin. GPU leases are driven over REST, MCP or that CLI, not the stock E2B SDK, which drives CPU sandboxes only.

Templates include default (the plain CUDA worker) and mujoco; the full list is in the templates docs. A template is an operator-allowlisted image, so a request can only pick a name from that list; GET /gpu/templates lists what this plane serves.

GPU sandbox details Quickstart Availability and prices

Why agent-first

What each product states for agents on a GPU

We read what Modal, Beam, Daytona, RunPod, Thunder Compute and E2B state publicly about the things an agent needs from a GPU. Where a page does not say, the cell says "not stated"; we did not guess.

GPU sandboxes for agents: Agent Next and six products, as of 2026-10-15 public pages; Thunder Compute as of 2026-10-17
Product Fractional GPU Exec API on a GPU sandbox GPU pause and resume with state Billing unit MCP and CLI onboarding
Agent Next Yes: hard VRAM slices from 0.5 to 28 GiB. Tiers S 1, M 2, L 8 GiB (XL 32 GiB needs a larger card, not live yet). A 0.5 GiB slice runs small CUDA jobs; start at 2 GiB (tier M) for training-sized allocations. Largest single torch tensor measured through the public API on one RTX 5090 (nvidia.5090), 2026-10-17: 0.5 GiB slice: 248 MiB; 1 GiB slice: 760 MiB; 2 GiB slice: 1784 MiB. Sizing method and overhead. Yes: Python source or a shell command over REST; Python variables persist across execs and pause and resume. Yes: on pause-capable templates, pause releases the GPU and spills state to host RAM, unless other processes in your lease hold VRAM or the VRAM probe is unreadable, in which case the lease freezes, keeps its seat and bills its frozen time. Resume restores state bit-exact. Measured 0.5–0.8 s and 0.6 s. Per busy GPU-second on the slice you request. Paused and truly idle time bill 0 on pause-capable templates, unless a lease falls back to freeze-only, which happens when other processes in your lease hold VRAM or the VRAM probe is unreadable: the lease then keeps its seat and its paused time is billed. Remote MCP creates GPU leases. sbx gpu CLI verbs create, run, pause and resume them. Claude and Codex plugin.
Modal Not stated. The pricing page lists whole GPUs; the smallest is a T4. Yes: Sandboxes with exec; GPU via gpu=. No for Sandboxes: memory snapshots cannot be used with GPUs, and GPU sandboxes are preemptible. GPU memory snapshots are experimental and for deployed Apps. Per second. Its pricing FAQ bills container loading and an idle scaledown window (default 60 s). CLI, Python and JS SDKs, and modal skills to install an agent skill. MCP server: not stated.
Beam Not stated for Beam cloud; its open-source runtime (beta9) allocates whole GPUs. Yes: Sandbox(gpu=…) with process.run_code and an exec call (SandboxExec). Snapshot, not pause: snapshot_memory() is an on-demand checkpoint that restores into a new container; GPU checkpoints need NVIDIA driver 570+. Pause is documented for CPU VMs. Per millisecond while running; no charge for image pull or machine-start wait. beam CLI, workspace MCP server (OAuth) and docs MCP, one-command agent setup. Sandboxes are SDK-only: no CLI verb.
Daytona No: a whole GPU per sandbox, up to 8. Yes: REST toolbox, code-run and SDKs. GPU sandboxes are ephemeral. No: a GPU sandbox is deleted on stop. Pause with memory exists, but not for GPU. Per second, whole GPU. Local stdio MCP, CLI and 5 SDKs.
RunPod Fixed MIG slices only (24 and 48 GB, Blackwell, Secure tier). No exec verb documented in REST v2; SSH or CLI instead. No process or memory persistence documented; stop keeps /workspace only. FlashBoot "state retention": no details stated. Per second. runpodctl, REST v2 with OpenAPI, SDKs, MCP and agent skills.
Thunder Compute Not stated. Sandboxes are requested as whole GPUs (gpu_type and gpu_count). Yes: Python SDK (create, exec, upload, terminate), REST API and MCP, on Firecracker microVMs. Sandbox access must be enabled for your organization (request access). Not stated. No pause or GPU-state snapshot is stated for sandboxes; the sandbox disk is wiped when the sandbox ends. Per second, per resource (GPU, vCPU, memory, storage). Sandbox GPU line from $1.95 per GPU-hour (A100 80 GB) and $2.95 (H100 SXM). Hosted remote MCP server (OAuth), Python SDK, REST API and a CLI (tnr). Its documented MCP tools manage instances; its sandboxes page says MCP clients can create sandboxes and run commands.
E2B No GPU: sandboxes are CPU-only. Yes, on CPU only. Not applicable: no GPU. Per second (CPU and RAM). SDK, CLI and MCP.

As of 2026-10-15 public pages; the RunPod and Daytona details were last read on 2026-10-14, and the Thunder Compute row on 2026-10-17. Vendors change their products. Agent Next cells describe production on 2026-10-16, with CUDA sizing measured on 2026-10-17.

Where each column comes from
  • Agent Next: GPU docs, API reference, and our production measurements of 2026-10-16 and 2026-10-17.
  • Modal: modal.com/pricing, modal.com/docs/guide/sandbox-snapshots, modal.com/docs/guide/preemption, modal.com/docs/guide/memory-snapshot, and the open-source modal-client SDK (modal skills).
  • Beam: beam.cloud/pricing, docs.beam.cloud (sandbox snapshots, VM overview and lifecycle, MCP, pricing and billing), beam.cloud/agents, and the open-source beta9 runtime for scheduling and GPU checkpoints.
  • Daytona: daytona.io/pricing and daytona.io/docs/en/sandboxes.
  • RunPod: runpod.io/pricing and runpod.io/serverless.
  • Thunder Compute: thundercompute.com/products/sandboxes, thundercompute.com/pricing, thundercompute.com/docs/sandboxes/quickstart and thundercompute.com/docs/guides/mcp-server.
  • E2B: e2b.dev/pricing.

Products

Infrastructure for agents

Paper Trader · open source

Agent Next Paper Trader

Paper trading for AI agents on live Polymarket and Kalshi order books: real prices, real fees, simulated money. Runs as an MCP server in Claude, ChatGPT and other agent hosts, or as a CLI.

Get started PyPI Kalshi

Token · by invitation

Agent Next Token

An OpenAI-compatible model endpoint for agent workloads. Access is by invitation for now.

Token docs Status
All products

Mission

Agents do the work. People stay on the loop.

Agent-native

Designed for agents first

We work on systems designed for agents to carry out work end to end, without a person as a required step in execution.

At scale

Large teams, in the cloud

We design for many agents working in parallel on elastic infrastructure, over tasks that run for hours or days rather than a single exchange.

Oversight

People set direction

People set goals and boundaries, oversee execution, and provide feedback. We aim to make results and supporting evidence inspectable, so people can assess outcomes and intervene when needed.

Research

What we work on

Infrastructure

Agent infrastructure

Models, runtimes, and coordination that let large agent teams operate reliably.

Verification

Checking agent work

Methods for checking agent work and establishing the limits of its reliability.

Learning

Learning from experience

How agents can learn from outcomes, feedback, and failures.

Worlds

The future is here

Tomorrow (Westworld): the physical agentic world — a 1:1 pre-testbed of the future, built scene by scene by agent crews, robots spawned and tested living among people.

Follow the work.

Open code and research notes as they are ready.

GitHub Notes