Unify reasoning selection for providers with separate model variants

[NikitaMGrimm]

Note

🤖 GPT-6.1 Sol writing on behalf of NikitaMGrimm

Problem

Some providers encode reasoning effort in separate model IDs. Antigravity, for example, lists Gemini 3.8 Flash (High), Gemini 3.8 Flash (Medium), and Gemini 3.8 Flash (Low) as three models.

To change only the reasoning level, users have to choose another model entry. This makes the catalog longer and gives reasoning selection a different workflow from providers that expose it as a model option.

Current mobile picker

The screenshot shows the three Antigravity entries. It was supplied by the user; the app version was not recorded.

Proposed behavior

Show one Gemini 3.8 Flash entry with a Reasoning selector offering the variants available from that provider: Low, Medium, or High. Choosing a level would select the corresponding native model ID.

Use the same interaction across web, desktop, and mobile. Preserve existing saved selections and favorites, and only group variants when their relationship is known. Models without a known effort mapping should keep their existing entries.

Current behavior and direction

Current upstream code explicitly preserves Antigravity's native model IDs, including thinking levels, and exposes no separate model options. This proposal changes how those choices are presented while retaining the provider's IDs.

Related: #9478 and #9511 concern missing or stale Antigravity model choices, rather than grouping reasoning variants.

Would maintainers support this direction, starting with Antigravity's known variants?

[raiomarco]

Following the direction in #20090, I would like to add the speed counterpart to this proposal.

In T3 Code Nightly 0.0.46-nightly.20261015.3171, Grok exposes grok-4.7 and grok-4.7-build-fast as separate model entries. Both advertise reasoning-effort choices. A consistent presentation could be:

• Model: Grok 4.7
• Reasoning effort: the levels advertised by that provider instance
• Speed: Standard / Fast

Choosing Fast would map to the native grok-4.7-build-fast ID while preserving the selected effort. Returning to Standard would map to grok-4.7. Speed and effort should remain independently selectable where the provider supports that combination.

Together with the effort-variant grouping proposed here, this would give users consistent Model / Reasoning effort / Speed controls across providers. Codex already represents reasoning effort and its Standard / Fast / Ultrafast service tiers separately; the controls should show only the options actually supported by each provider and model.

Please preserve saved selections, favorites, and existing conversations, keep the effective native variant identifiable, and retain current speed defaults. Any provider-reported usage or cost tradeoff should be visible before selecting a faster tier. This is a request to normalize presentation and selection mapping while retaining the provider's native IDs and behavior.

[Mchicao]

up 👀some of us poor we gotta just use gemini even if we dont want to t.t

[fagnersales]

That makes a lot of sense, up!