AI Agent Sandbox: Give Claude Code or Cursor an H100 (2026)

Every result for "AI agent sandbox" right now is a CPU code-execution tool: E2B, Daytona, Modal, something built on Firecracker or gVisor. All of them solve the same problem, running agent-generated Python safely in under a second. None of them give the agent a GPU. Spheron's Agent GPU Sandbox does: Claude, Claude Code, Cursor, Codex CLI, or any remote MCP client connects to one URL and deploys a real GPU VM, H100 through B300, that it operates with sudo for as long as the task needs. This is that sandbox end to end, connect command to final cost.

TL;DR: What Is Spheron's AI Agent Sandbox?

An AI agent sandbox usually means a CPU box for running code snippets; Spheron's is the one that hands the agent an actual GPU it can run sudo on for hours, through a single MCP connection, connect.spheron.ai/mcp.

• Connection: one URL, connect.spheron.ai/mcp, works across Claude, Claude Code, Cursor, Codex CLI, and any other remote MCP client, as of 11 Nov 2026.
• Setup time: a sandbox VM moves from setting up to ready in 1-3 minutes as of 11 Nov 2026, against a 125-200ms cold Firecracker boot (5-30ms with snapshot-restore) for the CPU sandboxes that currently rank for this query.
• Hardware: RTX cards and A100 through H100, H200, B200, and B300, single or multi-GPU, with none of them resetting state between tasks.
• Cost: the sandbox is free; you pay the GPU instance's normal hourly rate, with Spheron's on-demand H100 at $3.77/hr as of 11 Nov 2026.
• Safeguards: every deploy, Stop, Start, and terminate needs explicit approval against a price preview, the VM opens no inbound port, and only the deploying account can use its sandbox.

See the live on-demand rate on the H100 GPU rental page, the tier most of these jobs start on.

What the Agent GPU Sandbox Actually Is

Strip away the chat interface and the Agent GPU Sandbox is a system service: a small program that runs on a GPU VM, connects outbound to Spheron over HTTPS, and survives reboots. It opens no inbound port in either direction, which is why nothing has to be exposed to the internet for an agent on your laptop to reach a GPU on Spheron's marketplace. The service reports its own status back through that one connection, moving through setting up, ready, not reachable, or setup failed, so you always know which state the machine is in before a command gets sent.

That machine is not a container that disappears when the task ends. Packages, models, and checkpoints stay on it between tasks: an agent that installed a training stack yesterday doesn't reinstall it today. The deploying user's own SSH key keeps working on that same machine the whole time, so a human can get on the box directly and read a log file without going through the agent at all.

The sandbox also only accepts offers it can operate. It supports GPU tiers from RTX cards and A100 up through H100, H200, B200, and B300, as single or multi-GPU instances, on offers that take a startup script or SSH setup; an offer that doesn't is refused before anything gets created.

How to Connect Claude Code, Cursor, or Codex CLI

Every one of these clients reaches the same sandbox through the same address, connect.spheron.ai/mcp, because all of them speak the remote MCP transport. The difference is only where each tool keeps its list of servers.

1. Claude Code adds a remote HTTP MCP server with a documented command: claude mcp add --transport http <name> <url>, the same pattern Claude Code's own docs use for a server like Notion (claude mcp add --transport http notion https://mcp.notion.com/mcp). For Spheron that becomes:

   claude mcp add --transport http spheron https://connect.spheron.ai/mcp

2. Cursor and Codex CLI add the same URL through their own MCP configuration screens or config files. Neither needs a different protocol, since a remote MCP server is defined by its URL and transport, not by which client is calling it.
3. Once connected, ask for a GPU task in plain language. The agent proposes a tier, shows a price preview, and waits for your approval before anything is created or billed.

Claude Code's older SSE transport is now deprecated in favor of HTTP, so the command above is the current path, not a legacy fallback.

What Happens After You Send a Prompt

A prompt like "fine-tune Llama 3.1 8B on my dataset on an H100 and report the eval loss" starts with the agent picking a GPU tier and showing you its price before deploying anything. Once you approve, the VM moves from setting up to ready, which the docs put at 1-3 minutes, and the agent begins running commands against it over that same connection.

Two limits shape how those commands behave. A foreground command is capped at 10 minutes by default, which covers a quick check but not a real training run. Anything longer needs explicit background mode, which can run for up to 24 hours before it needs restarting, enough for most fine-tuning and benchmarking jobs. Either way, only the first 1MB of output comes back into the chat; the full log is saved to /var/log/spheron-agent/ on the machine, so SSH access still gets you the whole thing even when the chat summary is truncated. File transfer in either direction is capped at 5MB per file, so a large dataset has to be pulled directly on the box rather than piped through the conversation.

The Safeguards: Spend Limits, No Inbound Ports, Owner-Only Access

Handing an agent sudo on a GPU is a real risk, and the design bounds it rather than pretending it away.

• Approval on every state change. Spheron's own feature page states that every deploy, Stop, Start, and terminate shows a price preview and requires explicit approval, so nothing gets created or billed without a yes first.
• No inbound port, ever. The sandbox program only opens an outbound HTTPS connection; nothing reaches the VM from the internet through the sandbox itself.
• Owner-only access. Only the account that deployed an instance can use its sandbox.
• A spend limit per connection, so a runaway background loop can't turn into an open-ended bill.
• A logged, SSH-reachable machine. Every command the agent runs is logged, and the deploying user's own SSH key keeps working throughout.

GPU Sandbox vs a Code Execution Sandbox: Not the Same Tool

Every tool ranking for "ai agent sandbox" right now, E2B, Daytona, and the Firecracker or gVisor stacks underneath them, solves a narrower problem than the one this post is about: isolating a short snippet of agent-generated code, not running a sustained GPU workload. The two are built for opposite ends of the same spectrum.

Neither tool replaces the other. If you're building a product where many end users submit code to run, a CPU sandbox is still the right layer, and a fuller look at self-hosting that stack, Firecracker, E2B, and Daytona on bare-metal GPUs, covers that problem on its own. The Agent GPU Sandbox is single-tenant by design: it's built for one person's own agent operating one GPU for a sustained job, not a multi-tenant execution platform.

What People Are Actually Using It For

Spheron's feature page lists six example prompts. Four have their own full walkthrough on this blog with the exact commands, GPU choice, and output:

• Fine-tuning: fine-tune a LoRA from a single Claude Code prompt, including the exact prompt and the adapter it saves.
• Engine benchmarking: benchmark vLLM against SGLang from chat on the same model, with tokens per second and time to first token reported back for both.
• Checkpoint evaluation: compare LLM checkpoints from chat with MMLU and GSM8K scored side by side before promoting one.
• Reward model training: train a reward model from a chat prompt, walking through TRL's RewardTrainer on a LoRA-adapted base model.

The remaining named prompts, running a failing CUDA test suite, debugging a kernel crash on Hopper, and embedding five million rows, point at the same mechanism without a dedicated post yet.

For the inverse setup, deploying GPU-backed tools for agents to call rather than having an agent deploy the GPU itself, see deploying GPU-accelerated MCP servers.

What It Costs

The sandbox program carries no fee of its own. What you pay is the GPU instance's normal hourly rate for however long it runs, the same rate shown as a price preview before you approve the deploy. Spheron's on-demand H100 currently runs $3.77/hr as of 11 Nov 2026, and the rate for every supported tier through B300 is visible before the agent spends anything.

The cost variable most people miss is idle time: a sandbox VM keeps billing at its hourly rate until you stop it, so a job that finishes at 2am and sits ready until morning has been running up that rate the whole time.

Pricing fluctuates based on GPU availability. Spheron rates above are live as of 11 Nov 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.

If your agent's next task needs more than a sandboxed snippet, give it a GPU it can actually run a sustained job on.

Connect your agent to the Agent GPU Sandbox →