Local and frontier models

A frontier model is the strongest tool in the stack and the most expensive to run on volume. Most coding and research work, though, is not hard — it is renaming things, writing obvious tests, reformatting, summarizing a file. Paying frontier prices for that is wasteful, and sending it to a cloud is sometimes more exposure than you want. So the stack runs two lanes and you choose which one a task goes to.

The local lane

A local model runs on your own hardware — for example, Ollama serving a code-tuned open model on a machine with a GPU. You drive it with a coding agent that can point at a local endpoint, such as opencode . The result costs nothing per request and keeps the work on your machine, which makes it the right lane for the routine 80%: small edits, running tests, mechanical refactors, first drafts.

A rough setup, generically:

# on the GPU machine — serve a code model locally
ollama serve
ollama pull <a-code-model>      # e.g. a 14B–32B coding model that fits your GPU

# in your coding agent's config — point it at that local endpoint
#   base URL: http://<gpu-machine>:11434   (Ollama's default port)

One GPU machine can serve the whole set over your private network , so the laptops and smaller boxes use the local lane without each needing a GPU.

The frontier lane

The frontier lane is a frontier model through Claude Code (or a comparable agent). It takes the hard 20% — the design decision, the subtle bug, the unfamiliar codebase, the review that has to be right. You run it the way the rest of this handbook describes, under amux .

Which lane for which work

The two are not interchangeable, so do not treat the local model as a cheaper frontier model. It is smaller, and it will miss things the frontier model catches. The useful division of labor is by difficulty, not by mood:

• Local lane — high volume, low stakes: boilerplate, test scaffolding, format-and-lint passes, bulk edits, a first pass you intend to check anyway.
• Frontier lane — low volume, high stakes: architecture, a bug you cannot reproduce, anything you are going to ship without a second look.

A pattern that works well is to let the local lane draft and the frontier lane review — the local model produces the change, and the frontier model checks it before you do. You stay the final reviewer either way.

Where to go next

• The access rules behind the lanes: subscriptions, APIs, and local models .
• Run the frontier lane: Run agents on one machine .
• Serve the local lane across machines: Connect machines with hcom .