AI-assisted coding has seen massive changes in the last few months. For starters, it’s turned from what seemed like a gimmick into something that can handle a meaningful chunk of a development workflow. LLMs have also gotten incredibly capable, and the kind of tools that exist for development now are very different from what we had initially.

Coding agents like Claude Code and Codex can now inspect entire repositories, reason through unfamiliar codebases, plan multi-step changes, run commands, and keep iterating until something actually works. All of these improvements also mean that more and more people are leaning on AI for their coding needs, including people who have never seen a line of code before since the barrier to entry is lower than ever.

The downside to all of this increased usage is that it requires extra compute, and that usually translates into stricter usage limits. That’s the problem I kept running into with Claude Code, so I began splitting my usage between Claude Code and a local model instead.

Local LLMs have gotten incredibly capable at coding

Way, way, way better than they used to be

I’ve been running local LLMs here and there for a fair bit now, and my experience initially was a mixed bag. There were some genuinely impressive models, but none of them felt capable enough for me to rely on for anything beyond relatively simple tasks. They were great for experimentation, but the moment I gave them a larger codebase, a more involved set of instructions, or a task that required several steps of reasoning, the limitations became obvious very quick.

And then come all of the drawbacks of setting up and running a local LLM. You need capable enough hardware to actually run one, need to spend a fair bit of time setting everything up, and often have to experiment with different quantizations, context lengths, and runtimes just to find something that performed well on your machine. After all of that, the result still usually wasn’t as capable as simply opening Claude or ChatGPT and using one of the best cloud models available.

That’s changed quite a bit recently. Local models have improved to the point where I no longer think of them as something I run purely for privacy or experimentation. For instance, XDA’s resident local LLM expert, Adam Conway, wrote about Qwen3-Coder-Next and described it as the first coding model he actually wanted to use rather than one he was running out of principle. In his testing, it was able to handle real coding tasks, work through multi-step jobs, call tools, edit files, and recover when things went wrong.

Local LLMs aren’t great at everything

They do one thing really well, though

Claude running on an M1 Mac with Gemma 4 on a large display behind it.

Of course, this doesn’t mean that local models have suddenly caught up with cloud models. A model working on your own hardware, no matter how capable, can’t realistically compete head-to-head with a frontier model running on massive amounts of compute in a data center. Besides having access to significantly more compute, frontier models also tend to be much better at the parts of coding that require deeper reasoning.

Cloud LLMs are a lot better at understanding ambiguous requirements, weighing different approaches, spotting edge cases, and making architectural decisions before any code is actually written. They’re also more reliable when a task requires several rounds of reasoning or when the right solution isn’t obvious from the outset.

Services like Claude and ChatGPT can pull in up-to-date information from the web when needed, while a local model is usually limited to whatever knowledge was baked into its training unless you explicitly give it search or retrieval tools. That makes cloud models much better suited to the exploratory side of development, where figuring out what to do can require checking documentation, researching an unfamiliar library, or comparing several possible approaches.

None of the above makes local models useless, though. It just means I’ve stopped asking them to do the part of the job they’re weakest at. I’ve realized that there’s one part of the coding process where local models perform fairly well: executing a plan that’s already been worked out for them.

Claude plans it, my local model builds it

One model plans, the other clocks in

While I could theoretically make my setup a lot more autonomous, I’ve chosen to keep a clear handoff between the two models. What I’ve started doing is heading to Claude Code initially and spending a bunch of time hashing out what I’m trying to build, how I’m going to build it, and any potential issues I might run into along the way. I essentially use Claude for the part of the process that requires the most reasoning, going back and forth with it until I have a plan detailed enough that there aren’t many decisions left to make.

Despite having moved a lot of the tasks I make Claude do to Sonnet and Haiku to make sure I don’t have to ration my limits at the end of the week, this is one of the parts of my coding workflow where I still prefer using the most capable model I have access to. Planning is where I want the stronger reasoning, because a weak decision here can easily create more work later once the implementation starts. So, I lean toward Opus or Fable for this part of the process.


Claude Fable 5 home page on the desktop app.

Related


I changed one setting in Claude Code, and my token burn dropped by 45%

Claude Code was overthinking the assignment

Claude Code’s Plan mode is great for this stage as well. For those unfamiliar, it’s a read-only mode that lets Claude inspect your codebase, understand how everything fits together, and work out an implementation approach without actually making any changes. That makes it ideal for the planning half of this workflow, since I can let Claude dig through the project, ask any follow-up questions, and refine the approach before anything gets touched.

I then take the finished plan and hand it over to my local model to actually build. At that point, most of the difficult decisions have already been made for it. It knows what I’m trying to accomplish, which parts of the codebase are relevant, how the implementation should work, and what potential issues it needs to watch out for. Instead of asking the local model to reason through the entire problem from scratch, I’m essentially giving it a detailed set of instructions and asking it to execute them.

My limits thank me

I’ve considered upgrading to the Max 20x Claude tier (or canceling my subscription entirely) countless times because I’m tired of rationing my limits. However, splitting my workflow this way has made that problem much less noticeable.

The best part is that I’m not making any sacrifices in quality, either. Claude is still doing the part of the workflow where I care most about having the strongest model possible, while the local model takes over once the important decisions have already been made. As long as the plan is detailed enough, I’ve found that the final result is just as good as if I’d let Claude handle the implementation too.