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

A developer built an orchestration layer called agent-orchestra to manage Claude Code, OpenAI's Codex CLI, and local LLMs, using Git worktrees to isolate agent tasks and prevent merge conflicts. The setup runs Qwen3-Coder-Next (80B total, 3B active parameters) at Q4 quantization on an M1 Max with 64GB unified memory, achieving near-Sonnet-class coding performance. The dispatcher caps local agents at one concurrent job and API-based agents at higher limits, enabling failover when rate limits are hit.

LLM Orchestration: Managing Claude Code, Codex, and Local Models Claude /en/tags/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. Next Ed Zitron's Take on the AI Bubble: Risk Analysis → /en/threads/3018/