We fixed the context. Now look at our bill.
We have optimized teams of agents working. Quality is good, but it’s getting expensive fast. Faced with that cost, we try to drop to cheaper frontier models at the expense of quality. But that’s the wrong approach.
The question isn’t which frontier model to use. It’s: which steps actually need one?
Most of them don’t.
The Specification Problem
There is one thing frontier models are genuinely exceptional at: turning ambiguous intent into a precise, unambiguous specification.
“Clean up the auth module.” “Improve the performance of this query.” “Write a blog post about AI.” These are underspecified requests. We need some brainstorming, follow-up questions and judgment to get there. Frontier models excel at this.
Once the specification is clear, execution doesn’t need a high level of intelligence. It just needs a model that knows how to follow instructions.
The expensive part of a workflow is knowing what to do. Doing it is mostly mechanical.
This realization changes the architecture.
The 20/80 Split
The numbers echo the Pareto principle[1]: a small fraction of inputs drives the majority of outcomes. Specification is that fraction.
- 20% frontier: an orchestrator that reasons about the task, breaks it down, writes a precise spec for each step, and reviews the output.
- 80% local: workers that execute against the spec: searching, writing, calling APIs, transforming data using smaller, faster, cheaper models.
The orchestrator runs once to reason and specify. Workers run constantly to execute. Cost follows the split.
flowchart TB
U["User request"] --> O
subgraph F["☁️ Frontier (20%)"]
O["Orchestrator"]
end
O -->|"precise spec"| W1
O -->|"precise spec"| W2
O -->|"precise spec"| W3
subgraph L["🏠 Local (80%)"]
W1["Worker"]
W2["Worker"]
W3["Worker"]
end
W1 & W2 & W3 -->|"results"| O
O --> R["Response"]
The orchestrator is expensive, but runs less frequently. It runs at the start of a task, at the end, and occasionally mid-task to course-correct.
The workers run constantly and they’re cheap.
A well-written spec changes what local models can do. The same model that produces mediocre
results on "refactor the auth module" will reliably handle:
Extract the session handling from `user_controller.ex` into a new `Session` module,
preserving the existing public interface.
The model didn’t get smarter. The input did.
Running Local in Practice
I run local models on a Framework Desktop at home. Though it started as a hobby, these models became part of my workflows.
I still use frontier models for specifications. They’re awesome at that job. But my local models can follow these specifications almost flawlessly, for next to nothing.
This is why Planck supports both frontier and local models natively. I’ve seen the 20/80 split match frontier-only quality in my own AI teams. I’ve gotten good quality at a fraction of the cost.
Owning the Loop
Cost isn’t the only reason to run local though.
Some of the models I run locally are also decent at specifications for certain tasks. They’re slow, but they get the job done with the right context. That lets some workflows run entirely local.
When we call a frontier model API, our data leaves our machine. Code, context, conversation history… all sent to a third party. Their pricing decisions affect our workflow. Their model updates can change our agent’s behavior overnight. Their rate limits cap our throughput.
When we run local, data stays on our hardware. The pricing is predictable as electricity is the main cost. Models don’t change unless we update them. Throughput is bounded by our machine, not a provider queue.
Depending on the hardware, it could even be environmentally friendly.[2][3][4]
Conclusion
The previous post gave us the team model. This post adds the cost dimension: not every step needs a frontier model, and knowing which steps do is most of the architectural work.
Planck supports this natively. Each agent in a team configures its own model provider independently. The orchestrator can call a frontier API while workers call a local endpoint. The team doesn’t need to change.
In the next post, we introduce Planck properly: what it is, how it works, and how context, specialization, and model routing come together in a single system.
Frontier for thinking. Local for doing.