fix(tui): preserve Codex capabilities and OpenCode fast variants

[danielxxomg]

Pre-flight Checklist

• I have searched existing issues and this is not a duplicate.
• I understand that PRs will be rejected if the linked issue does not have status:approved.

📝 Bug Description

Gentle AI's model-assignment flow does not preserve the full capability metadata advertised by the installed runtimes.

Codex CLI exposes model-specific reasoning levels, speed tiers, and service tiers, but the Codex Custom picker cannot reliably present all valid choices. OpenCode may expose an OpenAI -fast variant while the canonical catalog contains only the base model, causing the variant to be missing from the picker or configuration path.

This is a capability propagation bug. fast is a speed/service selection, not a reasoning effort. Pi is out of scope because it owns its runtime model selector.

🔄 Steps to Reproduce

1. Run codex debug models using Codex CLI 0.146.0.
2. Note that gpt-5.6-sol and gpt-5.6-terra advertise ultra, fast, and service-tier metadata, while gpt-5.6-luna advertises max, fast, and service-tier metadata but not ultra.
3. Open Gentle AI and navigate to Configure Models → Configure Codex models → Custom.
4. Select the GPT-5.6 models and compare the available choices with the runtime metadata.
5. Configure an OpenAI model through OpenCode and compare the canonical model ID with its available -fast variant.
6. Observe that model-specific capabilities, service tiers, or the -fast variant are missing or not persisted separately.

✅ Expected Behavior

The Custom picker should:

• Use runtime-discovered selectable model IDs while retaining a curated fallback.
• Show reasoning choices per model.
• Show max and ultra only when the runtime advertises them.
• Treat fast as a separate speed/service selection, not as a reasoning effort.
• Persist the selected Codex service_tier.
• Materialize an OpenCode -fast alias only when an explicit same-provider canonical model exists.
• Preserve existing configuration behavior when no service tier is selected.

❌ Actual Behavior

The picker and configuration flow use incomplete or static capability information.

Model-specific reasoning levels such as max and ultra are not reliably exposed according to the installed runtime metadata. The fast capability is not represented as a separate speed/service selection, and an OpenCode -fast variant may be unavailable when only the canonical model exists.

As a result, users cannot select or persist the complete set of capabilities advertised by Codex CLI and OpenCode.

🖥️ Environment

• Gentle AI: gga v2.10.1; installed gentle-ai binary reports 2.2.4
• Operating System: CachyOS Linux, x86_64, kernel 7.1.5-1-cachyos
• AI Agent / Client: Codex CLI 0.146.0 + OpenCode 1.18.8
• Affected Area: TUI (terminal UI)

💡 Logs / Error Output

Sanitized runtime capability evidence:

codex-cli 0.146.0
OpenCode 1.18.8

gpt-5.6-sol:
  multi_agent_version: v2
  reasoning: low, medium, high, xhigh, max, ultra
  additional_speed_tiers: ["fast"]
  service_tiers: ["priority"]

gpt-5.6-terra:
  multi_agent_version: v2
  reasoning: low, medium, high, xhigh, max, ultra
  additional_speed_tiers: ["fast"]
  service_tiers: ["priority"]

gpt-5.6-luna:
  multi_agent_version: v1
  reasoning: low, medium, high, xhigh, max
  additional_speed_tiers: ["fast"]
  service_tiers: ["priority"]

Additional Context

Related work:

• #1087 covers runtime Codex model-ID discovery.
• #2080 covers Codex model discovery, visibility, and API support.
• #2134 covers asynchronous Codex discovery in the TUI.
• #1648 and #1695 cover OpenCode provider-ID fallback for variants.
• #1066 and #1067 introduced the GPT-5.6 defaults but explicitly deferred max/ultra.

A local candidate was implemented with bounded runtime discovery, model-specific effort choices, separate speed/service-tier persistence, safe same-provider OpenCode fast aliases, and asynchronous TUI discovery.

Focused tests, go vet, gofmt, git diff --check, and go build ./cmd/gentle-ai pass. The full repository suite has one unrelated environment-sensitive failure in internal/cli:TestEngramPathGuidanceDefault, which expects a go/bin path fragment while the active Go installation uses a mise-managed path.

No PR will be opened until this issue receives status:approved.

[MzaGuille]

Additional backend contract evidence for OpenAI Fast mode

I verified the OpenAI, OpenCode, and Codex sides of this behavior to clarify what Gentle AI needs to preserve.

What OpenAI expects

Fast is a service tier, not a separate endpoint, model ID, or reasoning level. A direct OpenAI request keeps the canonical model and adds service_tier:

{
  "model": "gpt-5.6-sol",
  "service_tier": "fast",
  "reasoning": { "effort": "medium" }
}

OpenAI documents fast and the older priority value as equivalent. For GPT-5.6 and earlier, the effective tier is currently reported in the response as service_tier: "priority". That response field matters because documented ramp-rate handling can downgrade a request to default.

Official references:

• OpenAI Fast mode
• Responses API
• Chat Completions API
• OpenAI API pricing
• Codex speed configuration

What OpenCode exposes

gpt-5.6-sol-fast is an OpenCode catalog alias. It is not sent to OpenAI as a distinct model slug. OpenCode keeps api.id = "gpt-5.6-sol", derives the alias from the catalog mode, converts service_tier to serviceTier, and later serializes it back to the OpenAI request field.

For a selection displayed as GPT-5.6 Sol Fast · OpenAI · medium, the independent values are:

UI value	Backend meaning
GPT-5.6 Sol Fast	OpenCode display name and selectable alias
OpenAI	Provider
gpt-5.6-sol	Canonical OpenAI API model
Fast	serviceTier: "priority" in OpenCode 1.18.11
medium	reasoningEffort: "medium"

OpenCode implementation evidence:

• Mode alias construction and option conversion
• Fast alias behavior test
• Responses request serialization
• Current service-tier normalization

Codex follows the same separation and normalizes Fast to the request value priority:

• Codex Fast/priority normalization
• Codex request construction
• Codex catalog capability validation

Suggested Gentle AI contract

Gentle AI should treat the installed runtime catalog as the source of truth and preserve both the user-facing selection and its resolved meaning:

{
  "selection_id": "openai/gpt-5.6-sol-fast",
  "provider": "openai",
  "base_model": "gpt-5.6-sol",
  "service_tier": "priority",
  "reasoning_effort": "medium",
  "capability_source": "runtime-catalog"
}

This avoids three common sources of confusion:

1. Do not send the -fast suffix directly to OpenAI.
2. Do not model Fast as a reasoning variant.
3. Do not hard-code a permanent list of Fast IDs. Materialize only modes advertised by the installed OpenCode/Codex catalog.

Useful acceptance coverage would include alias-to-base resolution, independent Fast and reasoning persistence, configuration round-trip, catalog additions/removals, legacy compatibility, and checking the response's effective service_tier without silently claiming Fast after a downgrade.

Catalog presence alone does not prove entitlement for a particular account, and API-token pricing should remain separate from ChatGPT/Codex credit multipliers.

[MzaGuille]

Related UI/UX follow-up: #2301

That feature request covers viewport-aware model and agent selectors plus contextual role guidance. This issue remains focused on runtime capability discovery, OpenCode Fast aliases, service-tier persistence, and the separation between Fast and reasoning effort.

[JuanDaa]

Confirmed another occurrence on macOS arm64 with Gentle AI 2.2.4 and OpenCode 1.18.13.

Observed evidence:

• opencode models openai lists openai/gpt-5.6-terra-fast.
• The SDD model picker does not offer that ID.
• opencode models --refresh completed successfully (Models cache refreshed), but the refreshed OpenCode model cache still had no gpt-5.6-terra-fast entry.

Expected: an OpenCode model ID selectable through /models and supporting tools should be available to the Gentle AI SDD picker.

Actual: the fast variant remains absent from the picker after the refresh, so it cannot be assigned through the SDD profile flow.

Minimal reproduction:

1. Run opencode models openai and confirm gpt-5.6-terra-fast is listed.
2. Run opencode models --refresh.
3. Open Gentle AI's OpenCode SDD profile/model picker.
4. Observe that gpt-5.6-terra-fast is unavailable.

[ardelperal]

Hi! I'd like to take #2218, but I want to coordinate before branching to avoid duplicating work. A couple of things I noticed:

1. @Alan-TheGentleman — there's already a local branch fix/2218-preserve-cox-fast-variants in the repo (created 2026-08-05). It only exists locally (404 on origin), and its tip is at main HEAD with no fix(tui): preserve Codex capabilities and OpenCode fast variants #2218-specific commits. Is that branch reserved for your own work, or is it fair game for a contributor?

2. @danielxxomg — your issue body mentions a "local candidate" implementing bounded runtime discovery, model-specific effort choices, separate speed/service-tier persistence, safe same-provider OpenCode fast aliases, and async TUI discovery, all with passing tests. Do you plan to push it as a PR? If yes, I'll happily step aside and let you land it. If not (or if you'd prefer a collaborator), I'd like to coordinate rather than reinvent.

If neither of you is actively working on it, I'll proceed with a clean branch (fix/2218-tui-preserve-codex-capabilities-and-fast-variants) from origin/main and reference the @MzaGuille contract from the second comment for the runtime-catalog capability record.

Thanks!

[ardelperal]

Bumping this — posted 3 days ago, no responses from @Alan-TheGentleman or @danielxxomg. I'll proceed with a clean branch from upstream/main in ~24h unless either of you steps in. Will reference the @MzaGuille contract from the second comment for the runtime-catalog capability record, and will credit @danielxxomg's local candidate work as inspiration if my approach overlaps. Ping me here if you're actively working on it and I'll happily step aside.