I ditched Claude Code for a local model and a cloud supervisor, and it's twice as fast

Published Jul 28, 2026, 10:30 AM EDT Anurag is an experienced journalist and author who’s been covering tech for the past 5 years, with a focus on Windows, Android, and Apple. He’s written for sites like Android Police, Neowin, Dexerto, and MakeTechEasier. Anurag’s always pumped about tech and loves getting his hands on the latest gadgets. When he's not procrastinating, you’ll probably find him catching the newest movies in theaters or scrolling through Twitter from his bed. Coding agents like Claude Code are very good at understanding large codebases and figuring out how to implement a complicated change. But they also spend a lot of time doing work that does not require that level of intelligence. For example, if you're using Claude Code with Opus 4.8, you'll notice it takes a long time to even make small edits because it's thinking hard, and that eats into the usage limit. I wanted to see what happens if I split the work that Claude Code is doing between a local agent and a cloud supervisor like GPT-5.6 Terra. The cloud model can understand the task, create a plan, and review the final changes, while a local model handles the actual implementation. The local model is obviously not as capable as the coding agent I’m replacing, but it gets a much narrower task and has a more capable model checking its work. Regarding the kinds of fixes and smaller features I usually work on, this setup completes the job in roughly half the time while using far fewer cloud tokens. I stopped paying the smartest model to do grunt work Terra thinks, Qwen does the typing The biggest waste in a regular coding agent workflow is that the same model handles both the difficult decisions and the repetitive implementation work. It figures out which files need to change, but it also reads those files again, makes small edits, and reruns the same test after every fix. A model like Opus 4.8 is useful for the first part, but using it for the entire loop slows everything down and burns through the usage limit much faster. I split the workflow based on what each model is actually good at. I first gave GPT-5.6 Terra the task, a basic map of the repository, and any relevant error output. It looks at the problem, identifies the files that are likely to matter, and creates a clear implementation plan for the local agent. I use Qwen3-Coder-30B-A3B as the local model. It's capable enough to handle proper coding tasks without being too slow to run locally. I serve it through llama.cpp and connect it to a coding harness that can read the repository, edit files, and run tests. The cloud model tells the local agent what needs to change and what conditions the final implementation has to meet. I also give the local agent a clear stopping point. If it fails repeatedly, needs to change the architecture, or reaches something outside the original plan, it stops and sends the task back to the cloud model. The setup is simpler than it sounds You need a local model, llama.cpp, and OpenCode I did not build a complicated multi-agent system to make this work. The setup has three parts — llama.cpp serves the local model, OpenCode gives it access to the repository, and a temporary Markdown file carries instructions from the cloud supervisor. On macOS, you can install llama.cpp through Homebrew and start the model with a single command: brew install llama.cppllama-server \ -hf unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF:Q4_K_M \ --alias qwen3-coder:a3b \ --host 127.0.0.1 \ --port 8080 \ -c 32768 \ -ngl all \ --jinja The -hf option downloads the GGUF model from Hugging Face. llama.cpp exposes the model through an OpenAI-compatible API, so almost any coding agent that supports custom providers can connect to it. You will need to adjust the quantization and context size based on your hardware. The Q4_K_M file alone is around 18.6GB, and the context cache requires additional memory. Qwen3-Coder only activates 3.3 billion of its 30.5 billion parameters for each token, which makes generation reasonably fast, but the entire model still has to fit into memory. You'd want to go ahead with a lower quantization and a shorter context if your machine doesn't have at least 16GB RAM. I use OpenCode as the coding harness. It already supports llama.cpp and gives the model tools for editing files and running terminal commands. After installing it with npm install -g opencode-ai, I added the following opencode.json file to the repository: { "$schema": "https://opencode.ai/config.json", "model": "llama.cpp/qwen3-coder:a3b", "provider": { "llama.cpp": { "npm": "@ai-sdk/openai-compatible", "name": "llama-server (local)", "options": { "baseURL": "http://127.0.0.1:8080/v1" }, "models": { "qwen3-coder:a3b": { "name": "Qwen3-Coder 30B A3B" } } } } } I also keep an AGENTS.md file in the repository with the correct test command and any project-specific rules. This saves the local model from rediscovering the repository structure every time and reduces the chance of it using the wrong command or changing something it should leave alone. The two models do not communicate through an API. I ask GPT-5.6 Terra to produce a short implementation brief containing the relevant files, required changes, acceptance tests, and stopping conditions. I save that response as SUPERVISOR.md and run: opencode run \ --model llama.cpp/qwen3-coder:a3b \ "Read SUPERVISOR.md, implement only that plan, and stop when its acceptance tests pass." Once OpenCode finishes, I give Terra the Git diff and test output for review. You could automate this handoff with a script, but keeping it manual makes the setup easier to inspect and prevents either model from silently expanding the scope. The speedup only appears on the right tasks Small jobs are where it flies The local model itself is not necessarily twice as fast as Opus 4.8 at generating code. The complete workflow is faster because the expensive model no longer participates in every step in understanding the task and verifying the result. In my split setup, Terra sees the repository information once when it creates the plan and then sees the final diff when the work is complete. Everything between those two points stays on my machine. This works especially well for changes with a clear boundary. Fixing a validation bug, adding a small option, or updating a few related tests gives the local model enough room to work without asking it to make architectural decisions. The supervisor has already removed most of the ambiguity, so Qwen only needs to follow the path laid out for it. That's where I see the roughly twofold improvement. I measure the complete time from giving the task to the supervisor until the final diff passes review, rather than comparing token-generation speeds. The local model can run through several edit-and-test cycles without waiting for another cloud request, and llama.cpp can reuse the existing prompt context as the session grows. The cloud usage is also much lower because terminal output and repeated file content never reach Terra. You can't fully replace a cloud coding agent I still use Claude Code for large refactors and problems where I do not understand the cause yet. It also comes in handy if you are building something from scratch, like a tool or a feature. For most smaller jobs, however, paying one model to reason and another to execute has proven much faster than asking the smartest model to handle every command itself.