LLM Orchestration: Managing Claude Code, Codex, and Local Models

Using Git worktrees to run multiple AI agents in parallel is the only way to maintain "vibe coding" momentum when you hit token limits. I spent the last weekend building a coordinator to handle a three-way orchestration between Claude Code, 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 wrote orchestrate.py to handle subcommands like add, run, status, review, merge, and discard.
• 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 as status: 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:

# Example of the internal logic the dispatcher uses to isolate agents
# 1. Create a unique branch for the agent task
git branch agent-task-123

# 2. Add a worktree in a separate directory to avoid collisions
git worktree add ../orchestra-worktrees/task-123 agent-task-123

# 3. Execute the agent command within that directory
cd ../orchestra-worktrees/task-123 && claude-code "Implement the X feature"

# 4. Commit changes and return to main repo for review
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.