When using the OpenCode provider in T3 Code, I can select the model from the composer footer, but there is no clear or obvious way in the main UI to choose the model's reasoning level/variant.
This is confusing because the underlying providers do support reasoning controls:
- GitHub Copilot CLI exposes reasoning effort for GPT-5.4 as
Low, Medium, High
- OpenCode CLI exposes reasoning/variant levels up to
xhigh
In T3 Code, the current OpenCode UI makes model selection visible, but reasoning selection is effectively hidden or missing from the normal model-selection flow.
Current behavior
- The footer model picker only exposes provider/model selection
- OpenCode reasoning is represented internally as
variant
- OpenCode capabilities already appear to be available from the runtime layer, but they are not surfaced clearly enough in the primary UI
Expected behavior
Expose OpenCode reasoning levels in the user-facing composer controls, ideally alongside model selection or as another first-class visible control.
Examples:
If OpenCode uses the term variant internally, that can still map to a user-facing “Reasoning” control.
Why this matters
- Reasoning depth is a major quality/speed tradeoff, not an advanced hidden setting
- Users coming from Copilot CLI or OpenCode CLI expect to configure it explicitly
- T3 Code already exposes model choice, so reasoning level feels like a missing part of the same control surface
- OpenCode’s higher ceiling (
xhigh) is especially useful and should be discoverable
Repo notes
There already seems to be backend/UI plumbing for this:
apps/server/src/provider/opencodeRuntime.ts builds variantOptionspackages/contracts/src/model.ts stores OpenCode options as variantapps/web/src/components/chat/TraitsPicker.tsx can render OpenCode Variantapps/web/src/components/chat/ProviderModelPicker.tsx only renders provider/model selection
So this looks less like a capability gap and more like a discoverability/UI exposure gap.
Suggested acceptance criteria
- OpenCode reasoning/variant is visible in the composer UI without requiring hidden or discoverability-poor navigation
- Users can switch reasoning level before sending a message
- The selected reasoning level is shown in the footer/composer state
xhigh is exposed when supported by the selected OpenCode model
Repro
- Open T3 Code
- Select
OpenCode
- Pick a model
- Observe that model selection is available, but reasoning level is not clearly exposed in the main UI
- Compare with Copilot CLI/OpenCode CLI, where reasoning selection is explicit
When using the OpenCode provider in T3 Code, I can select the model from the composer footer, but there is no clear or obvious way in the main UI to choose the model's reasoning level/variant.
This is confusing because the underlying providers do support reasoning controls:
Low,Medium,HighxhighIn T3 Code, the current OpenCode UI makes model selection visible, but reasoning selection is effectively hidden or missing from the normal model-selection flow.
Current behavior
variantExpected behavior
Expose OpenCode reasoning levels in the user-facing composer controls, ideally alongside model selection or as another first-class visible control.
Examples:
lowmediumhighxhighIf OpenCode uses the term
variantinternally, that can still map to a user-facing “Reasoning” control.Why this matters
xhigh) is especially useful and should be discoverableRepo notes
There already seems to be backend/UI plumbing for this:
apps/server/src/provider/opencodeRuntime.tsbuildsvariantOptionspackages/contracts/src/model.tsstores OpenCode options asvariantapps/web/src/components/chat/TraitsPicker.tsxcan render OpenCodeVariantapps/web/src/components/chat/ProviderModelPicker.tsxonly renders provider/model selectionSo this looks less like a capability gap and more like a discoverability/UI exposure gap.
Suggested acceptance criteria
xhighis exposed when supported by the selected OpenCode modelRepro
OpenCode