Validate thinking level/variant against model capabilities before sending to API #17736

Description

When a model fallback occurs (e.g., Opus → Sonnet) or the UI variant selector is set to "max", the thinking level from the original config is passed unchanged to the Anthropic API. Non-Opus models reject level: "max" with a 400 error. OpenCode should validate the thinking level against the target model's supported levels before sending the API request.

Steps to Reproduce

1. In oh-my-opencode.jsonc, configure an agent with variant: "max" and primary model claude-opus-4-6, with claude-sonnet-4-6 in fallback_models
2. Or: select variant "max" via ctrl+t variants in the UI while a Sonnet model is active
3. Send any message

Expected Behavior

OpenCode clamps the thinking level to the highest supported level for the active model before sending to the API. For Sonnet/Haiku, max should be clamped to high.

Actual Behavior

OpenCode sends level: "max" to the Anthropic API for Sonnet, which returns:

Bad Request: {"error":{"message":"level \"max\" not supported, valid levels: low, medium, high","type":"invalid_request_error"}}

The agent enters an infinite error loop — every retry hits the same 400.

Additional Context

• Anthropic's max thinking level is Opus 4.6 only. Sonnet/Haiku support low, medium, high.
• Plugin hooks (chat.input, chat.params) cannot fix this — chat.params receives a cloned input (mutations don't propagate), and the UI-selected variant is applied by Go code after JS hooks run.
• The oh-my-openagent effort hook also cannot intercept this (see oh-my-openagent#2606 and its Codex review confirming the clone issue).
• Suggested fix: add per-model thinking_levels to model definitions and clamp in the provider layer before building the API request.

Environment

• OpenCode v1.2.26
• macOS (Darwin 25.3.0)
• oh-my-opencode 3.11.2 with variant: "max" agents + fallback chains
• Anthropic API via Quotio proxy