Build a browser arcade across thirty sequential hidden prompts. The plan is deliberately broken in the middle: a single-game puzzle becomes a two-game arcade, levels must become data, scoring becomes shared and persistent, and a second game with an entirely different loop arrives unannounced. No system is shown a prompt before its turn.
This is the long-horizon test. Every earlier benchmark asks whether a system can build. This one asks whether it is still building well in hour nine — after the requirements have changed under it, after a night of downtime, after every interruption a working day contains.
Mean of the metered MagLev runs against the mean of their same-model counterparts, at completion.
Its counterpart on the identical model shipped an application that opened and then did nothing — and was granted a repair round MagLev never received.
491,260 tokens on every call against MagLev’s 63,983 — the same thirty prompts, the same model.
More than three times the work of its counterpart, and still a fraction of the total compute.
Every figure on this page is computed per request from each system’s own metered logs, using identical formulas on both sides. Read the spotlight on this benchmark →
A thirty-prompt build is graded on many things, but one result comes first. Each deliverable was opened the way any person opens it — a double-click — and then used.
MagLev — working
Opened into a complete two-game arcade and played. Its final report described its own limitations accurately, including one near-miss it caught and fixed during its own final verification. Its self-check harness was independently re-executed and passed in full.
Its counterpart — not working
On the identical model, the application rendered but no button, control, or interaction functioned. It certified its own deliverable ready three separate times and was wrong all three. It was then granted one additional repair round — which MagLev was never given and never needed — and shipped unplayable anyway.
The repair round is the part worth sitting with. It ran roughly thirty minutes and consumed several times MagLev’s entire thirty-prompt benchmark, and the product still could not be played. The engine logic was never the problem: its test harness was independently re-run and passed. What failed was noticing, after thirty prompts of accumulated context, that the human on the other side of the launch could not use the thing.
MagLev never loses the thread. Persistent memory means the thirtieth prompt is answered with the same discipline as the first. The project is remembered rather than re-read, so the oldest requirement in the brief is still present at the end of the day — including the quietest and most important one, that a person has to be able to use it.
The same thirty prompts, the same models, the same finished software. This is how large the prompt had grown on each individual model call, from the first call of the day to the last. Every compute and energy figure on this page is a consequence of this one behavior.
| Arm | Mean tokens / call | Median | Peak | Final call |
|---|---|---|---|---|
| Claude Code (Opus 4.8) | 491,260 | 502,741 | 974,327 | 974,327 |
| MagLev (Opus 4.8) | 63,983 | 64,272 | 99,714 | 69,040 |
The native harness runs the day at 491,260 tokens per call and peaks at 974,327 — near the top of the model’s window. MagLev holds 63,983 on average and never exceeds 99,714, start to finish, on the identical model solving the identical problem. It is not truncating the work and it is not answering with less: it is the run that shipped something playable.
A day of work does not have to cost a day of re-reading. The prompt does not swell, so hour nine is priced like hour one. Both systems were shut down overnight and restarted cold the next morning; only one of them had to pay to remember what it had been doing.
Prompt tokens per call as reported by each provider’s own meter, interpolated onto the shared progress grid. Cached and uncached input are both included: this is the size of the package the model was handed, before any billing discount is applied.
The mean of the metered non-MagLev runs against the mean of the metered MagLev runs. Equal weight for every run; both curves start at zero and accumulate across the session.
At completion: 4,038 billion attention pairs against 334 billion — a 91.7% reduction. Each run is independently normalized to 0–100% progress, with linear interpolation onto a 5% grid. Progress indicates position within the recorded session—not verified feature completion. No curve smoothing is applied.
Every curve begins at zero. The native harness climbs steeply as the day lengthens; the MagLev curve stays close to the floor.
One working day, thirty prompts, both systems shut down cold overnight and resumed the next morning.
Attention state streamed out of memory during decode, and the separate uncached counterfactual. Both are token-derived proxies, not measured hardware FLOPs.
82.2% less decode KV traffic (5.6×).
95.4% less under the uncached ceiling.
The main curves show causal attention pairs. Expand each comparison to view decode KV traffic (S3S) and the uncached scenario (S4); the latter is counterfactual, not actual hardware work.
Cumulative modeled memory-traffic energy at the same normalized progress. Dashed lines are KV-cache energy; solid lines are total modeled energy.
At completion: 82.0% less KV cache energy and 37.6% less total modeled energy.
Total modeled energy includes KV-cache and decode weight traffic, under identical fixed assumptions on both sides. These are estimates derived from measured token surfaces—not measured device or datacenter electricity.
Every figure above is a session total, and a total punishes the system that produced more software. These surfaces divide the same metered work by the output tokens that work produced. Same logs, same formulas, corrected units — and the gap widens.
Mean across these pairings. Work divided by the output it produced, so a longer answer is never charged as a loss.
What the end of the session costs — not the average of an easy first hour and an expensive last one.
How much the prompt grows from the first decile of calls to the last. Dimensionless, so it compares across every vendor.
198 output tokens per second against 23, at each arm's own mean context.
| Pairing | Per delivered token | Terminal rate | Escalation | Sessions / card | Decode rate |
|---|---|---|---|---|---|
| MagLev (GPT-5.6-SOL) vs Claude Code (Opus 5) · V1 | 62.1× | 63.5× | 2.02× | 9.33× | 9.33× |
| MagLev (Opus 4.8) vs Claude Code (Opus 4.8) · V1 | 29.1× | 61.4× | 8.46× | 7.68× | 7.68× |
A model call is bounded by how much KV state has to be streamed from memory for every token it writes. Context size therefore converts directly into how many of these sessions fit on one card — here, at each arm's own mean context. The strongest terminal result on this page is MagLev (GPT-5.6-SOL) vs Claude Code (Opus 5) · V1 at 63.5×.
Ratios are MagLev advantage: how many times more compute the native harness spent to deliver the same unit of output. Sessions per card and decode rate assume one 80 GB H100 SXM at 3.35 TB/s with decode bound by KV traffic; the constants are fixed and identical on both sides. Terminal rate uses the final decile of model calls, with a minimum window so a short arm reports no rate rather than a single-sample one.
Thirty prompts, one day, the plan deliberately broken in the middle. One system finished with a two-game arcade that opens and plays. The other, on the identical model, spent several times the attention compute, was given an extra repair round, and finished with an application nobody can use.
All of it comes from one property: persistent memory. MagLev remembers the project instead of re-reading it, so the thread is never lost and the prompt never swells. The thirtieth prompt is answered with the discipline of the first — including the oldest requirement in the brief, the one that says a person has to be able to use it.
Spotlight: the quadratic tax → ← Back to all benchmarks