Adding a local model to your toolkit isn't really about the model — it's about where each task goes. The interesting question isn't "is the local Qwen model as smart as a frontier cloud agent?" (it isn't, quite). It's "which work belongs on my machine, for free and in private, and which belongs in the cloud?" That routing decision is orchestration. This post is about how Command Fleet lets you make it — task by task, on one board.
What "local LLM orchestration" means
Orchestration is coordination: planning work, dispatching it to the right worker, running it safely in isolation, and integrating the result. Local LLM orchestration is the same thing with one of the workers running on your own hardware. A model served by Ollama and driven by the Qwen Code CLI becomes a first-class agent on your board — you dispatch a task to it exactly like you'd dispatch to Claude Code, and it gets the same isolated git worktree, the same streaming output, and the same review-before-merge gate. The only difference is that nothing leaves the machine.
An agent-agnostic layer
The reason a local model can slot in at all is that Command Fleet's orchestration layer doesn't care which model is doing the typing. The board, the worktrees, the dispatch, the diff review, the merge — none of it is bound to a particular provider. Cloud agents (Claude Code, Codex, Gemini) and the local Qwen agent all speak to the same machinery. So "add a local model" isn't a bolt-on mode; it's a fourth agent in a system that was already built to be agent-agnostic.
The model is a worker, not the workflow. Because the workflow is agnostic, swapping in a private, on-device worker for some tasks costs you nothing in how you operate.
Routing work to the right agent
The skill in orchestration is matching the task to the worker. A local coding model has a clear sweet spot: read-only, advisory work where it proposes and you decide. The standout is a codebase review — point the local agent at a project and it explores the repo and drops a prioritized backlog of suggested tasks (bugs, missing tests, refactors, security gaps) straight onto your board, without your code ever leaving the machine. Explaining unfamiliar code, drafting a plan, and answering questions about the repo land in the same comfortable zone.
Cloud agents earn their keep on the other end: long, execution-heavy, autonomous work — "implement this feature across six files, run the tests, fix what breaks." That's where a frontier model's stamina and reliability pull ahead. The orchestration pattern writes itself: route the cheap, private thinking to the local model; route the heavy building to the cloud.
- Local model → codebase reviews, code explanations, plan drafts, advisory passes — private and free.
- Cloud agent → multi-file features, refactors with tests, the autonomous build loop — stronger at sustained tool use.
Local and cloud, side by side
Mixing agents doesn't mean taking turns. Cloud runs still go in parallel across isolated worktrees — five agents on five projects, none of them touching your working tree until you say so. The local agent has one extra rule: local runs are capped to one at a time. A large model is heavy on memory, and loading two at once is what actually crashes a machine, so the scheduler keeps local concurrency at one while letting cloud runs fan out as usual. In practice you get a private review chugging away on your hardware while three cloud agents build features in parallel — all on the same board, all in the same review queue.
The board doesn't distinguish "local" from "cloud" — it just shows you what's queued, running, in review, and done. The agent is an implementation detail of each card.
Keeping the routing honest
Good routing needs honest signals about what each worker can actually do, and a local model is where that matters most. Two guardrails keep the orchestration grounded:
- A tool-execution probe. Before you trust a local model with an edit/run task, a one-click test asks it to run a trivial command and checks whether it really happened — proof it can execute on your machine, not a guess from a spec sheet. If a model can only describe changes, the task UI warns you and points to a stronger agent instead of finishing as if work was done.
- Review-capable gating. Driving a codebase review well takes a strong model; lighter local models explore fine but then summarize their findings as prose instead of emitting real tasks. So reviews are gated to the flagship local model (or a cloud agent), while lighter models stay available for the edit/run tasks they're good at.
The point is no silent failures: the orchestrator routes around a worker that can't do the job rather than letting it quietly do nothing.
Where the autonomous PM fits
One honest boundary worth drawing: the local model is an orchestrated agent, not the orchestrator. Command Fleet's autonomous workspace PM — the manager that scaffolds a project, plans a task graph, and delegates a whole build — dispatches its tasks to the cloud agents. Think of the local model as the private analyst you bring in for a specific task, not the manager running the crew. You can absolutely use both in a day: let the PM build a feature with cloud agents, then run a free, on-device review of the result before you merge.
A workflow that uses both
Here's the loop in practice. You start a sensitive client project and run a local codebase review first — private, free, and it seeds your board with a backlog. You triage that backlog, then dispatch the execution-heavy cards to Claude Code, Codex, or Gemini, which run in parallel in their own worktrees. While they build, the local model is free to take another advisory pass on a different project. When a cloud agent finishes, you read the diff, optionally run one more local review as a cheap second opinion, and merge. Sensitive thinking stayed on your machine; the heavy lifting went to whichever agent was strongest — and you never left the board.
Key takeaways
- Orchestration is routing. The value of a local model is deciding which tasks belong on your machine and which belong in the cloud.
- The layer is agent-agnostic. The board, worktrees, dispatch, and review don't care which model types — so a local agent is a first-class fourth option, not a separate mode.
- Match work to worker. Local for private, free, advisory work (reviews, explanations); cloud for long, autonomous building.
- They run together. One local run at a time (a memory safeguard) sits alongside any number of parallel cloud runs.
- Honest signals. A tool-execution probe and review-capable gating route around a local model that can't do a given job, so nothing silently no-ops.
Frequently asked questions
What is local LLM orchestration?
It's running a model on your own machine as one agent inside a larger workflow — dispatched, reviewed, and merged on the same board as cloud agents. Command Fleet's orchestration layer (the board, isolated git worktrees, dispatch, review, and merge) is agent-agnostic, so a local Qwen model via Ollama plugs in as a first-class agent you can route tasks to per job.
Should the local model or a cloud agent do the work?
Route by the nature of the task. Send private, free, offline work — codebase reviews, explanations, and advisory tasks where the model proposes and you act — to the local model. Hand execution-heavy autonomous building to a cloud agent like Claude Code, Codex, or Gemini, which are stronger at long, tool-driven tasks. Because you pick the agent per task, you can mix both on one board.
Can the local model run the autonomous build loop?
No. The workspace PM that scaffolds, plans, and delegates a whole build dispatches its tasks to the cloud agents (Claude Code, Codex, Gemini). The local model is for per-task dispatch and codebase reviews you trigger yourself — the private analyst you bring in, not the manager that runs the crew.
Can local and cloud agents run at the same time?
Yes. Cloud runs happen in parallel across isolated worktrees as usual. Local runs are capped to one at a time so a large model doesn't thrash your machine's memory — but that local run sits happily alongside any number of cloud runs. The board shows all of them together.
Orchestrate local and cloud agents on one board
Command Fleet runs Claude Code, Codex, Gemini — and a fully local Qwen model — across every project, on your own machine. Route each task to the right one. Free for 7 days, no credit card.