What problem does it solve? When an orchestrator hands work to an implementation specialist, it needs a consistent rule for deciding whether that single dispatch should run on a cheaper or stronger model. Without one shared rule, teams either overpay for trivial changes or under-power re-passes that just failed review. ## Core Features & Use Cases - Per-dispatch classification: Emits light or heavy plus a one-line reason naming the criterion that fired, so every dispatch site runs the same auditable rule. - Concrete thresholds: Classifies heavy when a dispatch touches more than 3 files, spans repos, changes a shared contract with multiple callers, works around a placeholder seam, or reopens a design decision on a fix pass. - Three invariants: Enforces raise-on-suspicion asymmetry, a ratchet so re-dispatches never drop below the last tier, and the agent's pinned model: as a floor. - Tier alias mapping: Gives the dispatching agent a table mapping installed model ids to tier aliases (sonnet, opus, haiku, fable), with unmappable ids meaning no override. - Use Case: After a reviewer returns REQUEST CHANGES with a design-level finding, the orchestrator re-classifies the re-pass as heavy and escalates the model for that run only, instead of reusing the original light weight. ## Quick Start Ask the agent to classify the weight of the upcoming implementation dispatch and emit light or heavy with the criterion that fired before dispatching the specialist.
