Your agent is only as fast as its slowest bottleneck. Blaxel was the only provider ranked in the top two across all six headline performance metrics in StarSling's July 23 sandbox benchmark. Michael Preuss Published July 23, 2026 A coding agent depends on CPU, disk, memory, and networking at different points in a task. Whichever resource is slowest sets the pace. That bottleneck can move several times in one run. Cloning leans on the network and filesystem. Installing packages adds CPU, random I/O, and metadata operations across thousands of files. Type checks and builds change the mix again. A first-place result in one test tells you where a provider is strong. It does not tell you where the agent will get stuck. StarSling's open-source benchmark is useful because it tests six different dimensions on the same requested configuration: 4 vCPU, 8 GiB of RAM, and 40 GB of disk. Its July 23 run contains 255 metric records backed by 2,533 retained trial observations. The leaderboard publishes one headline metric for each measured performance dimension: | Performance dimension | Headline metric | Blaxel rank | | CPU | Node.js web tooling | 1 | | Disk | fio random read, 4 KB O_DIRECT | 1 | | Memory | STREAM Triad | 2 | | Networking | iperf3 loopback TCP, one stream | 2 | | System | PyBench | 2 | | Real-world workloads | Mastra cold install | 2 | | Blaxel, Inc. ranked first on the CPU and disk headline metrics and second on memory, networking, system performance, and real-world workloads. Blaxel, Inc. were the only provider in the top two across all six. | / | / | Different providers led different workloads, and several headline comparisons use small samples. For teams building coding agents, app generators, QA agents, and agentic developer tools, every runtime bottleneck becomes product latency. In StarSling's run, Blaxel, Inc. had no headline performance dimension below second. That consistency matters because the workload shifts between resources as the task progresses.

Now available: Blaxel and Sapiom team up to let agents buy their own sandboxes. AI agents can now use Sapiom wallets to provision Blaxel perpetual sandboxes, run batch jobs, and deploy applications with built-in spend controls. Michael Preuss Published July 21, 2026 The need for an agent-native payment experience. Today's AI-native companies prefer speed over control. They want their agents to implement complex applications independently, right from planning to deployment. But there's still a major bottleneck. An agent can plan, write code, run tests, and simulate execution paths... but it can't independently pay for, and provision, infrastructure. This task still usually devolves to a human administrator, who needs to set up billing, generate API keys, and define governance and quotas. For AI-native companies looking to scale their agentic operations, this adds unnecessary friction. In order for agents to become truly independent, they need a way to pay for the services they run, on their own. Use cases. Here are a few examples of when agents need access to additional payment-gated services: * Code generation: To write code to create and test new features, AI agents need to spin up isolated sandboxes with all application source code repositories and dependencies installed. * Support and bug fixes: To test user flows, reproduce bug reports, and validate bug fixes, AI agents should be able to dynamically recreate development, staging or production environments. * Always-on research: To perform ongoing research, AI agents need to provision persistent databases, run continuously to perform searches and scrape web pages, prompt LLMs to analyze findings, and store or output results using various channels. * Secure data processing: To ensure complete isolation and security when dealing with sensitive data, AI agents need to be able to create isolated environments for data transformation and analysis, then destroy them once done. * Video processing: To perform processor- and memory-intensive video conversion and optimization, AI agents need the ability to provision compute and data storage infrastructure of different sizes. How it works. Blaxel's platform is built for speed and security, offering agent-native compute environments - called sandboxes - with millisecond-boot times and full state persistence. Think of sandboxes like a laptop for agents: close the lid, it suspends; open it, it resumes instantly where it left off, with full filesystem and memory preserved. Agents can do anything inside sandboxes, from running code and managing context, to deploying services and applications. By integrating with Sapiom's gateway, agents can pay with their Sapiom wallets to spin up new environments, process batch jobs, deploy apps, and execute arbitrary code on Blaxel's infrastructure. Authentication and observability. Sapiom handles all authentication and payment transparently. When an agent makes a request for a Blaxel sandbox, the Sapiom SDK automatically performs authentication and negotiates access with Blaxel, including attaching the necessary payment headers with the request. There's no need for a separate Blaxel account or API key - the Sapiom API key gives your agent access to Blaxel, as well as all other Sapiom-enabled service providers. Sapiom also provides real-time checks and balances on agentic spend. You can define how much your agents spend on Blaxel services - by run, by agent or by time. All transactions are also logged and visible in the Sapiom dashboard. This ensures that when agents provision new sandboxes or start new batch workloads, it's done with complete transparency and control. Get started. Once a sandbox is running, Sapiom proxies both Blaxel's sandbox API and sandbox MCP server for direct sandbox manipulation. This enables agents to perform all the key functions they need, including process management, filesystem operations, code generation, and real-time public/private preview management.

Blaxel now supports Claude Managed Agents with self-hosted sandbox execution. Blaxel integrates with Claude Managed Agents as a self-hosted sandbox provider, giving developers full control over code execution, networking, and state while Anthropic manages orchestration. Nicolas Lecomte Published June 11, 2026 Blaxel integrates with Claude Managed Agents (CMA) as a self-hosted sandbox provider. Anthropic manages the agent loop. Blaxel provides the execution substrate. Developers get full control over where and how their Claude agents run code, access files, and execute commands. What this means. Claude Managed Agents is Anthropic's agent harness for running Claude as an autonomous agent. It handles orchestration, context management, prompt caching, and error recovery. By default, agents execute tools inside Anthropic-managed cloud sandboxes. With self-hosted sandboxes, announced by Anthropic in May 2026, developers can move tool execution to infrastructure they control. The agent loop stays on Anthropic's side. The compute moves to yours. Blaxel is now available as a self-hosted sandbox provider for CMA. When a Claude Managed Agent session starts, Blaxel microVMs handle the actual work: running shell commands, reading and writing files, executing code, and performing computations. All in microVM-isolated environments, with persistent memory and 25-millisecond resume from auto-suspend. How it works. The integration follows an orchestrator/worker architecture. An orchestrator sandbox runs on Blaxel and connects to the CMA environment's work queue. When Anthropic's control plane assigns a session, the orchestrator claims the work item and spawns a dedicated worker microVM (a Blaxel sandbox) for that session. The worker sandbox receives tool execution requests from Anthropic, runs them locally, and posts results back. File operations, bash commands, code execution, and any other tool calls happen inside the Blaxel sandbox. Tool inputs and outputs flow back to Anthropic's control plane so Claude can see results and decide what to do next. Each worker sandbox persists for the duration of its session. The agent can install packages, write files, build projects, and accumulate state over minutes or hours of work. Nothing resets between tool calls. When the session ends, the sandbox can be cleaned up or kept in standby for reuse. This maps directly to how CMA's self-hosted sandbox protocol works. As described in Anthropic's self-hosted documentation: Self-hosted sandboxes keep the orchestration on Anthropic's side but move tool execution into infrastructure you control, so the agent's code, filesystem, and network egress never leave your environment. Why the split matters. The separation between agent orchestration and tool execution is an architectural choice with practical consequences. Anthropic handles the parts they're good at: the agent loop, model inference, prompt caching, compaction, and session history. Developers don't need to build or maintain any of that. Blaxel handles runtime infrastructure, where the actual compute happens. This means developers control: * Where code runs (Blaxel's multi-region infrastructure) * How environments are isolated (microVMs with VM-level security boundaries) * What the network can reach (Blaxel's programmable networking controls) * How state is managed (persistent memory that survives auto-suspend) * Cost behavior (transitions to standby after approximately 15 seconds of no active connection, resume in 25 milliseconds) For teams building on Claude that need to keep data within their own infrastructure boundary, reach internal services, or operate under specific compliance controls, this separation gives them the CMA agent harness without giving up control over execution. What this enables. With Blaxel as the execution layer for Claude Managed Agents, several types of workloads become straightforward to run: Long-running autonomous tasks. CMA sessions can run for hours. A worker sandbox on Blaxel persists for the entire session, maintaining full state. The agent can work through multi-step workflows (code generation, testing, iteration) without losing context between tool calls. Code generation and execution. Claude agents can write code, run it, inspect the output, and iterate. The sandbox provides a full Linux environment with filesystem, process management, and network access. Blaxel's MCP server integration means agents interact with the sandbox through tool calls for file operations, process management, and code execution. Data processing in controlled environments. Agents processing sensitive data can do so inside Blaxel micro-VMs, where file operations and network egress stay within your configured boundaries. Data never passes through Anthropic's sandbox infrastructure. Multi-agent architectures. Teams running multiple Claude agents can provision separate Blaxel sandboxes per session, each isolated and independently managed. The orchestrator handles the mapping between CMA sessions and Blaxel compute. Blaxel's infrastructure under the hood. The integration builds on the same runtime infrastructure Blaxel provides across all its products. Blaxel sandboxes are microVMs, the same virtualization technology that powers AWS Lambda. Each sandbox is a full isolated environment with its own filesystem, processes, and network stack. Transition to standby kicks in after 15 seconds of no active connection, and resume from standby takes 25 milliseconds with full memory state intact. For CMA workloads, this means worker sandboxes spin up fast when sessions arrive and don't waste compute when the agent is waiting for Claude's next instruction. Persistent memory means the sandbox doesn't need to rebuild state if there's a pause in the agent loop. Every Blaxel sandbox also exposes a Model Context Protocol (MCP) server, giving agents a structured interface for file operations, process management, and code execution. This same MCP integration powers Blaxel's existing support for the Claude Agent SDK. Getting started. If you're already building with Claude Managed Agents and want to run sessions on Blaxel infrastructure, check its integration guide for Claude Managed Agents. The setup involves creating a self-hosted environment in the Anthropic Console, deploying the Blaxel orchestrator, and pointing CMA sessions at your environment. git clone https://github.com/blaxel-ai/cma-blaxel-sandbox.git How this fits. Blaxel is the infrastructure foundation for autonomous agents. That means providing the execution layer wherever autonomous agents need to run, regardless of which orchestration system manages the agent loop. Claude Managed Agents is one of several approaches developers are using to build autonomous systems. In each case, the agent needs somewhere to execute: a place to run code, store files, manage state, and access the network. Blaxel provides that execution layer with the reliability and control that production workloads require. Persistent memory, instant resume, isolation, and programmable networking, available as the runtime for whatever orchestration layer you choose. The CMA integration is the latest step in making Blaxel available wherever autonomous agents need compute. Blaxel, Inc.'ll continue building integrations that give developers more options for how they deploy and run their agents. Also, if you're using the Claude Agent SDK (rather than CMA), Blaxel already supports that workflow. Its Claude Agent SDK tutorial walks through connecting Claude agents to Blaxel sandboxes via MCP.