Consistent model, reasoning effort, and speed controls across providers

[raiomarco]

Proposal

Use a consistent set of model controls across providers: Model, Reasoning effort, and Speed, showing only the choices supported by the selected provider and model.

Some providers encode effort or speed in separate model IDs. T3 could present those as related choices while preserving the exact native ID sent to the provider.

Observed behavior

In T3 Code Nightly 0.0.46-nightly.20261015.3171:

• Antigravity: Gemini 4 Argon appears as separate Low, Medium, and High model entries (gemini-4-argon-low, gemini-4-argon-medium, gemini-4-argon-high). Those entries expose no separate effort option in T3.
• Grok: Grok 4.7 and Grok 4.7 Fast appear as separate models (grok-4.7 and grok-4.7-build-fast), each with its own reasoning-effort choices.
• Codex: reasoning effort and Standard / Fast / Ultrafast service tiers are already represented as separate options.

Switching providers therefore changes where the user finds the same kind of choice. Effort can be part of a model name in one provider and a separate control in another; speed has a similar inconsistency.

Suggested interaction

For example:

• Gemini 4 Argon → Effort: Low / Medium / High.
• Grok 4.7 → Effort: the advertised levels; Speed: Standard / Fast.
• Codex models → retain their advertised effort and service-tier options.

These could live in a shared picker or separate controls; the request is consistent meaning and placement rather than a particular visual design. Effort and speed should remain independently selectable where supported: selecting Fast should not implicitly reduce effort.

Behavior to preserve

• Offer only combinations actually advertised or verified for that provider instance. Do not synthesize unsupported levels or a universal Fast mode.
• Map the visible selection back to the exact native model ID and options. The displayed selection must match what runs.
• Preserve existing conversations, saved selections, favorites, and custom models. Keep an explicit way to identify the effective native variant.
• Keep speed defaults unchanged and make any provider-reported usage/cost tradeoff visible before enabling a faster tier.
• Treat this as presentation and selection mapping; it should not require changing authentication, shell configuration, or the provider's underlying reasoning and billing behavior.

Related work

• #9256 — unified composer model picker with an effort slider: related presentation work based on existing option descriptors. This proposal additionally covers grouping effort/speed variants that arrive as separate native model IDs.
• Discussion #18013 — separate OpenCode reasoning and agent controls: a related request for clearer controls and cross-provider consistency.
• Discussion #6735 — generic trait controls across providers: related direction concerning reasoning effort, fast mode, and variants.

Would this normalization fit T3's intended model-picker design? The smallest useful starting point could be the Antigravity effort variants and Grok 4.7 Standard / Fast pairing above.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed write-up. The core of this, showing provider effort variants like Antigravity's Low/Medium/High model IDs as one model with a separate effort selector while still sending the native ID, is already proposed in #17247. Closing this as a duplicate so the conversation stays in one place. Please add the Speed half (Grok 4.7 vs Grok 4.7 Fast as a Standard/Fast pairing) as a comment there.