Dynamic model selection: per-selection reasoning control + small-model reliability for task-session outputSchema

[allenzhou101]

Context

defineDynamic model selection (0.22) lets a session.started resolver downshift specific sessions to a cheaper model — e.g. high-volume ambient wake classifiers to haiku while the agent runs sonnet. We shipped exactly that in vercel/internal-agents' e0 agent and hit a production incident on first enablement (vercel/internal-agents#820 has the full writeup).

Problem 1: no per-selection reasoning control

The selection object accepts { model, modelContextWindowTokens, modelOptions } but reasoning is agent-level only. A downshifted session inherits the agent's reasoning ambiance (reasoning: "xhigh" in our case), which is exactly wrong for a cheap structured classifier — the cost win is the point, and effort hints claw it back. modelOptions can pin provider options (anthropic: { thinking: { type: "disabled" } }) but that's provider-specific and doesn't neutralize the provider-agnostic reasoning mapping.

Ask: accept reasoning in PublicAgentModelSelectionDefinition, same precedence semantics as the other fields.

Problem 2: task-session outputSchema is unreliable on small models

With mode: "task" + outputSchema, claude-haiku-4.5 failed the structured-output contract two different ways:

• Production: semantically-correct reasoning ending in prose — no structured result; run fails with "The agent could not produce a result matching the requested schema" (3/3).
• Local E2E (eve dev, same schema): schema-valid JSON with one field set to the literal string "structured-output" — the output machinery's name echoed into a domain field (4/4, identical with thinking enabled or pinned off).

The same model + schema through direct AI SDK generateObject works fine, so this is specific to how the harness requests/validates the structured result. Sonnet-5 under the identical harness path works reliably.

Ask: whatever the harness's structured-output mechanism is (result tool / format instruction), harden it for small models — or document a supported-models floor for outputSchema task runs.

Why it matters

Wake-classifier-style workloads (one cheap structured judgment per firehose event) are the textbook case for dynamic downshifting — it's the difference between haiku and sonnet-xhigh pricing on the highest-volume call in the system. Right now the safe answer is "don't downshift," which forfeits the feature's main use case.

[ZhYGuoL]

Confirmed on main. A defineDynamic selection object accepted { model, modelContextWindowTokens, modelOptions } but not reasoning. DYNAMIC_MODEL_SELECTION_KEYS at packages/eve/src/runtime/agent/resolve-model.ts:171 excluded reasoning, so validateDynamicModelSelection rejected it and the resolved session kept the agent-level reasoning.

Repro on main: normalizeDynamicRuntimeModelResult({ fallback: { id: "openai/gpt-5.5" }, result: { model: "openai/gpt-5.5-mini", reasoning: "low" } }) throws

Dynamic model resolver returned a selection with unknown key(s): reasoning. Expected { model, modelContextWindowTokens?, modelOptions? }.

at validateDynamicModelSelection (resolve-model.ts:178). Even with the key allowed, nothing carried the value to the model call: the turn reads session.agent.reasoning at packages/eve/src/harness/tool-loop.ts:849, and a dynamic selection only updates session.agent.modelReference.

Fix threads reasoning the same way modelContextWindowTokens/modelOptions already flow: onto the runtime model reference, validated against the same enum the agent-level field accepts, then applied at the precedence point so a per-selection value overrides the agent default and falls back to it when omitted.

PR: #769