8bc529ef2d
Some checks failed
CI — Test & Build / Test & Build (push) Has been cancelled
- Implemented a status bar item for LexAI with dynamic status updates (ready, processing, notReady). - Created a suggestion panel for displaying and interacting with AI-generated suggestions. - Added functionality for accepting, regenerating, and discarding suggestions within the suggestion zone. - Introduced configuration options for writing style, prompt patterns, personas, and formats. - Integrated progress indicators for long-running tasks and improved user feedback. - Established TypeScript configuration for the vscode package.
32 lines
3.6 KiB
Plaintext
32 lines
3.6 KiB
Plaintext
---
|
|
description: How to choose which model runs a piece of work in this project. Apply when deciding what to delegate and to whom, when writing an orchestration record, when a subagent seems too cheap or too expensive for its job, when a Task call fails with an unknown model, or when anyone proposes writing a model name into a file.
|
|
alwaysApply: false
|
|
---
|
|
|
|
# Lane routing
|
|
|
|
This project routes by **lane**, never by model name. The lanes are bound to real model IDs in `@docs/MODEL_ROUTING.md`, and only two places may contain a model ID: that file, and the `model:` frontmatter of `.cursor/agents/*.md`. Both are written by `/model-routing`.
|
|
|
|
| Lane | Runs | Choose it for | Never for |
|
|
| --- | --- | --- | --- |
|
|
| **fast** | scout · verifier · learning-steward | narrow search, running checks, extraction, lesson capture | architecture, ambiguous change, security sign-off |
|
|
| **mid** | builder · integrator · ux-ui-designer · ux-psychologist | implementation, debugging, ordinary planning, design work | novel high-consequence decisions without review |
|
|
| **strong** | critic · security-auditor · system-steward · planner · gauntlet-critic | adversarial review, security analysis, architecture, final synthesis | retrieval, boilerplate, anything a command can decide |
|
|
| **lead** | this session | framing, routing, judging evidence, fast-path edits | deep implementation it should have delegated |
|
|
|
|
**Routing test.** Can a cheap model succeed given a precise contract and a deterministic verifier? Yes → `fast`. Known-pattern implementation → `mid`. Otherwise → `strong`, then verify independently.
|
|
|
|
## Rules that actually bite
|
|
|
|
- **Never write a model ID into `AGENTS.md`, a rule, a skill, or a task packet.** Name the lane. A model ID outside the two allowed places is drift that survives until the model is retired and then fails loudly at the worst moment.
|
|
- **Never change a subagent's `model:` line by hand.** Run `/model-routing`, which keeps the frontmatter, `docs/MODEL_ROUTING.md`, and the lead's picker selection in agreement. Editing one of the three creates a routing that is true nowhere.
|
|
- **`model: inherit` is not a bug — but it is not free either.** It means the subagent runs on the lead's model. A roster on all-inherit has no cost split at all, so a "cheap scout" costs exactly what this session costs. If the sessionStart hook reports the routing is unbound, say so before delegating rather than after.
|
|
- **Escalate one lane, once, on evidence.** A concrete failure at the current lane justifies one step up. Record a permanent escalation in `docs/DECISIONS.md`.
|
|
- **A second vendor is a cross-model critic, not a second builder.** Give it the contract, the proposed result, and a sharp question — "what would make this fail the acceptance tests or harm users?"
|
|
- **The referee is never cheaper than the builder.** `gauntlet-critic` rides `strong` by construction; a referee weaker than the thing it judges rubber-stamps. `Auto` is disallowed on `strong` for the same reason — a parity verdict from a router that may have downgraded is not a verdict.
|
|
- **The gates assume `strong` is genuinely stronger than `mid`.** If `docs/MODEL_ROUTING.md` records a collapsed lane, high-risk work and every parity verdict need a human reviewer standing in for the independent judge. Do not quietly proceed as though the judge exists.
|
|
|
|
## Cost
|
|
|
|
Parallel subagents multiply spend close to linearly — five in parallel costs roughly five times one. That is worth it for genuinely independent work with separate owners, and pure waste for work that a single agent would have done in sequence anyway. Parallelize because ownership is disjoint, never because it looks faster.
|