feature: route by task class — use a cheaper model when the prompt does not need an expensive one

Feature Description

Not every request needs the frontier model. Summarisation, compaction, commit-message
generation, title generation and simple classification are routinely served by a much cheaper
model at indistinguishable quality — but the agent sends them all to whatever model the user
selected, so the user pays top rate for the cheap work.

Cortex sees the request body, so it can classify the request and route accordingly.

Proposed Solution

• Classify each request into a task class from signals already on the wire: system prompt
  content, max_tokens, presence and size of tool definitions, prompt length,
  agent-declared metadata where present
• Start with the classes that are safe and mechanically detectable — agents already label
  some of their own auxiliary calls (compaction, titling) distinctly. Prefer those explicit
  markers over heuristics on prompt text
• A user-editable class → model mapping; ship a conservative default and let the user widen it
• Never downgrade the user's main turn without opt-in. The default should cover only
  agent-internal auxiliary calls
• Report realised savings per class, so the feature is falsifiable in the same way #952
  requires of tool pruning
• An escape hatch: if the cheap model returns an error or an obviously degenerate response,
  retry once on the original model

Risks and open questions

• Heuristic misclassification is a silent quality regression. "Looks like a summarisation
  task" is not the same as "is one". This is the argument for leaning on explicit agent-side
  markers first and treating text heuristics as a later, opt-in tier
• Downgrading a request can break prompt-cache reuse; the saving may be smaller than the
  headline price difference suggests
• Which classes the team is actually willing to route by default needs deciding by measurement,
  not assertion — see #1021

Additional Context

Team brainstorming, September 2026 — cc @galmasi. Post-v0.9.0. Builds on the model and provider
switching mechanism in #1019. The evidence for which classes are safe to downgrade should come
from #1021 rather than from intuition.

Part of the post-v0.9.0 brainstorm backlog under #962.

Start by reading the model and provider switching mechanism described in #1019, then review #1021 for evidence about safe task classes and #952 for the savings-reporting precedent. The issue is ready when the classification, opt-in routing policy, measurement, and fallback behavior have an agreed implementation plan.