A few weeks ago I was hitting the Claude Code rate limit twice a week. The work I was trying to do was not exotic. It was ordinary multi-file refactors and a couple of greenfield prototypes. I had the Max plan. The limits still ran out. Then I split the workflow in two and the problem quietly went away.
The split is simple. Claude Code does the part of the work where I most want a strong reasoning model: the planning. A local model runs on my own hardware and does the part that mostly needs to execute against an existing plan. The result is not a perfect workflow. It is a workable one. The article walks through what I changed, what got worse, and what I would tell someone considering the same setup.
What planning actually needs from a model
Planning is where a weak decision costs me hours later. If I am going to refactor a service across eight files, I want a model that can read the whole codebase, ask the right clarifying questions, and propose a sequence of changes that does not break the build halfway through. That is the part of the work that I am willing to pay for, and that is the part where the strongest model I can get is genuinely worth the cost.
Local LLMs (large language models, the kind that run on your own machine instead of in a data center) have gotten noticeably better at coding over the last year. The earlier generation was good for autocompleting a function. The current generation will sit inside a multi-file change and recover when an edit fails. That said, no local model I have tested beats a frontier cloud model at the open-ended reasoning part. The planning half of coding is where the gap still shows.
For the planning half I lean toward the strongest tier I have access to. Sonnet and Haiku are good for many tasks. For planning I want Opus or Fable, because I am paying for judgment and I do not want to ration it on the step that determines the rest of the work.
Claude Code’s Plan mode is the cleanest way I have found to do this part. It runs in read-only mode, so the model can inspect the project, ask follow-up questions, and refine its proposed sequence without touching a file. By the time I am ready to switch to implementation, I have a written plan that names the files, the changes, and the things that might break.
What execution actually needs from a model
Once the plan is settled, the work that follows is mostly execution against an instruction set. The hard parts have been decided. The local model gets handed a concrete set of edits to make, the relevant files to read first, and the failure modes to watch for.
On a 32 GB Mac with a recent Apple Silicon chip, Qwen3-Coder-Next at a sensible quantization (a reduced-precision version of the model weights that uses less memory at the cost of some accuracy) is fast enough to feel interactive on these tasks. Smaller and older models still struggle with multi-file work. The latest generation has crossed the line for me.
The local setup has its own costs:
- Hardware. You need a machine with enough unified memory to hold the model weights and a long enough context window for the files in play. A 16 GB laptop is too tight for anything serious. 32 GB is the floor.
- Setup time. Getting the runtime, the quantization choice, and the context window tuned for your machine takes a few evenings the first time. After that it is a single launch command.
- No web access. A local model does not fetch documentation. If the plan relies on a library you have not read the docs for, the implementation will silently miss the parts it should have caught. Cloud models with web tools do not have this problem.
The cost I underestimated is the planning handoff. If the plan is too thin, the local model will make the same small decisions a stronger model would have made, and the result will be subtly wrong in ways that are hard to spot during review. The plan needs to be specific enough that the implementation is mostly mechanical.
Why this is not the same as letting the cloud model do everything
When I let Claude Code handle the implementation too, the work was good. The issue was not quality. The issue was that every Sonnet or Opus call against a multi-file change consumed a meaningful slice of my weekly limit, and the implementation half is where most of the calls live. Planning is one pass through a codebase. Implementation is dozens of iterations.
After the split my limits last the full week. I still use Opus on the parts that matter. The local model eats the calls that used to add up without me noticing them.
I am not canceling my Claude subscription. I tried to imagine doing all of this on a local model alone and the planning half is worse. The frontier cloud models are still meaningfully better at the open-ended reasoning, especially when the codebase has unfamiliar conventions or the requirements are ambiguous. The plan-then-execute split puts each model in the slot where it is strongest.
Trade-offs
The split is not free in setup. The first time I configured the local runtime it was about three evenings of trial and error. The runtime has a config file, a quantization choice, a context window setting, and a system prompt that matters more than I expected. None of these are difficult individually. Together they are a project.
The split is also not free in attention. I now switch between two tools. The plan lives in Claude Code. The implementation lives in a different terminal. Keeping the handoff clean requires me to actually copy the plan over and paste it, which adds friction. When the work is small, the friction is not worth it. I still run small edits through Claude Code alone.
Quality has not moved much. The local model on a good plan produces code that passes review at the same rate as the cloud model. The cases where the cloud model is meaningfully better are the cases where the plan was thin to begin with, which is a planning problem, not an execution problem.
If you want to try this, the path that worked for me:
- Keep Claude Code for planning. Use Plan mode for anything that touches more than two files.
- Pick a local model from the current generation. Qwen3-Coder-Next at Q4 or Q5 quantization is the floor. Larger quantizations are noticeably better for multi-file work.
- Write the plan out as a real document. List the files, the changes, the things that might break, and the tests that should still pass. Paste it into the local model’s context.
- Review the diff before committing. The local model is good. It is not infallible, and the parts it gets wrong are the parts where the plan was vague.
Skip this setup if your work is mostly small edits, or if you are on hardware that cannot comfortably run a coding model. The savings on rate limits are real but they are not worth a week of fiddling if your machine is going to be unhappy about it.
If you only do one thing from this article, try Plan mode on your next non-trivial task. Whether or not you keep the cloud model through implementation, you will write better plans, and better plans are the part of the workflow that is upstream of everything else.