Repository navigation
Cascade routing core: two-model user selection + escalate-on-gate-failure flow #1138
Closed as not planned
Description
Parent: #1134
Implement the routing core:
- Config schema:
route.mode: "cascade",route.primary: "<provider/model>",route.escalation: "<provider/model>",route.primary_attempts(default 1 interactive, 3 unattended). - Both models are USER-SELECTED (config file, CLI flags, and interactive picker); validate both are configured providers at session start; clear error if not.
- Flow: run task on primary → on verification-gate failure (see gate subtask) escalate: restart the task on the escalation model, carrying the task prompt and a compact failure summary (what the gate rejected), NOT the full failed transcript.
- Session UX: routing decisions surfaced in the TUI/status line ("primary: X", "escalated to Y: build failed"), never silent.
- Tests: config validation, escalate-on-failure, no-escalate-on-pass, unattended attempt count.
Activity
anandgupta42 commentedon Aug 24, 2026
Evidence adjustment from the prior-art research (see parent #1134):
primary_attemptsshould default to 2-3 execution-agreement-checked attempts in unattended mode (Query and Conquer: execution-guided self-consistency lifts small models +15.9pts, arxiv.org/html/2503.24364); n=1 stays the interactive default for latency. Config should not preclude a later pre-generation classifier layer (RouteLLM-style), but no learned router in v1 — undertrained routers test near-random (arxiv.org/abs/2406.18665).anandgupta42 commentedon Nov 5, 2026
Closing: after evaluating verifier-gated and cascade routing, we decided not to build an inferred per-request router. The direction is a strong default model with explicit, user-chosen modes. Reopen if routing is revisited.