Prewalk: swap to a cheap model after the first edit
Contents
When an AI writes code for you, where does the money go?
Not into writing the code. Into reading it. Roughly nine of every ten tokens a coding agent spends are spent reading files to understand what it is about to change. Writing the change is the cheap part.
That one fact breaks the most popular way people try to save money. And it points at a better way, called prewalk.
The idea everyone tries first, and why it fails
The obvious money-saver sounds like a good org chart: “Let the expensive senior model make a plan, then let a cheap junior model do the work.”
So the expensive model reads the whole codebase and writes a plan. You hand the plan to the cheap model. The cheap model starts working.
And immediately re-reads all the same files.
Here is why. A plan is a tiny summary, maybe 2,000 tokens, of a huge amount of reading, maybe 100,000 tokens. The cheap model cannot act on the summary alone. To make a safe change it needs the same understanding the planner built, so it opens the same files and reads them again.
You just paid the expensive model to read everything, then paid the cheap model to read everything a second time. The 90 percent got spent twice. The handoff made things worse, not better.
The fix: hand off the context, not the plan
Prewalk keeps both models in the same conversation and swaps at one precise moment: the first real edit.
It works like this:
- The expensive model explores the code, writes a clear to-do list, and makes the first working change - a real edit that proves the approach, not a placeholder.
- At that exact edit, you swap to the cheap model, in the same conversation, and delete the “go explore and plan” instruction.
- The cheap model now inherits everything: all the files the expensive model read, the to-do list, and one edit that already works. It finishes the list without re-reading anything.
The thing that gets handed over is not a plan. It is the whole context. The cheap model never rebuilds understanding because the understanding is already sitting in the conversation in front of it.
The stencil.so team who named this reported the payoff: an expensive explorer plus a cheap executor kept about 92 percent of the full expensive-model quality at about half the cost, and finished faster.
Why the first edit is the right moment to swap
Two reasons, one about quality and one about cost.
Quality. The first working edit is the signal that the hard thinking is done. The plan is set, the approach is proven. Everything after it is execution, which a cheaper model handles fine. Swap earlier and the cheap model inherits a half-formed plan. Swap later and you overpay for the expensive model to do grunt work.
Cost. An expensive model that stops during its confident early phase is calmer and cheaper than one grinding away in a stuck, desperate late phase. As a side effect, the cheap executor inherits a context that already knows where it is going, so it is far less likely to flail or go hunting online for a shortcut.
In plain words
Picture a senior engineer and a junior engineer sharing one desk.
- The old, broken way: the senior reads the whole codebase, writes a sticky note, and leaves. The junior arrives, reads the sticky note, and then has to read the whole codebase again to understand it. Two people read everything.
- Prewalk: the senior reads the codebase, writes the to-do list, makes the first fix while the junior watches over their shoulder, then gets up and lets the junior take the same seat. The junior already saw everything. They just keep going.
Same desk, same open files, same conversation. Only the person in the chair changed.
The one thing people get wrong
You do not carry the expensive model’s memory across to the cheap model.
Every model has an internal working memory of the conversation, built from its own weights. A different model cannot use another model’s working memory - the shapes do not match. So when you swap, the cheap model reads the whole conversation once from the top to rebuild its own working memory.
That sounds like the same re-reading problem. It is not, and the difference is the whole point:
- Reading the conversation text once is a single fast pass. The words are already written down.
- Re-generating the exploration means the cheap model would have to go open files and think it all through again, token by expensive token.
Prewalk pays for one fast re-read of text that already exists, not a full redo of the thinking. On a local server like vLLM, a feature called prefix caching then makes every step after that first pass cheap too.
Where you run it matters
Prewalk is not a special model or a special server setting. It lives in the loop you write around the model, and it needs just one property: the chat interface is stateless. Every request carries the whole conversation and a model name. Both the big cloud APIs and any local server (llama.cpp, vLLM) work this way.
That statelessness is the trick. Because you resend the conversation each turn, you can point the next turn at a different model and edit the conversation before you send it. A locked-down hosted agent cannot edit its own history. A loop you write yourself can - which is why prewalk is actually easier to build against a raw local server than inside a black-box agent.
What I built
I wired prewalk into two routes so I can use it both in the cloud and on my own machine.
- Cloud route. An expensive model explores and lands the first edit, then the loop swaps the model name to a cheaper one and deletes the planning instruction, keeping the same conversation. Same desk, cheaper person.
- Local route. Two local servers. One runs the explorer, the other runs a small fast model. On the first edit, the loop rewrites the very first message of the conversation from “explore and plan” to “just execute the list” and sends the rest of the run to the small model. Rewriting that first message is a single line of code - the payoff of owning your own conversation.
Both share one rule for what counts as “the first edit,” so the swap fires at the same moment no matter which route runs.
Where prewalk helps, and where it does not
| Situation | Does prewalk help? | Why |
|---|---|---|
| One deep feature that touches many files | Yes, a lot | Reading dominates; prewalk removes the double-read |
| A small, self-contained change | Not really | There is barely any exploration to hand off |
| Many small tasks run in parallel | No | Prewalk is one conversation, one worker; parallel work needs separate contexts |
| Two local models of similar quality | Thin win | Little cost gap between explorer and executor |
The sweet spot is a single, meaty change that forces a lot of reading before the first safe edit. That is exactly where the double-read hurts most, and exactly where prewalk pays off.
What to do
- Notice the read/write split. If your agent’s bill is high on a task that ends in a small diff, you are paying for reading. That is the target.
- Let the expensive model explore, plan, and make one real edit. Not a stub. A change that proves the approach.
- Swap at that first edit, in the same conversation. Change the model, keep the history.
- Delete the planning instruction on swap. Tell the cheap model: execute the list, do not re-explore.
- Keep it for deep single tasks. Use parallel workers for many small independent jobs; prewalk does not replace them.
Maxim
Pay the expensive model once, for the reading. Never pay for the same reading twice.
Recap
- A coding agent spends about 90 percent of its tokens reading, not writing.
- The “plan then hand off” trick fails because the cheap model re-reads everything the planner read.
- Prewalk keeps both models in one conversation and swaps at the first real edit, handing over the whole context instead of a tiny plan.
- The cheap model re-reads the conversation once (fast), instead of re-generating the exploration (expensive).
- It works on cloud APIs and local servers alike, because both are stateless - and it is easier to build locally, where you can edit your own conversation.
- Best for deep single features. Not for tiny changes or parallel fan-out.
Sources
- Stencil, Prewalk
- Anthropic, Effective context engineering for AI agents