[FEATURE]: Expose active reasoning variant to agents, not only to the TUI #55375

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

OpenCode allows users to select reasoning variants such as High or Max, but the selected and effective reasoning configuration does not appear to be reliably accessible to the agent itself.

The model identifier alone is insufficient to determine the active reasoning variant.

This can lead to unnecessary interruptions, incorrect assumptions about the user's configuration, and uncertainty about which reasoning settings were used during a session.

I experienced this issue while running a technical code audit.

Steps to reproduce

Environment:

• OpenCode version: 1.19.0
• Operating system: Windows 11
• Provider: OpenAI
• Interface: TUI
• Agent: PLAN
• Selected reasoning variant: Max
• Model identifier reported by the agent: openai/gpt-6.1-sol

Steps:

1. Start an OpenCode session using the PLAN agent.
2. Select the Max reasoning variant in the TUI.
3. Submit a technical audit prompt explicitly requesting GPT-6 Max.
4. The agent identifies itself as openai/gpt-6.1-sol.
5. Instead of proceeding with the audit, the agent interrupts execution and asks whether to switch to GPT-6 Max or continue with the current model.

The Max variant had already been selected in the TUI.

Screenshot of the actual behavior

The following screenshot shows the original clarification dialog displayed by OpenCode.

English translation of the screenshot

The original dialog is in Spanish. Its English translation is:

"You requested the audit to be performed with GPT-6 Max, but this session identifies itself as openai/gpt-6.1-sol. How would you like to proceed?"

Option 1 — Use GPT-6 Max

"Stop the audit here so you can select the requested model or profile in OpenCode and resume the audit in that session."

Option 2 — Continue with the current model

"Authorize the audit with openai/gpt-6.1-sol, maintaining all PLAN restrictions and read-only access."

Option 3 — Type your own answer

The problem is that the agent appears to infer a possible mismatch from the model identifier, even though the Max variant was explicitly selected.

The identifier openai/gpt-6.1-sol does not, by itself, establish whether Max reasoning is active.

Expected behavior

The agent should have a reliable way to determine its current execution configuration without inferring the reasoning variant from the model identifier.

Ideally, the available information should distinguish:

• Provider and model identifier.
• Active agent (PLAN, BUILD, etc.).
• User-selected reasoning variant (High, Max, etc.).
• Effective reasoning configuration resolved by OpenCode.
• Provider-specific reasoning parameters actually included in the request, when verifiable.

The selected variant and effective provider parameters should not be treated as necessarily identical.

If the effective configuration cannot be verified, the system should report that uncertainty explicitly rather than making assumptions based on the model name.

An agent should not unnecessarily interrupt a task simply because the model identifier does not contain the variant name.

Actual behavior

The agent sees openai/gpt-6.1-sol and questions whether the requested Max variant is being used.

This produces an unnecessary clarification dialog, despite the user having selected Max in the interface.

Important clarification:

I am not claiming that OpenCode sent an incorrect reasoning configuration to the provider.

There is no evidence from this incident that Max was ignored or that a different reasoning level was actually used.

The observed problem is that the agent did not have, or did not use, a reliable way to verify the selected and effective reasoning configuration.

This is primarily an observability and session-introspection issue.

Proposed enhancement

Expose authoritative, read-only information about the active session configuration to agents.

This could be implemented through:

• A built-in session information tool.
• Structured runtime metadata accessible to the agent.
• Another documented introspection mechanism.

For example, the information might conceptually include:

{
  "agent": "plan",
  "provider": "openai",
  "model": "gpt-6.1-sol",
  "selectedVariant": "max",
  "effectiveReasoningEffort": "provider-specific-value"
}

This is only an illustrative example, not a proposed API contract.

The actual structure and values should reflect OpenCode's internal configuration resolution and the settings supported by the provider.

The feature should distinguish between:

1. What the user selected.
2. What OpenCode resolved internally.
3. What was actually sent to the provider, when that can be verified.

If any of these values cannot be determined, they should be reported as unknown rather than inferred.

Session diagnostics

It would also be useful to expose this information through session diagnostics or exports.

For example, a session could clearly indicate:

PLAN · OpenAI GPT-6.1 Sol · Max

This should represent the selected variant, with the effective provider configuration available separately when appropriate.

Such information would improve troubleshooting and reproducibility.

Acceptance criteria

1. Agents can reliably obtain the active reasoning variant without inferring it from the model identifier.
2. User-selected variants and effective provider settings can be distinguished.
3. Switching between PLAN and BUILD updates the reported configuration correctly.
4. Switching between High and Max updates the reported configuration correctly, even when the model identifier remains unchanged.
5. Starting or resuming a session preserves accurate configuration information.
6. Unsupported, ignored, or unavailable reasoning variants are not incorrectly reported as successfully applied.
7. Session diagnostics or exports allow users to inspect the relevant configuration.
8. Automated tests cover multiple reasoning variants sharing the same model identifier.

Related issues

• [FEATURE]: Show current variant in TUI status bar #38015 — Show current variant in TUI status bar.
• OpenAI reasoningEffort=xhigh is not visible in TUI or export #18634 — OpenAI reasoningEffort is not visible in TUI or export.
• Same model cannot use different reasoningEffort values across agents #39524 — Same model cannot use different reasoningEffort values across agents.

These requests are related, but they do not necessarily address the exact same problem.

The key difference is that this feature request focuses specifically on agent-accessible runtime introspection, rather than only displaying the selected variant in the user interface.

The agent itself should be able to determine which configuration is active, without relying on assumptions about the model name.

Why this matters

Users performing technical audits, software development, debugging, or other complex tasks may deliberately select a specific reasoning variant.

When an agent cannot reliably identify that configuration, it may unnecessarily interrupt the workflow or provide misleading information about the current execution environment.

Exposing authoritative session metadata would improve:

• Confidence in the selected configuration.
• Reproducibility of technical work.
• Troubleshooting and diagnostics.
• Transparency between user-selected settings and effective provider parameters.
• Overall reliability of agent-driven workflows.

This would be particularly valuable when multiple reasoning variants share the same underlying model identifier.

Thank you for considering this improvement.