How routing works

Every prompt is classified by task type and cognitive shape, then each step is sent to a model that fits it. The shape is scored across deep reasoning, long context, multi-file taste, adversarial and exploratory work.

Conversation or task. Each prompt is first sorted into a conversation (wants an answer) or a task (wants work on the workspace). Conversations skip the pipeline: deep questions go to the Lead or a strong model, everyday ones to the Workhorse or scored routing, with read-only and web tools only.
Task design. For non-trivial work, a planner breaks the prompt into sub-tasks with dependencies and assigns a model to each. It sets quality floors by kind and blast radius: anything with several dependents or touching architecture gets the top tier.
Orchestration. Sub-tasks run in parallel in isolated git worktrees, each with its own lean context slice. A sub-task that fails its validators is escalated to a stronger model, and a strong-model integration pass reviews the merged result.
Learning. Outcomes feed back into routing. Routes that work on your repo get preferred, routes that keep failing get avoided, and both decay over time.

Lead and Workhorse

You can pin two models, or let the router balance cost and quality on its own.

The Lead plans every prompt and executes design and hard tasks.
The Workhorse executes mechanical tasks and trivial prompts.

Pin them in the app’s Models settings, or from the terminal with sparse lead <model> and sparse workhorse <model>. Pass off to clear a pin.

Batch-only, free-tier and floating OpenRouter variants are never auto-routed.

See why a model was picked

Every decision carries a rationale: which classifier fired, which shape axis dominated, which validator failed.

sparse route "fix typo" --explain   # difficulty, policy, value breakdown and runners-up
sparse logs                         # recent runs
sparse logs <runId>                 # the full decision timeline for one run

In the desktop app, the Sessions page shows the same timeline.