[Bug]: Fast service-tier selector missing for GPT-6.1 Sol on managed Codex connection #30245

Before submitting

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

Area

apps/server; affects the apps/web composer model/options picker.

Summary

The managed Codex connection offers GPT-6.1 Sol and reasoning-effort choices, but its discovered model capabilities contain no serviceTier descriptor, leaving no Fast speed choice in T3's generated model options.

OpenAI's Codex speed documentation explicitly lists GPT-6.1 Sol as supporting Fast mode. The regular Codex CLI model cache on the same machine also advertises a Fast tier for Sol. This report concerns the missing selector/capability metadata, not a demonstrated failure of a Fast inference request.

Steps to reproduce

1. Use T3 Code with an enabled Codex provider configured with setupMode: "managed" and no custom model overrides.
2. Select the built-in gpt-6.1-sol model. The affected thread uses reasoningEffort: "xhigh" and the composer displays 6.1 Sol Extra High.
3. Open the composer's model/options control and inspect the available speed/service-tier choices.
4. Inspect ~/.t3/caches/codex.json: the Sol entry's only option descriptor is reasoningEffort; serviceTier is absent.
5. Compare the Sol entry in ~/.codex/models_cache.json, which advertises Fast as shown below.

Observed on an existing installation on November 3, 2026; a clean-install reproduction has not been performed.

Expected behavior

When Fast is available for the connected account/model, T3 should expose a Service Tier choice such as Standard / Fast in the model/options control and pass the selected tier to Codex.

If this connection mode cannot use Fast, T3 should explain that restriction rather than silently presenting no speed capability. This does not request a Fast badge while Standard is selected: the absence of a badge on the collapsed control is not, by itself, the bug.

Actual behavior

The current T3 model catalog for Sol contains reasoning-effort options only, with no service-tier selector to render. T3's available model-options inventory likewise reports only reasoningEffort for gpt-6.1-sol.

Impact

Minor bug or occasional failure.

Normal coding still works, but the user cannot select Sol's Fast mode through the T3 model/options control.

Version or commit

• Desktop-bundled t3 --version: t3 v0.1.6.
• Codex CLI: 0.164.0; T3's Codex discovery cache also reports 0.164.0.

Environment

• macOS 26.5.1, Apple Silicon (arm64).
• T3 Code desktop, managed Codex connection.
• Model: gpt-6.1-sol; thread reasoning effort: Extra High (xhigh).
• No custom model overrides; no custom Codex launch arguments or home-path overrides configured.

Logs or stack traces

No crash or stack trace is involved. These are sanitized projections of the local metadata; credentials, account identities, and unrelated configuration are omitted.

T3 discovery cache (~/.t3/caches/codex.json):

{
  "version": "0.164.0",
  "checkedAt": "2026-11-03T15:37:32.141Z",
  "models": [
    {
      "slug": "gpt-6.1-sol",
      "capabilities": {
        "optionDescriptors": [
          {
            "id": "reasoningEffort",
            "label": "Reasoning",
            "type": "select"
          }
        ]
      }
    }
  ]
}

The reasoning descriptor's individual choices are omitted above; the descriptor list itself contains only this one entry.

Regular Codex CLI model cache (~/.codex/models_cache.json):

{
  "slug": "gpt-6.1-sol",
  "additional_speed_tiers": ["fast"],
  "service_tiers": [
    { "id": "priority", "name": "Fast" }
  ]
}

Additional checks:

• codex features list reports fast_mode as stable and enabled.
• The top-level Codex configuration currently has service_tier = "default"; this is not a case of an inherited Priority request being mislabeled Standard.
• T3's provider configuration has setupMode: "managed", customModels: [], and no custom launch arguments.

Investigation scope / unresolved cause

The missing T3 capability descriptor is confirmed, but the precise upstream cause is not established. In particular, it has not been proven that managed mode intentionally disallows Fast, that T3 drops an advertised tier, or that Codex's app-server omits tier metadata in this connection mode. The regular CLI cache and managed connection have not been verified to use identical account/catalog contexts.

Please compare the managed connection's raw Codex model/list response with T3's resulting Sol capabilities, including serviceTiers / additionalSpeedTiers. An account-aware refresh or capability-mapping fix may be needed; this report does not recommend unconditionally exposing tiers without checking availability.

No account, provider mode, feature flag, or inference service tier was changed during this investigation, and no Fast inference request was used as a reproduction test.

Workaround

The documented standalone Codex CLI route is /fast. Switching T3 to its "Use existing CLI" connection mode has not been tested as a workaround for this report.

Related issues

• Outdated managed Codex runtime misses 6.1 Sol metadata and inflates startup context #27939: managed-runtime/model-metadata mismatch; concerns an older Codex runtime and missing Sol metadata/context behavior, rather than this specific missing speed descriptor.
• [Bug]: Reasoning effort selector missing for built-in GPT-6.1 Sol on managed ChatGPT provider; Astra works #26707: missing Sol reasoning selector on a managed provider, now closed; here reasoning choices are present and the missing capability is serviceTier.
• [Bug]: Codex Priority inherited from config is hidden as Standard #10576: inherited Priority hidden as Standard, now closed; the configuration here is explicitly Standard and the speed descriptor itself is absent.