Hyperlambda
Ask a modern AI agent "what is 2 + 2?" and, if it has to actually execute that as a tool call rather than recall it, here is what typically happens: a frontier model runs a forward pass to decide what to do, hands that decision to an isolated execution environment, that environment boots, runs 2 + 2, returns the answer, and tears itself down.
Measure the energy for that, end to end, against a whitelisted Hyperlambda dispatch doing the identical job inside a process that was already running — and the ratio lands at roughly 17,000,000 to 1.
This is that calculation, run in the open, naming every sandbox provider I compared it against.
Every name, not a strawman
The "agent writes code, a sandbox runs it" pattern isn't one company's product. It's the industry's default answer to a hard problem: an LLM can write arbitrary code, and arbitrary code needs to run somewhere that can't be harmed if the code turns out to be wrong, hallucinated, or hostile.
OpenAI's Code Interpreter popularized the pattern. In April 2026, OpenAI's Agents SDK made it official by shipping native, first-class support for seven hosted sandbox providers: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. That's not a list I assembled to make a weak case — it's OpenAI's own blessed roster.
A one-line read on each, from their own public positioning:
- E2B — on-demand Linux VMs via Firecracker microVMs, a writable filesystem per session.
- Daytona — leads with startup speed, advertising sub-90ms cold starts.
- Modal — serverless, gVisor-isolated containers, the only one of the seven with first-party GPU sandboxes.
- Vercel Sandbox — built around Next.js/TypeScript workflows.
- Cloudflare, Runloop, Blaxel — newer entrants, each built specifically around coding-agent execution.
Every one of these is a real, well-built product solving a real problem: letting arbitrary, untrusted code run without threatening the host. None of them is why this number is what it is. The number exists because of what isolation itself costs, no matter who implements it well.
What isolation costs, honestly
Two ways to get 2 + 2 computed by an agent:
Hyperlambda dispatch. A tree-walk interpreter resolves one function by name against an explicit, per-role vocabulary, and runs it. No model inference. No environment to provision.
math.add
.:int:2
.:int:2
yield
result:x:@math.add
LLM + sandbox, worst case. A frontier model interprets the request and produces a tool call, which then provisions a sandbox to actually execute it — the worst-case path, since it's the one every one of the seven providers above exists to serve.
| Hyperlambda dispatch | LLM + sandbox (worst case) | |
|---|---|---|
| Energy | 3.33 × 10⁻⁵ J | ~564 J |
Hold that 564 J figure loosely for a moment; the next section is where it's actually built, cycle by cycle on one side and FLOP by FLOP on the other.
Send the computation, not a description of it
The alternative isn't "make the sandbox faster." It's not sending natural language to interpret in the first place. An agent that already knows it needs to add two numbers can send the computation itself:
math.add
.:int:2
.:int:2
yield
result:x:@math.add
That's not pseudocode standing in for "real" code — it's the literal, executable payload. No compilation step, no container image, no runtime to attach to. It arrives, gets checked, and runs in the same process that received it.
Why no sandbox is needed here
A sandbox exists to contain code that might do anything. Hyperlambda's safety model takes a different position: before a single statement runs, every function it references is checked against an explicit, per-role vocabulary — in Eval.cs, the slot dispatcher that's the only path a user-authored statement can take to actually execute. A name that isn't in the vocabulary doesn't get refused after the fact — it was never dispatchable to begin with.
That's a structurally different guarantee than isolation. A sandbox says: whatever this does, it can't escape. A whitelist says: this specific thing is the entire set of things that can happen, full stop. The second one doesn't need a VM boundary, because there's nothing outside the vocabulary for the code to reach in the first place. I've written about this mechanism end to end before, in The Only Sandbox Your AI Agent Cannot Break Out Of and Zero-Hallucination Code Generation — this article isn't re-deriving that case, just using it.
The cycle-level math
Here's where the 3.33 × 10⁻⁵ J actually comes from — counted, not estimated from a vendor's Wh figure:
| Step | What happens | Cycles |
|---|---|---|
| Parse the snippet | Lex ~60 characters, allocate ~5 node objects | ~1,500 |
| Whitelist check | Scan the active vocabulary for math.add | ~1,300 |
| Resolve the slot | Dictionary lookup + cached DI resolution | ~250 |
| Execute | Read two values, add, set result | ~100 |
Whitelist + resolve + execute yield | Same shape, second statement | ~1,800 |
| Interpreter loop overhead | Two iterations, async state-machine cost | ~300 |
| Total | ~5,250, rounded to 10,000 for margin |
At 3 GHz, 10,000 cycles is 3.33 microseconds. At ~10W for one active server core: 3.33 × 10⁻⁵ Joules.
Now the other side, FLOP by FLOP rather than quoting an opaque per-query Wh number:
# Hyperlambda dispatch: counted cycles, converted to energy
hl_cycles = 10_000
hl_time_s = hl_cycles / 3e9 # 3 GHz core
hl_energy_j = 10 * hl_time_s # ~10W for one active core
# LLM inference: FLOPs/token ≈ 2 × active-parameter-count (standard estimate)
tokens = 300 # tool schema + query + call + result + answer
active_params = 200e9 # frontier MoE, active params per token
llm_flops = tokens * 2 * active_params
llm_time_s = llm_flops / 3e14 # effective decode-bound GPU throughput
llm_energy_j = llm_time_s * 910 # 700W TDP × 1.3 datacenter overhead
# Sandbox: worst-case cold provisioning (not a warm pool)
sandbox_energy_j = 2.0 * 100 # ~2s at ~100W during cold provisioning
total_j = llm_energy_j + sandbox_energy_j
ratio = total_j / hl_energy_j
# hl_energy_j ≈ 3.33e-05
# total_j ≈ 564
# ratio ≈ 16,920,000
16,920,000 — round it to 17 million, and that's the whole headline.
See it running today
This isn't a thought experiment sitting in a slide deck. The whitelist that makes the cycle-count side of this comparison possible is a dashboard feature: Magic's Endpoint Generator has a Sandbox API tab that builds exactly this vocabulary, per role, with a UI instead of hand-written policy.
The admin role in that screenshot has exactly two capabilities pinned by exact path — /modules/purchase/checkout.post.hl and /modules/purchase/manage.post.hl — via execute-file. Not "may run code." May run these two files, and nothing else. Hover any candidate file and the tooltip reads its own file-level comment back to you, so granting a capability means reading what it does first, not guessing from a filename. I walked the whole tab, start to finish, in Let Strangers Run Code on Your Server. On Purpose. — this article leans on that mechanism rather than re-explaining it.
What this means once there are a million agents, not one
Everything above is a single call. Multiply it by a swarm, and the gap stops being an efficiency curiosity and becomes a difference in what's even attemptable — coordination that finishes in seconds instead of months, at a fraction of a household's daily electricity instead of multiple households' worth. I worked through that scaling, and the important limits on what it does and doesn't buy you, in Seven Orders of Magnitude: What a Whitelisted Swarm Costs Compared to an LLM Swarm — published the day before this one, arriving at the same order of magnitude from a slightly different angle. Read that one for the swarm-scale argument and its honest limits; this one is the vendor-by-vendor, cycle-by-cycle receipt.
The honest edges
A number like this invites exactly one kind of pushback worth taking seriously: you picked the slowest sandbox.
I didn't pick one at all — the 2-second, ~100W provisioning figure is a generic cold-start cost, not any specific provider's number. But let's steelman the other side anyway. Daytona's own marketing leads with sub-90-millisecond cold starts — the fastest number any of the seven publishes. Swap that in for the worst-case 2 seconds:
sandbox_energy_j = 0.09 * 50 # Daytona's own advertised cold start
# ratio drops to roughly 11,000,000
Even granting the fastest sandbox in the industry, by its own marketing, the ratio only drops from 17 million to about 11 million. The conclusion doesn't depend on which competitor I picked.
What it does depend on, and what I want stated plainly: the 200B active-parameter figure, the 300-token exchange, and the 3×10¹⁴ FLOPS effective throughput are my own estimates, not measured benchmarks — reasonable, documented, and rerunnable, but estimates. The honest range on a calculation like this is easily half an order of magnitude either way. What doesn't move, under any assumption I can construct in good faith, is the conclusion that this is a multi-million-to-one gap, not a marginal one.
Run it yourself
The Python above is the entire model. Change the token count, the active-parameter estimate, or the sandbox cold-start time to whatever you believe is correct, and see where the ratio lands. If your numbers put it at 5 million instead of 17, that's still the headline — just a more conservative one.
Magic is MIT-licensed and open source. The repository is at github.com/polterguy/magic, documentation at docs.ainiro.io.
Frequently asked questions
How much more energy does a sandboxed AI agent use than Hyperlambda, for the same task?
Modeling a frontier LLM interpreting a request plus a worst-case sandbox cold start, against one whitelisted Hyperlambda dispatch resolved via cycle counting, the gap is roughly 17,000,000 to 1 in energy per call. Using the fastest publicly advertised sandbox cold start (Daytona's sub-90ms figure) instead of the worst case still lands around 11,000,000 to 1.
Which AI agent sandbox providers does this compare against?
OpenAI's Code Interpreter, which popularized agent-written-code-in-a-sandbox, plus the seven providers OpenAI's Agents SDK natively supports as of April 2026: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel.
Why doesn't Hyperlambda need a sandbox to run AI-generated code safely?
Because every function a piece of Hyperlambda references is checked against an explicit, per-role vocabulary before it can dispatch at all - a name outside that vocabulary was never reachable, rather than being caught and blocked after the fact. A sandbox contains code that might do anything; a whitelist makes "might do anything" untrue in the first place.
Is the 17,000,000x figure a measured benchmark?
No - it's a bottom-up estimate built from counted CPU cycles on one side and published FLOP-based reasoning on the other, not a timed, instrumented benchmark run. The full calculation, including every assumption, is in the article so it can be rerun with different numbers.
Related reading
- Seven Orders of Magnitude: What a Whitelisted Swarm Costs Compared to an LLM Swarm
- Let Strangers Run Code on Your Server. On Purpose.
- The Only Sandbox Your AI Agent Cannot Break Out Of
- Zero-Hallucination Code Generation: A Vocabulary Your AI Cannot Escape