Weekend #2: Scafolding the 3-Way LLM Orchestration

Johan Sulaiman — Sat, 25 Jul 2026 00:53:26 +0000

Last time, I closed with a line I half-meant as a joke: "a 3-way orchestration between ChatGPT, Claude, and my local LLM, to maintain my vibe coding momentum even when I hit token usage limits." One of you commented that you couldn't wait for your Claude Code session to refresh at 9:50am. Same feeling, different weekend. So this time I actually built the thing.

The question that started it
I'm running Qwen 2.5-Coder 32B locally via Ollama on an M1 Max, 64GB unified memory — fixed hardware, not upgrading it any time soon. The question was blunt: can this local setup actually stand in for Claude Code when I hit a wall, or am I fooling myself?

Short answer: not as-is, but closer than I expected. Qwen2.5-Coder 32B benchmarks around GPT-4o territory — fine for autocomplete, weak on the multi-step, tool-calling agentic work Claude Code does well. The real fix wasn't a bigger local model alone, it was pairing a better local model with a proper agent harness instead of raw Ollama chat.

What changed on the local side
Swapped in Qwen3-Coder-Next — a MoE model, 80B total params but only 3B active, so it actually fits in 64GB unified memory (tight: ~49GB at Q4, so nothing else memory-hungry runs alongside it). Benchmarks land close to Sonnet-4.5-class coding performance, which is the first time "local" has felt like a real second seat at the table rather than a toy.

Harness matters as much as the model. Raw ollama run isn't an agentic loop — I put OpenCode in front of it instead, which turns the local model into something that can actually read a repo, plan, and edit multiple files with tool calls, the same shape of workflow Claude Code and Codex CLI already give me.
Building the actual orchestration
This is the part I actually spent the weekend on: agent-orchestra, a small, transparent coordinator that lets me hand a task to Claude Code, OpenAI's Codex CLI, or my local OpenCode+Qwen agent — and run all three in parallel against the same repo without them stepping on each other.

The mechanics, deliberately boring:

Git worktrees — every task gets its own branch and its own working directory, so three agents can edit the same repo at once with zero collision.
A stdlib-only Python dispatcher (orchestrate.py) — no dependencies, ~250 lines, add/run/status/review/merge/discard as subcommands. Queue a task, walk away, come back to a diff.
No auto-merge, anywhere. Every agent's output lands on its own branch, gets auto-committed for a clean diff, and sits at status: review until I explicitly merge it. Treat every agent like a fast, inconsistent junior dev — because that's what it is.
Per-agent concurrency caps — the local model is capped at one concurrent job (only one thing realistically fits in memory at a time), Claude and Codex get more headroom since they're just network calls.

Before trusting any of this with real work, I wrote fake claude/ codex/opencode stand-ins and ran the whole add → run → review → merge lifecycle against a throwaway git repo. Worth doing — it caught a real bug (worktrees nested inside the target repo cluttered git status with untracked noise), which reshaped the final design: agent-orchestra now lives as its own standalone tool, outside any project it's pointed at, invoked via a shell alias against whatever repo you cd into. Clean separation, no clutter, and it's now getting its own init-repo.sh to turn into a real GitHub repo (gh repo create ... --push, one command).

The plot twist: almost shipped on a dead product
I went looking for a nicer interface than raw tmux panes. Found Vibe Kanban — genuinely great looking, real Kanban board, diff review, built-in browser preview, supports exactly the agents I care about. Then I actually opened its GitHub repo and the README's first line now reads: "Vibe Kanban is sunsetting." Glad I checked before building on it.

Landed instead on Claude Squad — actively maintained, same tmux-plus-worktree bones I'd already built by hand, but wrapped in a real terminal UI: a session list, a live diff tab, a one-key commit/push. Configured it with three profiles — claude, codex, local — so switching agents is a picker, not an env var.

Then I actually ran it
Design docs are cheap. So I moved the whole thing to ~/tools, ran the install script for real, and let it pull Qwen3-Coder-Next — a genuine 51GB blob, which is exactly the number I'd guessed at on paper. Six tools, one script, no manual intervention: Ollama, Claude Code, Codex CLI, OpenCode, GitHub CLI, Claude Squad, all confirmed working via a check subcommand I'd built specifically so I wouldn't have to take my own setup script's word for it.

Outcome: Claude Code, invoked headlessly, in its own git worktree, wrote a file and a test, committed to its own branch, and sat there waiting for me to review the diff — exactly the shape I designed for. That's the loop working end to end, on real hardware, with a real bug found and fixed along the way instead of staying theoretical.

Two ways to drive it now:
Claude Squad for anything I want to watch happen or steer — day-to-day driving.
orchestrate.py for fire-and-forget batches — queue five small tasks across three agents before bed, review diffs in the morning.

One honest gap: I haven't actually validated the local-model path yet. First attempt sat at "starting on local..." long enough that I bailed and routed that task to Claude instead — Qwen3-Coder-Next's cold start, loading 49GB into unified memory before it generates a token, is a real wait, not a rounding error. Works fine once warm, in theory; I just haven't sat through it yet. Next session's job.
Up next
Now that the three agents can actually share work without me babysitting context switches, the next itch is closing the loop further: can the orchestrator route tasks by difficulty on its own instead of me manually picking an assignee? I still owe the local-model path a real cold-start timing test. And I still owe myself that always-on architecture-hygiene dashboard from last time a proper look.

What's your local-model breaking point — the task you've tried offloading to a local LLM that just wasn't worth the fight?

A One-Weekend AI Build Stack (and the day I finally made peace with IAM)

Johan Sulaiman — Sun, 19 Jul 2026 23:25:39 +0000

I spent this weekend finally joining the vibe coding revolution: not by writing much code — but building the thing that writes it.

The shift: I stopped treating my AI tools as a smarter autocomplete and started treating them as a small team that hands work to each other. One prompt in plain English, and the "how" runs itself.

The Weekend #1 stack

Here's the actual wiring from two sessions (~10 hours, 158 shell runs, 12 tools stitched together):

You → Claude Code (orchestrator). Plans, runs the shell, writes files, and drives a real browser to verify its own work.
Local agent mesh. A local Qwen 2.5 model via Ollama, Cline inside VS Code, and a GitHub MCP server bridging the repo over Docker.
Code & cloud. A Vue web app on a staging environment, backed by AWS Amplify + DynamoDB (and, yes, IAM).
Data platform. A Python pipeline → DuckDB → Metabase dashboards.
Cross-cutting. An always-on monitor + architecture-hygiene dashboard (LaunchAgent), and persistent memory files so context carries from one session to the next — I'm not re-explaining myself every morning.

The funny part: IAM

I have always hated IAM. Users, roles, policies, access keys — historically my cue to throw my hands up and quietly give up on whatever I was building.

This weekend I ran amplify pull and the whole thing — user, profile, policies, access keys — came up correctly in minutes. Even the scary "owners may reassign ownership" warning didn't send me running. After years of that being my wall, it just… wasn't. A genuine 0→1 for me.

That's the real story of "productivity" here. It's not that I type faster. It's that the tasks I used to avoid — the ones that quietly killed projects before they started — are now approachable. The ceiling moved because the floor did.

Up next

Autonomous agents that build and self-improve on these projects, so the loop closes without me holding every thread. Curious, and a little cautious, about what that changes. Or a one-stop social media posting engine. Or a 3-way orchestration between ChatGPT, Claude, and my localLLM, to maintain my vibe coding momentum even when I hit token usage limits.

What's the task you've always avoided that AI finally made approachable?

DEV Community: Johan Sulaiman

Weekend #2: Scafolding the 3-Way LLM Orchestration

A One-Weekend AI Build Stack (and the day I finally made peace with IAM)

The Weekend #1 stack

The funny part: IAM

Up next