Summary

Add a pre-inference complexity triage step to the LLM routing pipeline. Before the main LLM call, a cheap/fast model evaluates input complexity and routes to the appropriate provider tier (Simple/Medium/Complex/Expert). Context window size is used as an additional routing signal.

Motivation

• Current routing is reactive (Cascade evaluates output quality) or keyword-based (TaskType classifies type, not complexity)
• Simple questions waste expensive model capacity; complex tasks suffer on cheap models
• Context window overflow is discovered at API call time (400 error), not at routing time
• No proactive complexity assessment exists in the pipeline

Research

Full analysis: .local/reports/complexity-routing-research.md

Phases

1. Core types + triage prompt (ComplexityTier, TriageRouter, structured output)
2. Config + bootstrap ([llm.complexity_routing] section, LlmRoutingStrategy::Triage)
3. Agent loop integration (triage in process_user_message_inner(), provider swap)
4. Triage + Cascade hybrid (composite routing, fallback on misclassification)
5. Metrics + TUI (triage latency, tier histogram, status bar indicator)
6. Documentation + testing (config reference, --init wizard, live testing)

Key design decisions

• Triage model: local Ollama (qwen3:1.7b) or API Haiku/Flash, configured as triage_provider in pool
• Provider swap via existing provider_override: Arc<RwLock<Option<AnyProvider>>> slot
• Insertion point: after prepare_context(), before process_response() in agent loop
• Context window hard override: auto-escalate if context > target provider's window
• Composable with Cascade for misclassification safety net

Config example

[llm.complexity_routing]
enabled = true
triage_provider = "fast"
bypass_single_provider = true

[llm.complexity_routing.tiers]
simple = "fast"
medium = "default"
complex = "smart"
expert = "expert"