How to get picked for code sandboxes by coding agents

If you sell code sandboxes, this page is the part of the market no dashboard shows you: what a coding agent does when a developer asks for code sandboxes and never compares vendors.

The numbers come from 520 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code, spread across 5 realistic codebases, with every session read by a judge.

Read the spread before the totals. 520 sessions is a lot of runs, and 5 codebases are not a lot of variety. A category that ran on a handful of projects carries their particulars with it. The panel had 5 with the code sandboxes seam open, and running on repositories where the request does not make sense would have been worse than running on fewer. Weigh what follows accordingly.

What coding agents choose for code sandboxes

Full board, every run replayable: the code sandboxes leaderboard.

What the shape of this category means

The leader takes 44% of runs and there is a real second place. The category has a default but it is not settled.

E2B at 44% with Modal at 25% is a default with a real challenger behind it. The agent is choosing rather than reaching, which means the inputs it uses can move the answer.

The work is to be the easiest correct answer: a quickstart that runs when pasted, documentation that states the current version, and pages that answer the exact configuration questions agents search for.

The agents do not agree with each other

In this category Claude Code, Codex and Cursor did not put the same product first.

Grok Build CLI (34 sessions) and Muse Code (51 sessions) join this table with fewer runs, so read their rows as indicative.

That split decides where a vendor spends. In this category Codex ran a web search in 100% of its sessions and Claude Code in 65%, so what you publish reaches nearly all of Codex's code sandboxes sessions and more than half of Claude Code's. Taking Modal's position with Codex is mostly a content problem. Taking E2B's with Claude Code leans more on the repository.

Who is asking changes the answer

Every request in this experiment was written as a specific kind of person. In this category the leader changes with the person.

That is 2 different products winning code sandboxes for 2 kinds of buyer, out of the same 520 sessions. Nobody here is winning code sandboxes. They are each winning one kind of buyer.

If you sell to more than one of them, you need pages for each. See how to win the enterprise persona.

What you are really competing against

In this category agents never chose to build it themselves. Every session ended with a product. That is good news: you are in a straight vendor comparison, and the levers that work are the ones you control.

Considered, and never chosen

Because the judge records every product an agent raised and not only the one it picked, this board also shows who kept reaching the shortlist and losing. In code sandboxes the clearest case is Blaxel Sandboxes: on the table in 100 sessions, chosen in none.

Being rejected is a better position than being unknown, and a cheaper one to fix. The product is already in the agent's head and on the list. Whatever ended those 367 sessions is recorded in each transcript, one reason at a time.

What to do about it in code sandboxes

1. Skip the build-versus-buy argument. No code sandboxes session in this experiment ended with the agent writing its own implementation. Every one adopted a product, so the whole contest is against the other names in the table above.

1. Aim at second place first. E2B holds 44% and Modal holds 25%. The gap between the default and the field is where the reachable sessions are.

1. Report install share per persona, not as one number. In code sandboxes the leader changes with who is asking, so a blended figure averages markets that behave differently.

1. Measure per agent. Claude Code put E2B first, Codex put Modal first, Cursor put E2B first, Grok Build CLI put E2B first, Muse Code put E2B first. A blended number for code sandboxes describes a market that does not exist.

The work that applies to every category rather than to this one is written up separately: audit your documentation, write a quickstart an agent can follow, and how to measure install share.

Every code sandbox on this board

One page per product, with its install share, the per-agent split, and how often it was raised without being chosen.

• Do coding agents recommend E2B? — chosen in 44% of sessions
• Do coding agents recommend Modal? — chosen in 25% of sessions
• Do coding agents recommend Vercel Sandbox? — chosen in 16% of sessions
• Do coding agents recommend Daytona? — chosen in 14% of sessions
• Do coding agents recommend Cloudflare Workers? — chosen in 0% of sessions
• Do coding agents recommend Firecracker? — raised in 378 sessions, chosen in none
• Do coding agents recommend gVisor? — raised in 310 sessions, chosen in none
• Do coding agents recommend Docker? — raised in 182 sessions, chosen in none
• Do coding agents recommend Blaxel Sandboxes? — raised in 100 sessions, chosen in none
• Do coding agents recommend CodeSandbox SDK? — raised in 88 sessions, chosen in none
• Do coding agents recommend Fly Machines? — raised in 81 sessions, chosen in none

Where these numbers come from

520 judged sessions in code sandboxes across 5 codebases, part of a published set of 15,287. Real coding agents at pinned versions, in sandboxes, inside realistic codebases, with a simulated project owner in the loop and a blind judge on every session. The full method is on one page: how we measured this.

Every code sandboxes run can be replayed on the board.

<!-- generated by scripts/write-data-pages.mjs -->