← All issues

The number on the label lies

Issue #17 · October 3, 2026 · ~5 min read

Welcome back to Zero to MVP Weekly. One signal, one tool, one MVP idea — five minutes, every Saturday. No link dumps. This issue has one theme: the number on the label lies. Three labs priced their new models identically this week, and the bills differ by about four times. And the GPU scheduler I've been building since June taught me the same thing about memory: almost every serious bug was a number that lied.

1. The signal of the week

Three new models, one price tag, and bills about four times apart.

In three days, three labs priced new models identically: $2 per million input tokens, $10 per million output.

  • Claude Sonnet 5.5 (Anthropic, September 28): the same price as Sonnet 5, "up to 30% less per task," 30%+ faster.
  • GPT-6.1 Sol (OpenAI, September 29): "nearly matches" GPT-6 Astra at a fifth of Astra's price; cached input $0.10.
  • Gemini 4 Argon (Google, September 30): Google's new frontier model, at an introductory $2/$10, though for now only vetted cyber defenders can use it.

Last week I wrote that price per token had stopped telling you the price. This week is the cleanest proof. Artificial Analysis ran Sonnet 5.5 and GPT-6.1 Sol at every effort level:

  • Sol at low effort: score 42 for $0.13 a task. Sonnet at medium, Claude Code's default: 41 for $0.59.
  • Sol at max: 52 for $0.72. Sonnet at xhigh: 52 for $2.75.

Same label, same score, about four times the bill. At max effort Sonnet 5.5 uses about 193,000 output tokens per task, the most Artificial Analysis has ever measured. That makes it more expensive than Opus 5.5 at max ($7.67 vs $5.98) while scoring lower.

What to do with it: stop choosing by model name or price list. Set effort explicitly, and compare cost per task on your own work. "Sonnet for the cheap stuff" is no longer a safe rule.

One honest caveat. Artificial Analysis's index leans on knowledge work. On Terminal-Bench 4.0, the index's agentic coding test, Sonnet 5.5 at max leads both (63.6% vs Sol's 56.1%). Artificial Analysis also tested a pre-release Sonnet build with a structured-outputs bug and plans to re-run. And on a Claude Code subscription you pay in rate limits, not dollars, though every token still counts against them.

2. My take

It seems to me the market has reached the point where the price per million tokens has almost stopped meaning anything as the main measure of what a model costs.

What matters now isn't $2/$10. It's how many reasoning and output tokens a model burns to solve a specific task. That's why two models with the same price list can differ in real cost several times over. In that sense Sol looks very aggressively optimized for cost/performance, and Sonnet looks more "expensive to think," especially at high effort.

So this is how I see the main shift: we're moving from asking "which model is cheaper?" to asking "which model solves this particular kind of task more cheaply, at the quality I need?" Routing follows naturally from that: a cheap, efficient model by default, and a more expensive one only where it really gives you an edge.

3. Tool of the week

GridCore, a scheduler I built so my local models can share one GPU. (Disclosure: it's mine. Read this as a build report, not a review.)

  • What it's for: one card, several things that want it at once: a chat, a coding agent, an indexer, a screenshot reader. GridCore sits between your apps and llama.cpp, speaks the OpenAI API, and decides who gets the GPU. interactive goes first; background and batch are cut into small steps that yield to chat. Apps change one address and, optionally, send X-GridCore-Class: background.
  • What the write-up is really about: the numbers lie. Estimating VRAM from file size was off by −8% to +94% (Gemma 4 E2B: 5,678 MB estimated, 2,924 actual); reading the GGUF header tensor by tensor gets it to −1% to +10%. And four bugs no simulated test caught:
    • background work starving under constant chat;
    • unloading 15 GB of models to free 200 MB;
    • "phantom" memory from two nvidia-smi calls that disagree;
    • 502 errors, because llama.cpp's server closes a connection after five requests while Go kept reusing it.
  • What it does now: four models on one RTX 4060 Ti 16 GB (15.5 GB used), and a five-minute mixed load test with no errors and no unnecessary loads. Since v0.3 it also runs on Apple Silicon.
  • Where it costs you: under mixed load, the median chat response time rose from 1.9 s to 3.4 s (2.7 s with v0.2's default background_share). One GPU, NVIDIA or Apple Silicon only; no AMD yet, no vLLM or MLX, no authentication. Open source under the MIT license.

The full write-up, with the Mac surprises: A GPU Scheduler for Local LLMs: What Broke on Real Hardware · code: w512/GridCore

4. MVP idea of the week

"Will it fit?" A VRAM calculator that reads the model, not the file size.

  • Problem: people pick a local model by file size or parameter count, then find out at load time whether it fits. Building GridCore, I watched that estimate miss by up to 94%. One flag, --cpu-moe, took a 35B model from a 21 GB estimate to 2.2 GB on the card.
  • Solution: a web page. Paste a GGUF model link and pick your device, context size and offload flags. It reads only the header and shows the footprint: weights on the GPU, tables kept in RAM, KV cache, buffers. It ends with the llama-server flags that make the model fit.
  • For whom: anyone choosing between local models and quantizations, or sizing a home GPU or a Mac for local AI.
  • Minimal v1: two model families (Gemma 4 and Qwen), NVIDIA only, one page, with a "measured vs. estimated" table so the error is visible.
  • Demand check: post three cases where the naive estimate says "won't fit" and the model runs fine, and count how many people paste in their own models in the first week.
  • Why now: newer architectures broke the rule of thumb: per-layer embeddings, MoE experts on the CPU, unified memory on Macs. The method and real measurements are now public, in the write-up above.

5. Useful links

— Nick

P.S. GridCore v0.3.0 is out, and the repo is now public. Until this week it was a beta for my Patreon supporters. Now it's available for everyone. New in v0.3: Apple Silicon support and a built-in dashboard. github.com/w512/GridCore

Get the next one in your inbox.

One signal, one tool, one MVP idea — every Saturday. Free.