Run a fleet on mixed models

Most tools make you pick one model and live with it. In Lanes the provider and the model are chosen per session, which means a single board can span them. The rename job runs on a model on your laptop while the tricky migration runs on a frontier model on your subscription, both in their own worktrees, both reviewed the same way.

This is a workspace-shaped capability. It only means anything when you are running several agents at once.

How Lanes does it

Three rows, set per session. The launch flyout carries Harness, Model, and Gateway, so each session picks its CLI, its model, and where the requests go. Nothing is global, and nothing has to be changed back afterwards.
Isolation does not care who served the tokens. Every session still gets a git worktree and branch off your base branch, created and cleaned up automatically. A cheap local session cannot tread on an expensive one.
Cost is visible per session. The Meta tab tracks tokens, cost, and runtime on each one, so the question "was that worth doing on the big model" has an answer on the card rather than in a monthly invoice.
Review is uniform. Whatever produced the diff, it lands as a branch you read in the Changes pane before it merges. The model choice is an input to the work, not a reason to trust it more or less.

A split that works

There is no scheduler doing this for you, and that is deliberate. You choose, per issue, and a few defaults hold up well:

Local models for volume. Lint fixes, mechanical renames, test scaffolding, dependency bumps, first drafts of a docs page. Marginal cost is zero, so a retry costs nothing but time. Respect the Fit column: a session sends roughly 38,000 tokens before you type, so a model that cannot hold that will produce confident nonsense rather than an error. Running agents on a local model covers why.
Your subscription for the work that needs judgment. The architectural change, the bug nobody has reproduced yet, the plan-mode run you want to be right before any code is written. Sessions on the CLI's own provider are the real binary in a real terminal, which is interactive use, so they draw on the plan you already pay for.
A bought provider for burst or for a specific model. A provider profile pointed at OpenRouter, z.ai GLM, or a vLLM box on your network covers the cases where you want capacity now, or want one particular model for one particular task.

You can also run the same issue twice, on two different models, and keep the diff you prefer. Sibling sessions share the issue's worktree but keep separate transcripts and metrics, which is the same move as running Claude Code and Codex side by side, one level down.

Why it matters

The usual argument about local models is whether they are good enough to replace a frontier model. That is the wrong question for a fleet. Plenty of the work on a real board is mechanical, and paying frontier prices for it is a choice you only make because your tool made model selection a global setting.

Splitting the fleet also changes what you are willing to start. When a third of the board costs nothing to run, the speculative refactor and the second opinion stop needing justification. The board stays the control surface either way: same columns, same statuses, same bell when a session wants you, regardless of what is answering it.

Set it up

Install Lanes and open it:

Bash

brew install --cask lanes-sh/lanes/lanes && open -a Lanes

Then:

Set up one local model in Settings, Agentic Coding, Local LLMs. Lanes registers the daemon as a Gateway provider once it has a model to serve.
Start two sessions on two issues. On the mechanical one, set Gateway to your local daemon and pick the tag in Model. On the hard one, leave Gateway on the CLI's own provider.
Watch the Meta tab on both. Tokens, cost, and runtime per session are what tell you whether the split is set correctly.

How Lanes does it

A split that works

Why it matters

Set it up

Further reading