Frontier reasoning at phone scale

In the first two notes we showed that GoM reasons — that it holds at depth where larger models fall off, that it executes a procedure the same way every time, and that it declines rather than guesses when it is unsure. Capability is the interesting part of the story. It is not the part a buyer signs off on. The buyer signs off on the bill. So this note is about the bill: what GoM weighs, what it draws, what it costs per answer, and why those three numbers — taken together — change the deployment math for everyone who has been told that good reasoning has to live in a datacenter.

The short version: the whole thing fits in 2.54 GB, runs under two watts on a phone, and costs nothing per token because there is no token meter to begin with. The rest of this note is the detail behind those three numbers and why they hang together rather than trading off against each other.

2.54 GB versus 39 GB versus a rack

Start with footprint, because it sets the boundary on everything else. GoM is a graph of small specialized models plus a roughly 40 MB trainable “brain” that attaches to a frozen base model of your choice — the base never gets touched, the brain does the adapting. The smallest viable whole package — a small base plus that brain — comes to about 2.54 GB. That is the entire deliverable, not a quantized teaser of it.

For comparison, the best model you can realistically run on a single local machine today lands around 39 GB. The frontier systems most people mean when they say “AI” do not run on one machine at all; they run on clusters measured in the hundreds of gigabytes and up, behind an API, in someone else’s building. So the spread is not incremental. It is 2.54 GB against 39 GB against a rack — more than an order of magnitude at each step.

Footprint is the gate for edge deployment. Under a few gigabytes, the model fits on the device already in the user’s pocket or already bolted to the drone, the inspection robot, the field laptop. Above it, you are shipping silicon, power, and cooling to wherever the work happens, or you are shipping the work back to a datacenter and paying for the round trip. Crossing that line is what makes everything downstream — the power budget, the latency, the data-egress story — even possible to discuss.

The token tax nobody puts in the quote

Here is a cost that rarely shows up in a pilot’s budget and reliably shows up in the production invoice: the token tax. A sampling model that is unsure of an answer does not fail cleanly. It samples again. It retries, votes across attempts, expands a longer chain, burns more output tokens to claw its way to a confident-looking answer. Every one of those tokens is billed. On a hard problem the retry behavior is exactly where the spend balloons, and it balloons precisely on the inputs you most wanted the model for.

GoM does not have this failure mode, because it does not get its answers by sampling. It exact-executes: given the same input it produces the identical, repeatable answer, run after run, where a frontier model’s output varies from one run to the next. There is no temperature to anneal, no best-of-N to pay for, no silent multiplier between the price you were quoted and the price you were charged. When it is unsure, it declines — a confidence floor — rather than spending more tokens to manufacture confidence.

This is why “reproducible” and “cheap” are the same property here, not two separate selling points. The thing that makes GoM auditable — same input, same output — is the thing that caps its cost. You can read the reasoning note in this series for what that exactness buys you in correctness; this note is about what it buys you on the invoice.

Under two watts, and one checkpoint everywhere

Footprint lets the model fit on the device. Power decides whether it can actually run there all day. GoM does inference at under two watts on-device — a power budget a phone or a small embedded board can sustain without a fan, without draining a battery in an afternoon, without a thermal-throttle wall. It already ships on TestFlight for iOS and macOS, so this is a logged property of a real build, not a projection.

Two watts at the edge has a consequence the spec sheet does not spell out. When inference is local, the marginal cost of an answer is zero. There is no per-token meter running, no API call leaving the device, and so no data egress: the input never travels to a third party, which is its own line item in any regulated or sovereign deployment. Compare that to cloud inference, where every answer carries a per-token charge and every input is data you have handed to a building you don’t control.

And it is one checkpoint, not a per-platform port. The same GoM build runs across Apple, NVIDIA, and AMD — linear-time, non-attention core (details under NDA) — so the device you happen to have does not fork the model you have to maintain. One artifact, three silicon families, the edge and the datacenter alike.

Why this is the grid’s problem too

Zoom out from the single device and the footprint story becomes an infrastructure story. The U.S. national labs and the IEA have been tracking where the new demand comes from, and it increasingly points at this build-out: data centers drove about half of all U.S. electricity-demand growth in 2025, a share the IEA expects to hold through 2030, with Berkeley Lab putting data centers on track for a large share of total U.S. electricity by the end of the decade (LBNL / DOE, 2024; IEA Electricity 2026). The direction of travel is not in dispute: more capability has so far meant more compute, which has meant more power, drawn from a grid that does not expand on a model-release cadence.

The default answer to that pressure has been to build — more datacenters, more substations, more generation to feed them. That is one answer. It is a capital-and-concrete answer, and it ties the growth of AI capability to the growth of the power grid as if the two were the same line on a chart.

GoM is the software side of that decoupling. If serious reasoning fits in 2.54 GB and runs under two watts on hardware that already exists in the field, then a large class of inference does not need the datacenter at all. The work happens where the question is asked, on power that is already there, at zero marginal cost and zero data egress. You do not retire the cloud; you stop sending it the volume that never needed to leave the device. The capability curve keeps climbing — the power curve does not have to climb with it.

None of this asks you to trade capability for thrift. The earlier notes in this series make the capability case on its own terms — depth, reproducibility, in-session learning. What this note adds is that the capability arrives in a package light enough to live on the device, quiet enough to run on its power, and exact enough to carry no hidden retry bill. That combination is the argument for moving inference to the edge: not because the cloud is bad, but because most of the work no longer needs it.

See it run

Methodology and honesty: GoM figures (2.54 GB whole package, < 2 W on-device, $0 marginal cost, exact execution, one checkpoint across Apple/NVIDIA/AMD) are from logged builds, including the current TestFlight release for iOS and macOS — not live or projected runs. Footprint and power numbers for closed frontier systems are third-party estimates, since those vendors do not publish them. The grid figures are from the U.S. national labs and the IEA (Berkeley Lab / DOE, 2024 United States Data Center Energy Usage Report; IEA, Electricity 2026); the ~50% figure is data centers' share of U.S. electricity-demand growth in 2025 (projected to hold to 2030), not of total electricity. Core architecture details are under NDA.