The Conductor & routing
Lectern can drive several agents at once — Claude Code, Antigravity (Gemini), OpenCode and its free/OpenRouter models. Two mechanisms decide which model does what: Auto routing for single tasks, and the Conductor (/conduct) for multi-step goals.
Auto: one task, the right model
With the model set to Auto, each task is routed by rules you can read and edit in ~/.lectern/routing.json (open it from Settings → Routing). Rules match on the shape of the task and send it to a fitting model; an optional fast classifier breaks ties on ambiguous prompts.
| Task looks like | Routed to | Why |
|---|---|---|
| A one-word fix or rename | A small, fast model (e.g. Haiku) | Cheap and instant; no reasoning needed |
| Architecture / a hard bug | A strong reasoner (e.g. Opus) | Depth matters more than latency |
| Screenshot / visual task | A vision model (e.g. Gemini Flash) | Best at images, and fast |
| No rule matches | Your default, or the classifier's pick | Sensible fallback, never a hard fail |
Routing is fully local and inspectable — nothing is sent anywhere to decide where a task goes.
/conduct: a goal across providers
/conduct <goal> treats the request as a project, not a single turn. It runs four stages:
- Plan — the goal is decomposed into concrete sub-tasks with their dependencies.
- Route — each sub-task is classified and assigned to the model best suited to it (same idea as Auto, per step).
- Fan out — independent sub-tasks run in parallel, each in its own git worktree so they can't collide.
- Cross-review & merge — a different provider reviews each result before it's merged back, so no single model grades its own work.
The cross-provider review is the point: a bug one model introduces is often caught by another with different blind spots. You can run it as a one-off (/conduct fix the flaky test and document it) or toggle it on for a session.
Why parallel steps stay safe
Fanned-out steps each get an isolated git worktree, so two agents editing at once never overwrite each other. Results merge back only after review; a step that fails review is redone rather than silently accepted.
From the CLI
lectern conduct "add rate limiting to the API and cover it with tests" # plans, routes each sub-task, runs independent ones in parallel, # cross-reviews across providers, then merges