[Bug]: Reasoning effort selector missing for built-in GPT-6.1 Sol on managed ChatGPT provider; Astra works

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

Not sure

Steps to reproduce

Open T3 Code desktop with an authenticated managed ChatGPT connection (the local provider is named ChatGPT - Personal, driver codex).
Select the built-in gpt-6.1-sol model in a normal thread and look for the reasoning-effort control.
Switch to gpt-6-astra using the same provider and compare the available controls.

On this installation, the reasoning-effort selector is absent for Sol 6.1 and present for Astra. The user directly confirmed the Astra control appears. Claude models also show effort controls.

Expected behavior

Models supporting configurable reasoning effort should expose their supported options consistently. If a model or managed ChatGPT connection intentionally does not support this setting, please clarify that limitation rather than leaving it indistinguishable from missing capability metadata.

This report does not assume Sol 6.1 supports every effort value offered by Astra.

Actual behavior

gpt-6.1-sol is available and usable, but its reasoning-effort selector is missing. The same provider exposes the selector for gpt-6-astra.

Read-only inspection of T3's provider snapshot/cache shows capabilities: null for both gpt-6.1-sol and gpt-6.1-terra, whereas Astra and several other GPT models have a reasoningEffort option descriptor. Both affected entries have isCustom: false.

Sol 6.1 and Astra were compared in the UI by the user; Terra's missing capability metadata was observed in the cache only, not independently verified in the UI.

Impact

Minor bug or occasional failure

The user can continue working, but cannot choose reasoning effort for the affected selected model through the UI.

Version or commit

T3 Code desktop 0.1.3, installed from the official Linux amd64 .deb. T3-managed Codex CLI 0.156.1.

Environment

Ubuntu 26.04.1 LTS, KDE Plasma, Wayland, amd64.
Desktop app with its local server.
Managed ChatGPT subscription-sharing authentication; provider authenticated and ready.
Affected UI model: gpt-6.1-sol.
Same-provider working control: gpt-6-astra.
Observed on October 29, 2026, local time (Asia/Kolkata).

Logs or stack traces

No crash or stack trace is involved. The following is a sanitized projection of relevant fields from ~/.t3/caches/<managed-codex-provider-id>.json; account identity, provider UUIDs, tokens, and unrelated data are omitted:

{
  "version": "0.156.1",
  "status": "ready",
  "checkedAt": "2026-10-28T22:31:25.280Z",
  "models": [
    {
      "slug": "gpt-6.1-sol",
      "isCustom": false,
      "capabilities": null
    },
    {
      "slug": "gpt-6.1-terra",
      "isCustom": false,
      "capabilities": null
    },
    {
      "slug": "gpt-6-astra",
      "isCustom": false,
      "capabilities": {
        "optionDescriptors": [
          {
            "id": "reasoningEffort",
            "label": "Reasoning",
            "type": "select",
            "options": [
              { "id": "low", "label": "Low" },
              { "id": "medium", "label": "Medium", "isDefault": true },
              { "id": "high", "label": "High" },
              { "id": "xhigh", "label": "Extra High" },
              { "id": "max", "label": "Max" },
              { "id": "ultra", "label": "Ultra" }
            ],
            "currentValue": "medium"
          }
        ]
      }
    }
  ]
}

T3's orchestrator_capabilities tool independently reports no options for the two 6.1 entries, while advertising reasoningEffort options for Astra. This corroborates the provider-level metadata difference; it is not just an assumption based on the UI.

The local model manifest has manifest.updatedAt: "2026-10-28T08:10:39Z". Its gpt-6.1-sol entry marks the model current and specifies Codex minVersion: "0.153.0"; the installed managed CLI is newer than that minimum. This does not establish a specific root cause or guarantee effort support.

Investigation limits: no raw upstream model-catalog response was captured, no same-account native Codex CLI comparison was performed, and no provider settings, caches, or effort defaults were modified. It is not yet established whether the null capabilities originate upstream, in Codex discovery, or in T3's metadata merge.

Screenshots, recordings, or supporting files

No screenshot attached. UI observations are user-confirmed; sanitized provider evidence is included above.

Workaround

Select gpt-6-astra on the same provider: the user confirmed its effort selector appears. This changes the model, so it does not restore effort selection for Sol 6.1 itself.

Related: #14321 concerns missing models with managed ChatGPT authentication and mentions missing controls in a custom-model workaround. This report concerns built-in models that are already listed and usable, but have null capability metadata. No custom-model workaround was used here.

Isolated validation of the existing fix

I tested #17865 at 06d30ee796f3285e9096e977194ceb3b81ca80c3 in a separate scratch checkout on October 29, 2026, using Node 26.13.0, pnpm 12.14.0, and the repository's Vite+/Vitest setup. Production source files were unchanged on the final passing run; I only extended existing tests locally.

Red/green evidence

For the red check, I replaced only CodexChatGptModels.ts with its contents from main at 58e60bf5e808fc226d9b769d66d1ea9fec014d23, keeping the PR's other files and the same test fixtures. Three catalog regressions failed and the two existing entitlement/error cases passed. The mapper returned no reasoning descriptor for fixtures named gpt-6.1-sol, gpt-6.1-terra, and an arbitrary future-model slug.
Restoring the exact PR mapper made all 10 catalog/provider tests pass. The added fixture rows expose the supplied reasoning options for all three slugs, preserve the supplied default, and retain an explicit xhigh through the shared option-normalization functions. Existing cases also cover preserving native reasoning/other options and isolating malformed optional metadata.
The 10 shared model tests pass.
I extended the existing native collaboration-mode parameter test with xhigh and the two affected slugs: 3 parameterized tests pass, exercising 54 combinations of model, effort, interaction mode, and T3 MCP presence. Both params.effort and params.collaborationMode.settings.reasoning_effort retain the requested value. The other 83 adapter tests were intentionally excluded by the name filter; this is not a claim that the entire adapter suite passed.
Server-package typecheck, formatting of the two locally extended test files, and git diff --check pass.

Commands, from apps/server unless stated otherwise:

vp test run src/provider/CodexChatGptModels.test.ts src/provider/CodexProvider.test.ts
vp test run src/orchestration-v2/Adapters/CodexAdapterV2.test.ts -t 'selects native collaboration modes without prompt overrides'
vp run typecheck
# From packages/shared:
vp test run src/model.test.ts

Important limits: catalog responses were mocked. The extra Sol/Terra/future-model rows deliberately supplied low, medium, high, xhigh, max, and ultra, with high as a fixture default and no per-level descriptions. This verifies data-driven mapping, not which values the real account currently advertises or supports. The protocol check constructs turn-start parameters; it does not send a live model request or prove backend enforcement.

Tests ran with an empty inherited environment and scratch HOME/XDG/temp directories. I did not start or patch the installed T3 app, access saved provider credentials, change its configuration/cache/database, or run browser/Electron/mobile verification. No live authenticated catalog capture or full app build was performed, so why the native catalog omits the models is still unconfirmed.

This supports linking #17865 to this report: it fills missing reasoning controls using account-catalog metadata rather than hard-coding Sol/Terra options. I have not opened another competing PR. #26733 also references this issue, but I did not execute that PR's implementation in this validation.

Prepared with Codex (GPT-6.1 Sol) in T3 Code.

Root cause: the T3-managed Codex (pinned to 0.156.1) does not receive the GPT-6.1 models in its native catalog

Reproduced on T3 Code desktop 0.1.5 (Linux x64, local server, managed ChatGPT provider, Codex 0.156.1): same symptom, with capabilities: null for gpt-6.1-sol and gpt-6.1-terra.

Why the capabilities are null: Codex's own models_cache.json in the managed shadow home (client_version: 0.156.1) lists gpt-6-astra, gpt-6-sol, gpt-6-luna, gpt-5.6-*… but no gpt-6.1-* entries. So model/list never returns them. They only show up through the ChatGPT account catalog merge in CodexChatGptModels.ts, which falls back to capabilities: null when there is no native match.

On the same machine and account, a models_cache.json written by Codex 0.165.0 contains gpt-6.1-sol and gpt-6.1-terra with supported_reasoning_levels low/medium/high/xhigh/max/ultra (default low) and a priority ("Fast") service tier.

Workaround (confirmed): install @openai/[email protected], enable a Codex provider instance in existing setup mode that uses it, and disable the managed one. The provider cache then shows both 6.1 models with full reasoningEffort (low → ultra) and serviceTier descriptors, and the selector appears in the composer. T3 sets the same originator override in both modes, so the catalog appears to be gated by Codex client version, not by originator.

Suggestion: bump the pinned managed Codex release in CodexInstallation.ts (still 0.156.1 on main and in nightly 0.1.6-nightly.20261030.3904). The model manifest already recommends >=0.159.0. #17865 would still be a good fallback for account-only models, but with a newer managed Codex the native catalog should already provide these capabilities.

Investigated via t3 triage with Claude Code (Claude Opus 5.5).

Confirmed on Windows 11 x64 (10.0.26300), T3 Code Desktop 0.1.5 with its local server, managed Codex 0.156.1.

The user reports that reasoning controls work for GPT-6 Astra in the permissions menu but are unavailable for the GPT-6.1 models.

Read-only evidence:

The provider is ready and uses managed setup mode.
Both gpt-6.1-sol and gpt-6.1-terra have isCustom: false and capabilities: null in the provider cache.
The running server's orchestrator_capabilities independently exposes both 6.1 models without options.
Astra has a reasoningEffort descriptor with low, medium, high, xhigh, max and ultra.
The inspected Codex 0.156.1 models_cache.json lists Astra and older models but no gpt-6.1 entries.

In v0.1.5, CodexChatGptModels.ts reads only slug/display_name/visibility from the account catalog and obtains capabilities exclusively from a matching native model, falling back to null. This explains the observed metadata gap. No raw authenticated catalog response was captured.

This adds Windows 0.1.5 evidence to #26707. No T3 settings, provider binaries, caches, database, or application source were changed. The newer external Codex workaround has not been tested on this machine.

Update: the Windows selectors are now restored, and the MacBook comparison isolates why the same T3 version behaved differently.

Both machines run T3 Code 0.1.5. Windows used managed Codex 0.156.1; its 6.1 entries had null capabilities. On the MacBook, process metadata identifies T3's actual child executable as the Codex desktop app's bundled binary, version 0.165.0-alpha.1.2. That Mac provider follows the existing/default-binary path. Its native catalog includes both 6.1 models, and its live T3 provider advertises their reasoning options.

On Windows, I installed the official Codex 0.166.0 Windows x64 package alongside 0.156.1, verified the published archive hash, and switched the managed installation's active-version pointer. The existing managed provider and authentication were retained. T3 refreshed without restarting: its provider now reports 0.166.0 and reasoningEffort values low/medium/high/xhigh/max/ultra, default low, for both gpt-6.1-sol and gpt-6.1-terra. The user then confirmed that the reasoning selector appears and works.

This establishes runtime/catalog provenance as the machine difference, with a T3 fallback-mapping defect amplifying it. It is not a confirmed macOS-specific failure: the inspected MacBook currently works. Existing Linux reports in this issue describe the same managed-runtime symptom.

The upgrade is a local mitigation. A durable fix must retain advertised account-catalog reasoning metadata when the native catalog lacks a model or a reasoning descriptor, while preserving native reasoning and unrelated capabilities. It should not hard-code the 6.1 slugs or assume Astra's effort levels apply to every model.

No live inference was used as a test of effort enforcement. The shared native models_cache.json can be overwritten by an older still-running Codex process, so the post-upgrade evidence is the refreshed T3 provider and live capability response, plus the user's UI confirmation.

Note

🤖 Claude Opus 5.5 responding on behalf of Theo

Closing: this is covered by #27931 and #27891, which landed. Reopen if an important part is still missing.

Navigation Menu

Repository navigation

[Bug]: Reasoning effort selector missing for built-in GPT-6.1 Sol on managed ChatGPT provider; Astra works #26707

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Isolated validation of the existing fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Reasoning effort selector missing for built-in GPT-6.1 Sol on managed ChatGPT provider; Astra works #26707

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

edwardEsmerson commented on Oct 29, 2026

Isolated validation of the existing fix

pablitar commented on Oct 30, 2026

chai-in commented on Oct 30, 2026

chai-in commented on Oct 30, 2026

t3dotgg commented on Oct 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions