o3 and o4-mini made routing harder to dodge

o3 and o4-mini made model routing more honest because both routes could reason.

The choice was no longer simply small model for easy text and large model for serious work. A smaller reasoning model could own bounded tasks while the stronger route handled ambiguity and expensive failure.

A route table is more useful than model preference:

routes:
  routine_summary:
    model: o4-mini
    reason: low-risk summarization with bounded context
    escalation: o3_on_low_confidence

  code_repair_plan:
    model: o3
    reason: multi-file reasoning with expensive failure mode

  support_triage:
    model: o4-mini
    reason: fast classification and draft routing
    escalation: human_for_billing_or_policy

The exact names will change. The task tier records the expected quality, latency, cost, and failure consequence.

Measure cost after retries. A cheaper first pass may still be worthwhile if escalation is rare. It may be false savings if most failures go to the stronger route anyway. Track first-pass success, retry and escalation rates, human correction, p95 latency, refusal rate, cost per accepted output, and failure severity.

Latency belongs in the product decision. A slow plan may be acceptable in the background and wrong for autocomplete. A coding agent may use the strong route for diagnosis and a faster route for small edits.

The router also needs escalation signals: low confidence, invalid schema, failed tests, missing evidence, policy-sensitive content, user correction, source contradiction, and high ambiguity.

Evaluate routes, not isolated models. The route includes model, prompt, context builder, verifier, and fallback. The useful question is which route produces an accepted result for the task at the cost and latency the product can support.