Eleven prompts in.
A working enterprise application out.

The deliverable is the evidence.

Eleven prompts went in. What came out is a sell-side M&A deal room with full data tables, a Supabase cloud backend, and a live AI API integration for drafting and communication. Other than the eleven prompts, there was no human interaction — no correction, no steering, no repair round.

Spotlight: the software it built → Launch DealCommander

Counts are measured directly from the delivered source tree: product files only, excluding test harnesses and tooling (6 files, 2,029 lines). Code volume is not a quality score; it is reported here because the structural comparison below is about how that volume is organised.

Four graded pairings. Four MagLev wins.

Each deliverable was graded against the same rubric built from the brief. In every pairing, the MagLev arm and its comparison system ran the same model.

The structural comparison is where the difference becomes concrete. Both sides of the Opus 5 pairing produced a working application of similar scale. Only one of them produced a codebase a team could take over on Monday.

Product-source counts exclude test harnesses and tooling on both sides. The apparent extras in the comparison codebase were audited against the brief and found to be unrequested scope, including one database table with no call sites in its own source. Scores are compared within this study, not averaged across rubrics.

Three lines hold flat. Three climb until something has to give.

This is the size of the prompt on each individual model call, from the first call of the build to the last. It is the one chart that explains every other number on this page — and it is where the two approaches stop resembling each other.

In V2, the native harness on Opus 5 averages 350,498 tokens per call and ends at its own peak of 609,663 — still climbing when the work runs out. In V1 it climbed to 966,007 and then shed 927,756 tokens in a single step, down to 38,251. Codex did the same thing at 91.4% complete, falling from 202,216 to 31,826. MagLev on the identical model held 51,608 and 46,594 in the two runs, and never exceeded 129,723 in either.

MagLev never reaches that wall, because it was never walking toward it. Persistent memory means the project is remembered rather than re-read, so the eleventh prompt is answered with the same discipline — and the same cost — as the first. Nothing has to be summarised away, because nothing was being hoarded in the first place. MagLev stays on track like a maglev: the thread is never lost, and it never has to be reconstructed.

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. MagLev arms also show call-to-call variation — they operate from a low ceiling by design, not by truncation at a limit.

2.77× less attention compute at completion.

The mean of the metered non-MagLev arms against the mean of the metered MagLev arms. Equal weight for every arm; both curves start at zero and accumulate across the build.

At completion: 840 billion attention pairs across 2 comparison arms against 303 billion across 2 MagLev arms — a 63.9% reduction. One metered pairing — Codex against MagLev on GPT-5.6-SOL, V1 — is excluded from this average and disclosed rather than diluted into a mean: on that one small-scale pairing MagLev accumulated more attention pairs, having done several times the work volume and produced several times the output. Each arm 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.

Less modeled memory-traffic energy, in every pairing.

Cumulative modeled memory-traffic energy at the same normalized progress. Dashed lines are KV-cache energy; solid lines are 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. Where a total-energy surface is not shown, the MagLev arm was higher on it: in three of these four pairings MagLev generated substantially more output, and output tokens carry decode weight traffic regardless of how small the prompt is.

Divide by the work actually delivered.

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.

The capacity statement.

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 (Opus 5) vs Claude Code (Opus 5) · V1 at 146×.

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. This section publishes only pairings where MagLev finished ahead on every surface shown. Held back and named here instead: MagLev (GPT-5.6-SOL) vs Codex (GPT-5.6-SOL) · V2 (context escalation at 0.56×).