So far we have studied each lead on its own. Yet tomorrow's AI would use them together. Simple question, less simple answer: do the savings add up, or do they tread on each other's toes?
Promisingupdated
I
The idea, simply
Picture Leonardo's workshop. To deliver more paintings without wearing himself out, he can hand the work to apprentices first (the small model first), call only the specialist who is needed (the experts), use templates instead of painting everything by hand (the programs), grind less pigment (fewer bits), change tools (the machine), have the master look it over (the checking) and keep his models in a notebook rather than in his head (the separate memory).
Each trick attacks a different part of the cost. That is why we can hope they stack. But they also touch: a template is useless if nobody checks the result, and many apprentices take up room in the workshop. The figure goes round all 21 pairs.
Experts × fewer bits: gpt-oss stores its experts in 4 bits and fits on a single graphics card.
Fewer bits × machine: NorthPole runs a language model in 4 bits, with the weights kept on the chip.
Experts × machine: many experts means many weights to house, and chips with built-in memory have little of it.
Fewer bits × checking: long chains of reasoning pile up rounding errors.
Illustrative diagram: it shows the idea, not measurements.
Seven leads make 21 pairs. Each cell says whether two leads help each other (+), get in each other's way (−), do both (±) or ignore each other (·). This is the author's reading, based on the studies cited in the notebook: few studies have tested two leads together, and almost none has measured each one's share of the mix.II
The journey of a question
Let us follow one question through a system that uses all seven leads. 1. A router looks at it. If a program can already answer it (a calculation, a unit conversion), the program is called: almost free.
2. Otherwise a small model answers. It is made of experts of which only a few switch on, its weights are in 4 bits, and it runs on a chip that keeps those weights next to the calculation. 3. If it needs a fact, it looks it up in a memory instead of relying on its weights.
4. Its answer goes through a check: tests if it is code, otherwise a larger model that confirms several words at once. 5. Only if the check fails does the question climb to the large model. At every step, the full price is paid only when it is needed.
III
What adds up
Four combinations already work in real systems. What they share: the two leads act on different factors, so one does not eat the other's gain.
Established
Experts + fewer bits: gpt-oss and Kimi K2 Thinking
Experts reduce the share of the model that calculates; 4 bits reduce the size of each weight. The two stack: gpt-oss switches on only 5.1 billion of its 117 billion parameters and stores its experts in 4 bits, enough to fit on a single 80 GB GPU. Kimi K2 Thinking does the same at the scale of a trillion parameters, and generates about twice as fast.
A chip that keeps the weights in place has little memory; 4-bit weights take a quarter of the room of 16-bit ones. That is how IBM ran a 3-billion-parameter model on 16 NorthPole cards, at under a millisecond per word. Without the compression, the model would not have fitted on the chips.
A program is easy to check: you run it and measure. That is what lets a model propose thousands of them and keep only the best. AlphaEvolve drew from it a shorter matrix multiplication and 0.7% of Google's compute recovered; ShinkaEvolve sets a record in 150 attempts.
Small model first + checking: speculative decoding
The most polished cascade is also a check: a small model proposes several words, and the large one verifies them in a single pass. The final text is exactly the large model's, but it comes out 2 to 3 times faster, and up to 6.5 times with EAGLE-3.
Three frictions keep coming up in the studies. They appear when two leads pull on the same resource: memory, precision, or how far the judge can be trusted.
Promising
Many experts against little memory
A mixture of experts switches on only a few of them, but has to keep them all within reach. Fast chips with built-in memory have very little of it: Taalas engraves an 8-billion-parameter model, not a trillion-parameter one. Joint scaling laws soften the conflict without settling it: the right number of experts depends on the memory available.
Each word written builds on the previous ones, so a small rounding error can spread. Models that reason at length are more sensitive to it: Moonshot AI says it had to learn the 4 bits during training for Kimi K2 Thinking. And very well-trained models, the ones we would most like to compress, are the most fragile.
A cascade is only as good as its judge. A router can be fooled on purpose into sending everything to the expensive model, and under equal rules many routers barely beat the simplest strategy. The more tiers you stack, the more reliable judges you need, and every judge is one more door for an attack.
On paper it is tempting: if each lead halved the cost, seven leads would divide it by 2⁷ = 128. That is the spirit of our hypothesis H6, which we put at 35%.
But a simple rule, Amdahl's law, cools the enthusiasm: speeding up one part of the work only helps for that part. A purely illustrative example: if the large model is half of the total cost and you make it ten times cheaper, the total cost does not fall by 90% but by 45%. It goes from 100 to 50 + 5 = 55.
So the gains multiply when the leads target different parts of the cost (experts and bits), and overlap when they target the same one: a cascade that avoids the large model saves less if that large model has already become cheap thanks to experts. Our reading: combining brings far more than one lead alone, but clearly less than the product of the gains taken one by one. Nobody has measured it properly yet.
The matrix is a reading, not a measurement. It rests on studies that almost all test one lead at a time. Systems that combine several, such as gpt-oss or Kimi K2, do not publish what each lead contributes to the mix.
It also leaves out two very real costs: complexity (each lead added is one more part that can break) and batching. A server is efficient when it handles many similar questions at once; every routing decision, every variable depth breaks those batches up a little.
VII
How to put it to the test
One simple experiment would settle it: take an open model, then add the leads one at a time, in several orders, measuring each time the cost per correct answer on the same benchmark.
If the gains multiply, order does not matter and the last addition pays as much as the first. If they overlap, each addition pays less than the one before. That curve would say better than any table which lead to start with.