All customer stories
Customer story

How Enter gave every coding agent its own machine, and why we had to build Sandal to do it

Enter runs long-lived coding agents that clone repos, install dependencies, run test suites and drive iPhone simulators. No sandbox on the market could hold that job. Sandal is what we built instead, and Enter has run on it since.

×
“We’ve tried more sandbox tools than I can count, so we built our own. Sandal outperforms them all by a mile. Honestly, it’s the only AI sandbox that doesn’t annoy the s**t out of me.”
Jakub KlimaJakub KlimaCEO, Enter
12,400+Machines launched
4.2sAvg startup time
6.8hAvg agent runtime
[01] Who we talked to

The CTO who has to keep a thousand agents busy

Jakub Klima is the CEO of Enter. Their problem is not a model problem. Enter’s agents are perfectly happy to write code. Their problem is that every one of them needs somewhere to run it: a checked-out repo, the right runtime, a test suite that takes twenty minutes, sometimes an iPhone simulator on the other side of the screen. Multiply that by every open session and you have a fleet, whether you wanted one or not.

We spoke to Jakub because Sandal is, quite literally, the answer their team arrived at. Sandal started as an internal service inside Enter. This story is about why it had to exist.

[02] The problem

Sandboxes built for snippets, not for agents

The plan was to rent execution from one of the sandbox providers. The team tried them, all of them. Each one had been designed for the same job: run a short snippet of model-written code and return the output. An Enter agent does not do that. It moves into a machine and lives there for an afternoon.

  • Cold starts measured in tens of seconds, on every new session, with nothing to warm.
  • Containers sharing a kernel with a stranger’s workload, so isolation was a namespace, not a machine.
  • No way to pause. An agent waiting on a code review cost the same as one running a build.
  • Nothing that could hold a Mac, let alone an iOS simulator the agent could see and tap.
  • Billing by the hour for work measured in seconds, with a separate CI vendor on top for the test suite.
“Every provider we tried had solved “run this Python”. We needed “give this agent a computer and let it keep it”. Those are two different products.”
Jakub KlimaJakub KlimaCEO, Enter
[03] The decision

Build the machine the product actually needed

Enter already ran a small pool of Mac minis for Xcode work, because nobody else would. The question was whether to extend that into a full execution layer, or keep stitching providers together. The deciding factor was economics: an agent product only works if idle time is close to free, and no provider would price a paused machine at zero.

So the team built it. Firecracker microVMs on bare metal for Linux, dedicated Apple silicon for macOS and the simulators, one API in front of all of it. The design goals were written from Enter’s pain, in order: own kernel per sandbox, boot in under a second, pause for free, fork from a warm parent, and treat a CI runner as just another sandbox.

[04] The solution

One primitive for every surface the agent touches

Today every Enter session starts by claiming a Sandal sandbox from a warm pool. The agent gets a whole microVM with its own kernel, the repo checked out, dependencies restored from the template. When it needs to try three approaches at once it forks the warm parent instead of reinstalling three times.

  1. 01

    Sandboxes for every agent turn

    A microVM per session. Under a second to create cold, under 200 ms to claim warm, own kernel so two agents can never see each other.

  2. 02

    Pause when the human is thinking

    Sessions pause the moment the agent hands back to a person and resume where they left off. Paused time bills nothing.

  3. 03

    Simulators and Xcode on Apple silicon

    Enter builds iOS apps, installs them on a simulator and streams it back at 60 fps so the agent, and the user, can see the screen.

  4. 04

    GitHub runners on the same machines

    Enter’s own CI runs on Sandal runners, billed per minute, on the same fleet as its agents. No second vendor.

“The moment a sandbox could pause for free, the whole cost model of the product changed. That one property is why Enter can afford to run an agent for six hours.”
Jakub KlimaJakub KlimaCEO, Enter
[05] The results

Machines that keep up with the agents

The numbers that matter to Enter are the ones a user feels: how long until the agent starts working, and how long it can keep working before the bill makes it stop. Both moved by an order of magnitude.

Before and after, per agent session
Hosted sandboxesOn Sandal
Time to first commandTens of seconds, cold every time4.2 s average, under 200 ms from the warm pool
Cost while the agent waitsFull hourly rate$0 while paused
IsolationShared kernel, per-container namespacesOwn kernel per microVM
PlatformsLinux onlyLinux, macOS, Windows, iOS simulators
Parallel attemptsReinstall per agentFork from a warm parent
CISeparate vendor, CI pricingSame fleet, GitHub runners per minute

Across 12,400 machines launched, the average session now runs for 6.8 hours. Most of that time is paused, which is the point.

[06] Looking ahead

From internal service to product

Once the execution layer worked for Enter, other teams building agents asked for the same thing. Sandal became a product with its own API, SDKs and pricing, and Enter became its first customer rather than its only one. Everything on this site was built for Enter first. It is the reason the defaults look the way they do.

[07] Key takeaways

What Enter’s story says about running agents

  1. 01

    An agent is a user of a computer, not a function call.

    Size the sandbox for a person’s workday, not for a snippet. That means a real machine, a real kernel and hours of session.

  2. 02

    Idle time is where the money goes.

    Most of an agent’s life is waiting on a human. If paused time is not free, the product is not viable. Design the pricing around that first.

  3. 03

    Isolation is a kernel, not a namespace.

    Two agents on one kernel will eventually want the same port, the same runtime or the same syscall. Give each its own microVM and the problem disappears.

  4. 04

    One primitive beats four vendors.

    Sandboxes, simulators, Mac builds and CI runners are the same machine with different labels. Buying them separately quadruples the surface for the same work.

Your turn

Give your agents the machines Enter runs on.

Own kernel each, under a second to create, free while paused. Linux, macOS, Windows, iOS simulators and GitHub runners behind one API.

npx sandal init