Volume Goes Local. Stakes Go to the Cloud.

The views expressed here are my own and do not represent those of any current or former employer.

The first time I routed a task to the wrong model, it was a rename. A boring, mechanical rename across eleven files, and I sent it to a frontier model on a metered path, because that was the model my editor happened to have open. It did the rename perfectly. It also spent a slice of a budget I would be cursing four hours later, when I actually needed a model to think and the bucket was dry.

The model was not the mistake. The model was fine. The mistake was the question I had used to pick it. I had asked “which model is best,” when the question that actually routes the work is “what can this task afford to get wrong.”

Once I started asking the second question, the crew reorganized itself. Not around a model. Around two tiers and a rule for which work lands on each.

The packet decides what a task can afford

Here is the thing I got wrong for a year. I kept believing the gap between a frontier model and a fast local one was raw intelligence, and that no amount of plumbing could close it. That is true for open-ended work. A frontier model carries a worldview: a vast implicit prior about how codebases are shaped, what a sensible fix looks like, where the bodies are buried. Ask it to “figure out why checkout is flaky” and it earns its price, because the wandering is exactly the part the worldview is for.

But most of a backlog is not open-ended. Most of it is bounded: rename this across these files, add this field with this validation, port this pattern from there to here. A bounded task does not need a worldview. It needs a specification. Hand a fast model a tight packet, the intent stated plainly, the acceptance criteria written as checks, the scope drawn as an explicit file list, the non-goals named so it does not gold-plate, and the model no longer has to explore. The packet is the worldview, narrowed to the size of one task.

That is the routing primitive, and it is not about models at all. A task’s packet quality decides which tier can do it. A tight packet makes a cheap model sufficient. A vague one forces you up to the frontier, or turns the cheap model loose to wander and burn the budget reconstructing context it was never handed.

Two tiers, pinned, no router

The tempting build is a smart router in the middle: something that reads each task, sizes it up, and picks a model. I did not build that, and not building it is the point. A router is a brain you have to keep teaching about every model that will ever exist, and it is exactly the layer the platforms keep absorbing.

Instead, the crew is nine specialists, and each one carries a single model field. The role decides the tier, once, statically. The agents that set the quality ceiling sit on the cloud frontier tier. The agents that do high-fan-out, cheap-to-verify builder work sit on the efficient tier. There is no branching and no scheduler. The routing is a property of the roster, written down where anyone can read it.

Tier	What it does	Who sits there	Default model
Quality (stakes)	Planning, architecture, the review gate, final acceptance	orchestrator, guido (design), critic, sentinel	flat-rate cloud frontier
Efficient (volume)	Wiring, bug fixes, plugins, research, docs, CI and config	welder, smith, scout, herald, keeper	cheaper cloud mini, or local

The split falls straight out of “what can the work afford to get wrong.” A bad architecture call or a review that waves through a broken change is expensive, so those roles get the frontier. A wiring fix or a changelog entry is cheap to check and cheap to redo, so those roles get the efficient tier. You are not picking the smartest model for each task. You are pinning each role to the cheapest tier that clears its bar.

The honest part: it ships cloud-first, and local is a toggle

Here is where I have to be precise, because the slogan oversells the default. “Volume goes local” is the architecture, not the state you get out of the box.

The shipped default runs both tiers on the cloud, on flat-rate plans: a frontier model for quality, a cheaper mini for volume. The efficient tier is built to drop onto your own GPU, but it does not start there. You opt in by pointing one variable, FAKOLI_LOCAL_MODEL, at a local SGLang endpoint (in my case Qwen3.6-35B-A3B on the 5090), and the volume tier moves onto your hardware. The local server itself is off by default, started on demand, and stopped to give the GPU back to gaming. Calling it “local” by default would be a lie the installer itself warns you about. The first time I flipped that toggle for real, it pulled the whole crew onto a different runtime, and only one layer survived the move.

That default is a cost-safety decision, not an accident. Every paid surface is opt-in; every default is free or flat-rate.

Surface	Default	Opt-in
Primary model path	flat-rate cloud frontier (no per-token billing)	per-token APIs, kept out of the defaults
Volume tier	cheaper cloud mini (flat-rate)	local SGLang on your GPU
Speech, search, secrets	free or local providers	paid providers, never plaintext secrets in config

So the routing fabric ships safe and gets more local as you turn knobs, rather than shipping expensive and hoping you notice. The rename that started this post should have hit the efficient tier and, once I flip the toggle, my own GPU. The frontier path should be reserved for the work that actually trades on a worldview.

What makes the local tier work at all

The local toggle is not free to earn. A 35B model served at a 32K window deadlocks on its first turn under the serving runtime’s default reserve, because the reserve floor eats most of a small window before the agent reads a file. The fix is two lines of configuration, and the arithmetic is its own post. Without it, the volume-local toggle does not function at all. The point worth keeping here: routing work to a cheap tier is only half the job. The other half is making the cheap tier survive a real agent loop.

And there is one early sign it is worth the trouble. On a small suite of six deterministic coding tasks, the local builder matched the cloud frontier on correctness, six for six, and came back faster on wall-clock.

	Local builder (SGLang, 35B on the 5090)	Cloud frontier
Pass rate	6 / 6	6 / 6
Wall-clock	92s	134s

One run on six small tasks. It proves the plumbing, not that local equals frontier on the hard problems, and a suite where both score perfectly has not yet found the local model’s ceiling. But it is the first real evidence that for bounded, well-packeted work, the efficient tier does not need to be the expensive one.

Route by what the work can afford to get wrong

The lesson outlived the rename. I stopped treating models as brains I assign work to and started treating tiers as lanes I pin roles into. The intelligence I was trying to buy turned out to be mostly a packet problem: bound the task well enough and the efficient tier is sufficient; leave it open-ended and you are paying the frontier for its worldview, correctly.

A model is a hammer. This year’s hammer is faster than last year’s, and the routing rule does not change with it, because the rule is a property of the work, not the tool. Volume goes to the cheapest tier that can verify itself. Stakes go to the frontier. The packet is what tells the two apart. Pin your roles by that, and you stop rebuilding the router every time the hammers change.