There's a quiet assumption baked into most AI tooling: the smartest model should do everything. If a large cloud model is best at reasoning, route every task through it. It's a tidy story, and it's the wrong one — for cost, for privacy, and for the simple architectural reason that planning and doing are different jobs with different requirements.

We split them on purpose.

Two roles, not one model

In our system the capable cloud model has a specific job title: facilitator. Our design note draws the line cleanly. "[The cloud model] is the facilitator: it plans, calls workflow.next, delegates. Local agents are the workforce: they do the actual work inside a worktree."

That sentence is the entire architecture in miniature. The facilitator is the one that holds the shape of the task, decides the order of operations, and parcels work out. The workforce is a set of small models running on the local machine that take a bounded piece of work and execute it. The facilitator thinks; the workers do.

This isn't a vague aspiration that the code hopes you'll honor. It's encoded as one of the project's standing rules — "use local agents for sub-agent work." Our note names it directly: it "is Rule 4 of the five rules." When the facilitator needs a sub-task done, the default dispatch goes to a local model. Reaching for the cloud for the sub-work is the exception, not the reflex.

Local-first, and why the order matters

The dispatch path makes the preference concrete. Our note describes it as "local-first": the work-execution call "dispatches to [local runners] by default," and "only when local cannot meet the task is a cloud-backed or facilitator path taken." The word only is doing real work there. The cloud isn't the first option that local merely supplements. Local is the first option, and cloud is what you fall back to when local genuinely can't do the job.

Why arrange it that way? Three reasons, and they reinforce each other.

The first is foundational. One of the project's deepest commitments is wholeness — the system must be complete on its own, with no external dependency for its core function. A design where every sub-task phones a cloud vendor would violate that at the root: pull the network and the workforce vanishes. By making local models the default workforce, the system keeps working when it's offline. Our note ties the two together explicitly: the local-first rule composes with that wholeness commitment.

The second is cost and heat. Cloud inference costs money per call and the workload here is bursty — our note pegs the inference pool's sizing at roughly five to ten queries an hour, with thermal limits as the binding constraint on mobile. You do not want to pay a cloud vendor for every small step of a multi-step task when a local model on hardware you already own can take most of them for nothing.

The third is control. Work done by a local model is work whose inputs never left your machine. For a system whose whole reason to exist is to hold your memory privately, routing every sub-task's content through someone else's servers would quietly undo the point.

Where the boundary actually sits

The honest version of this story has a soft edge, and our note doesn't hide it. The facilitator/workforce split is clean today because the local models aren't yet as strong as the cloud model at planning. The rule "prefer local" currently resolves the question by fiat. But the open question is written down: "Where does the facilitator/sub-agent boundary sit when a local model eventually matches [the cloud model] for planning?" The note admits "the fallback policy needs sharper criteria."

We think that's the right way to hold it. The architecture isn't claiming local models are better at planning. It's claiming the roles are real and worth separating — and that as local capability rises, the boundary moves, but the shape stays. You'll always want one thing holding the plan and other things executing pieces of it. Which model plays which role is a tuning decision; that there are two roles is the design.

The discipline underneath

What makes this more than a slogan is that the local workers aren't second-class citizens running unsupervised. Each one runs in its own isolated workspace and its own process, with a bounded budget on how deep and how long it's allowed to delegate. Its output passes a quality check before it's accepted — scored as approve, retry, or skip — so "let the cheap local model do it" never degrades into "ship whatever the cheap model produced." The facilitator delegates real work and still answers for the result.

So the picture is: a capable model up top, planning and parceling; a fleet of small local models below, doing the labor offline and for free; a rule that says try local first and mean it; and a quality gate that keeps the cheap path honest. Plan with the big model. Work with the local one. Fall back deliberately, not by default.

Related: The Protocol That Lets an AI Drive Your Daemon · One Door for Every Model You Run.

Written by AI agents from real project logs; owned and edited by Mujo.