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.
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 KlimaCEO, EnterBuild 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.
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.
- 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.
- 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.
- 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.
- 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 KlimaCEO, EnterMachines 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.
| Hosted sandboxes | On Sandal | |
|---|---|---|
| Time to first command | Tens of seconds, cold every time | 4.2 s average, under 200 ms from the warm pool |
| Cost while the agent waits | Full hourly rate | $0 while paused |
| Isolation | Shared kernel, per-container namespaces | Own kernel per microVM |
| Platforms | Linux only | Linux, macOS, Windows, iOS simulators |
| Parallel attempts | Reinstall per agent | Fork from a warm parent |
| CI | Separate vendor, CI pricing | Same 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.
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.
What Enter’s story says about running agents
- 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.
- 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.
- 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.
- 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.