macrokit.dev · paper, explained

Stop paying for the same reasoning twice

The MacroKit Pattern in one sitting: why your agent re-derives an identical plan on every request, what it costs you, and the compiler-shaped fix that let a 7B local model hold 94.5% routing accuracy at roughly 1/5000 of the price.

The bill you are actually paying

Most production agents work like this: a request arrives, a frontier model reads the prompt stack, reasons its way to a plan, executes, and forgets everything. The next, nearly identical request pays for all of that reasoning again. If a workflow runs a thousand times a day, you are buying the same chain of thought a thousand times — at frontier prices, roughly $0.50 a run for the workloads we measured.

The one idea: reasoning about how to do a task and doing the task are different workloads. Price them differently.

An analogy you already trust: the compiler

Nobody re-compiles a program every time they run it. You compile once — slow, expensive, done by heavy machinery — and then the binary runs cheaply, forever, on modest hardware. MacroKit applies exactly that split to agents:

Without the pattern request #1…N frontier model re-reasons every time result ~$0.50/run With the pattern frontier model reasons ONCE (design time) macro library explicit, versioned request #1…N 7B local model routes + replays macro result ~$0.0001/run
Fig. 1 — The same split compilers made sixty years ago: pay for reasoning once at design time; pay only for execution at runtime.

What the numbers said

On a 100-task intent-routing benchmark, a 7B local model replaying distilled macros reached 94.5% routing accuracy with zero structural failures — at about $0.0001 per run versus ~$0.50 with a frontier model in the loop: a ~5000× cost gap on the workloads measured.

Same model, one configuration choice apart before 53.5% after 94.5% The delta was one SDK setting — how argument names were rendered to the model. Capability was never the bottleneck; configuration was.
Fig. 2 — The most useful failure in the paper: a 41-point accuracy swing traced to a single configuration choice, not to model capability.

Where it works — and where it honestly doesn't

The pattern earns its keep on narrow, recurring workflows: the same shape of task arriving over and over, where a frontier model's reasoning can be captured once and replayed with different parameters. That is precisely why the SDK ships a distillation gate — a static analyzer that flags which workflows are worth encoding as macros and, just as importantly, which are not.

Not a free lunch: open-ended, novel, one-off tasks still belong to the frontier model. The pattern does not make a small model smart; it makes previously-captured intelligence cheap to re-run. If your workload never repeats, there is nothing to compile.

Try it / verify it

Everything above is checkable — the benchmark, the SDK, and the macro format are public.

Paper: Qian, C. The MacroKit Pattern: Intent Routing and Macro Distillation for Weak LLMs on Narrow Workflows (2026). DOI: 10.5281/zenodo.20446805
Code: github.com/macrokit (Apache-2.0 SDK: runtime router, adapters, replay test harness)
More from this line of work: macrokit.dev · A Mathematical Theory of Value

All diagrams and analogies on this page are original to this explainer. Figures summarize results reported in the paper above; consult it for methodology and full benchmarks.