FIELD NOTE / INSTAGRAM
A router should know when to stay out.
The complete written thought and the evidence behind it. The video edition will follow its public release.
The written argument is here.
This approved Instagram edition is on the journal now. Its video player and original platform link will appear after each public release is verified.
A router should know when to stay out.
Video caption
A router should know when to stay out.
A restarted task may lose its expected capabilities.
Pin, resume, and fresh available route.
Select only when intent is absent and the route is live.
#EricFieldNotes
Full written post / accessibility read
Dynamic model selection sounds useful until it changes a provider the engineer explicitly pinned, or reroutes a session already underway. The Avid Jev build limits automatic choice to fresh unpinned tasks. That boundary is more important than a clever ranking.
Imagine a resumed coding session that depends on a provider-specific tool. An eager router selects a cheaper model on the next turn. The engineer now debugs a capability change they never requested. A model selector has crossed from optimization into changing user intent.
Make tests for an explicit user route, a resumed session and a new unpinned task. Only the third reaches the selector. Then withdraw the chosen provider before dispatch and require a visible fallback receipt. This probes the real seam rather than asking the model whether it understands the rule.
Apply automatic choice to fresh unpinned work, recheck provider availability at dispatch, and record fallback. Do this because a router should optimize within the engineer's constraints, not silently rewrite them.
#EricFieldNotes
Four-beat scene transcript
1. A router should know when to stay out.
Dynamic model selection sounds useful until it changes a provider the engineer explicitly pinned, or reroutes a session already underway. The Avid Jev build limits automatic choice to fresh unpinned tasks. That boundary is more important than a clever ranking.
Visual: Automatic selection can override a deliberate choice.
2. The user pays for a silent override.
Imagine a resumed coding session that depends on a provider-specific tool. An eager router selects a cheaper model on the next turn. The engineer now debugs a capability change they never requested. A model selector has crossed from optimization into changing user intent.
Visual: A restarted task may lose its expected capabilities.
3. Replay three eligibility cases.
Make tests for an explicit user route, a resumed session and a new unpinned task. Only the third reaches the selector. Then withdraw the chosen provider before dispatch and require a visible fallback receipt. This probes the real seam rather than asking the model whether it understands the rule.
Visual: Pin, resume, and fresh available route.
4. Give automation a narrow window.
Apply automatic choice to fresh unpinned work, recheck provider availability at dispatch, and record fallback. Do this because a router should optimize within the engineer's constraints, not silently rewrite them.
Visual: Select only when intent is absent and the route is live.
Research and claim limits
The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.