Memory decides which model can do the work.

Two Macs, two models, one harness, one replicate per cell, over two days. The memory figures are measured on the Studio and the 36 GB Max. The 128 GB M5 Max is emulated, not measured: the cap models the server process only, the Studio’s own apps sat outside it, and the Studio has about twice that laptop’s GPU cores, so its wall clock flatters a real one. The two-solve swaps between cells sit inside temperature-1.0 variance on identical weights.

Self-funded editorial. No part of this lab was sponsored, and no vendor commissioned it, funded it, previewed it or saw it before publication. Both Macs were bought by the author at retail. Disclosure: Google Cloud is a client of The CTO Advisor LLC, and Google’s Gemma 4 is one of the two models here. Apple, Alibaba and NVIDIA are not clients. Anthropic’s Claude Code is the harness in every arm, and an Anthropic model drafted this record.

Which Mac should an architect buy to run a coding agent locally? The usual answer is a chart of tokens per second, and I don't trust it, because a chart can't tell you whether the agent finished the job. So I ran the same 22 verified repair tasks, under the same agent harness, on two Macs with identical file systems and applications. One is my 36 GB M5 Max laptop. The other is a 256 GB M5 Ultra Mac Studio. Each task counts only when its own held-out tests pass in a sealed container. I used one model that fits both machines and one model that actually does the work, and then I asked whether a 128 GB M5 Max, the biggest laptop Apple sells, could carry the second one.

The first result on the laptop showed up before I ran a single test. Gemma 4 26B at 4 bits is a 14 GB model, small enough that I expected no drama. oMLX, the open-source server that runs models on Apple's MLX framework, carries a memory guard that refuses work it predicts won't fit. At the safe tier, which holds back 20 percent of RAM, it refused to load the model with a normal day's apps open. I closed them and it refused again. What was left was my own stack: the Claude desktop app, Claude Code and Spotlight indexing, about 6 GB nobody is going to quit. On a laptop, the binding resource wasn't the model. It was everything else I run.

What happens when the agent starts?

I dropped the laptop one guard tier and ran the pool anyway. It scored 1 of 22. The memory guard ended 20 of the 22 sessions. Five never took a turn, because their opening request of 28,000 to 61,000 tokens arrived while the other session held the memory. The same weights scored 14 of 22 on a DGX Spark in Lab 013 and 15 of 22 in Lab 018, and the laptop missed 13 of the 14 tasks Gemma solved in Lab 013. That's memory, not capability.

Here's the part that worries me for anyone measuring this at home. The harness recorded every one of those guard-ended misses as a model that made no edit. A memory abort on a small machine looks exactly like a model that can't code, unless someone reads the session logs.

The Studio served the same weights at the same safe tier with my apps left open. Eight concurrent sessions at 250,000 tokens of context peaked at 94.8 GB. There was no memory wall. Its limit was time instead: oMLX prefills one request after another, so the eighth session waited 1,066 seconds for its first token. More sessions than a couple of agents buy you a queue, not more work.

Isn't this just a speed contest?

That's the obvious objection, and the speed was real. The Studio decoded Gemma at 165.6 tokens per second per stream against the laptop's 111.6, and prefilled 128,000 tokens in 38 seconds against 89. However, it didn't turn into solves. I stopped Gemma's Studio run at 7 of 22 as redundant, with no memory events and nothing solved, including one task Gemma had solved on a Spark in Lab 013, after a full 50-turn attempt. What I saw instead was Gemma being Gemma, on both machines: tool-call loops, one of which repeated a single command 266 times on the laptop, and runaway generations that ran to the 32,000-token output cap.

Speed doesn't change what a model can reason through. A faster machine samples from the same weights the same way. The only way speed raises a score is by finishing work the clock would otherwise have cut off. So here's the rule I'm working from. A model's score carries across platforms once the platform clears a floor: enough RAM to hold the model and its sessions, enough memory speed to finish turns inside the harness ceiling, and a serving stack that serves the model correctly. That last one isn't a footnote. In Lab 018, a tool-call parser bug made this same Gemma look like a model that couldn't use its tools. With the correct parser it scored 15 of 22.

So which model does the work?

Qwen3.8-Flash-Next is a sparse mixture of experts, 10 of 512 experts active per token, and it's 104.95 GB loaded at 4 bits. On the Studio it scored 20 of 22 in 1 hour 25 minutes, with no timeouts and no memory events. Of the 8 tasks Gemma 4 26B missed in Lab 013, it solved 7, in 8 to 25 minutes each. It doesn't load on the 36 GB laptop at any published size.

That made the 128 GB laptop the real question. I don't own one, so the Studio stood in for it, with the server process capped at what that machine allows. At 112 GB, the stock limit, Flash-Next loaded and then refused a 55,000-token prompt before the first task started. At 120 GB, with the wired limit raised by the owner, it scored 20 of 22 at one session in 1 hour 43 minutes. The process peaked at 115.5 GB, and the largest prompt was 142,682 tokens. That configuration leaves about 8 GB for macOS and every app, which is less than my ordinary apps used on the smaller laptop. That's a dedicated inference machine, not a laptop you also work on.

I want to be straight about what that emulation is. It capped memory, not compute. The Studio's own apps sat outside the cap, and the Studio has about twice that laptop's GPU cores, so the wall clock flatters a real one. Read it as the memory answer only, from one run per cell.

The close call is the 96 GB M5 Ultra against the 128 GB M5 Max, at about the same price. They split on the model, not on speed. The 96 GB Ultra can't load Flash-Next at 4 bits at all. Its extra GPU cores only pay if a model under about 60 GB does the work and the Ultra clears the memory-speed floor for it. Dense models are where that floor bites, because every token reads every weight. Gemma 4 31B dense scored 11 of 22 on an L40S in Lab 013, and ran at 10 tokens per second on two clustered Sparks in Lab 017. Where Apple silicon lands for a dense model, I didn't measure.

What does the cache cost?

One more thing changes how to read all of this. The workload is decode-heavy, but only because of the prefix cache. An agentic session re-sends its whole context every turn, and 98 to 99 percent of those tokens came back from cache. That's why cold-prefill benchmarks miss this workload, and it's also where memory comes back in, because the cache lives in memory. Every request the laptop refused was a cold prefill.

The cache also lives on disk, and nobody warns you. oMLX sized it to about half the free disk. On the Studio it peaked at about 1.2 TB and wrote at least 2.0 TB over the lab, against 367 GB on the laptop. Peak is a capacity question. The total is an SSD-wear question. Neither one scales with RAM.

The result I'll remember isn't a number, though. While the Studio served a 105 GB model to an agent, I used it as my desktop. I didn't instrument that, so it's an observation, not a measurement. On the laptop, the same lab meant closing everything, and it still wasn't enough.

So don't start with the chip, and don't start with the speed chart. Start with the model that does your work, then buy the memory it needs plus room for the person at the keyboard. Which model is that for you?

The numbers

Which Mac runs which model?

Where each layer belongs

Method and disclosure

Self-funded editorial. The instrument is loopcontrolbench, open under MIT: the 22-task certified pool, the sealed test gate, and the Claude Code harness driver, run at two concurrent sessions with a 7,200-second ceiling except where a cell says otherwise. The harness ran on DGX Sparks, never on the Macs, because the Macs sit on a personal network and the harness executes model-written code.

Both Macs served through oMLX v0.7.1rc1 at commit 7a5a3d75 on MLX 0.32.4, installed from one package freeze. Custom kernels were built on the Studio and absent on the Max, and none of them target either model here. Each instance ran with its own state directory and a single model, so the bench’s envelope gate read the served context unambiguously. Sampling came from each checkpoint’s generation_config. Requests reached oMLX through its Responses API on both Macs.

Declared confounds, one line each. macOS 26.6.2 on the Max against 27.0.1 on the Studio. The Max ran at the balanced guard tier and the Studio at safe, matched by proportion of RAM reserved. Gemma’s prior records ran NVFP4 under vLLM on a Spark in Lab 013, plus Lab 018’s corrected-parser run, against MLX 4-bit here. The Studio’s Gemma and Flash-Next cells ran their harness on a second Spark of the same class after the first stopped answering. The two copies of the harness differ only in two bookkeeping fields.

The 128 GB cells capped the oMLX process with its custom memory guard: 112 GB is 128 minus oMLX’s 16 GB safe reserve, and 120 GB models the owner raising the wired limit. Apple’s default GPU working-set cap on a 128 GB machine wasn’t measured. On these two Macs it read 78 and 87 percent of RAM.

The same Studio served DeepSeek V4 Flash through this harness at 22 of 22 (`sf_dsv4_studio_r1`), which is Lab 020’s measurement, not this one’s. Lab 020 compares the Studio against two DGX Sparks. This lab compares it against a laptop.

The raw detail ships at the download link: every arm’s configuration, the envelope probes, the per-task tallies, the guard events, and the cache accounting.

The essay on this page was drafted by Claude Opus 5.5, an Anthropic model, from this record under the author’s voice specification, passed the deterministic post gate, was checked by a second model from a different vendor, and was approved by the author before publication. Anthropic’s Claude Code is the harness in every arm here, so the drafting model’s vendor is also part of the apparatus.

The essay on this page was rendered from the lab’s frozen structured record by a model writing under this practice’s voice specification, with a deterministic gate checking every figure against the record before publication. The record is the canonical surface: where prose and record disagree, the record rules.