ClaudeCode, OpenAI's Codex CLI, and a local LLM setup. The goal was simple: stop staring at "rate limit reached" messages and keep the development loop moving.
The Local LLM Gap: Qwen 2.5-Coder vs. Agents #
I'm running an M1 Max with 64GB of unified memory. Initially, I tried using Qwen 2.5-Coder 32B via Ollama. While it's great for autocomplete, it struggles with the multi-step, agentic tool-calling that makes Claude Code so effective.
To fix this, I swapped to Qwen3-Coder-Next. It's a MoE (Mixture of Experts) model with 80B total parameters but only 3B active. At Q4 quantization, it takes up about 49GB of VRAM. This fits within my 64GB limit, though it leaves little room for other memory-heavy apps. More importantly, the performance is significantly closer to Sonnet-class coding.
The real unlock wasn't just the model, but the harness. Raw Ollama isn't an agent; it's a chat interface. I integrated OpenCode as the orchestration layer, which allows the local model to actually read a repository, plan changes, and edit multiple files using tool calls.
Building the Orchestration Layer #
I developed a lightweight Python dispatcher called agent-orchestra
. It's a stdlib-only script (about 250 lines) that manages tasks across different agents without them colliding in the same working directory.
The technical architecture follows these rules:
Git Worktrees: This is the secret sauce. Every agent task is assigned its own branch and its own physical directory. This allows Claude Code and a local Qwen agent to edit the same codebase simultaneously without merge conflicts or file-lock issues.The Dispatcher: I wroteorchestrate.py
to handle subcommands likeadd
,run
,status
,review
,merge
, anddiscard
.No Auto-Merging: I treat every agent like a fast but inconsistent junior developer. Every output is auto-committed to its specific branch and marked asstatus: review
. I manually review the diff before merging.Concurrency Caps: Because local VRAM is a bottleneck, the local agent is capped at one concurrent job. API-based agents like Claude and Codex have higher limits.
Implementation Details and Bug Fixes #
During a deep dive into the deployment, I hit a specific issue where I initially placed the worktrees inside the target repository. This cluttered git status
with a massive amount of untracked noise.
The Fix: I moved agent-orchestra
to be a standalone tool located outside the project directory. I now invoke it via a shell alias.
Here is a simplified version of how the task dispatching logic handles the worktree creation:
git branch agent-task-123
git worktree add ../orchestra-worktrees/task-123 agent-task-123
cd ../orchestra-worktrees/task-123 && claude-code "Implement the X feature"
git add . && git commit -m "Agent implementation: task-123"
Tooling Transitions #
I almost integrated this with Vibe Kanban for a better UI, but discovered the project is sunsetting. I've since pivoted to Claude Squad, which shares a similar philosophy of using tmux and worktrees to manage multiple agent sessions.
This setup has turned my local machine into a legitimate failover. When the Claude API hits a ceiling, I shift the workload to the local MoE model. It's not a 1:1 replacement in terms of intelligence, but with a proper agent harness and worktree isolation, it keeps the project moving forward without the downtime.
Next Ed Zitron's Take on the AI Bubble: Risk Analysis →