Android hides accessible GPT 6 Astra as legacy on Pro 5x (prolite)

[MidbrainMan]

What happened

In the Android app v1.1.0, GPT 6 Astra (gpt-6-astra) is missing from the normal Codex provider/model picker for an authenticated ChatGPT Pro 5x (prolite) account. A new T3 thread ran gpt-5.6-sol, although direct Codex CLI execution with Astra works on the same account.

This is the triage replacement for #11632, explicitly requested by its author. It includes fresh verification and corrections to that report's diagnosis.

Diagnosis

The account has working Astra access. The evidence points to T3's model classification/picker state, but does not establish a missing prolite entitlement mapping:

• The provider event log records account/rateLimits/updated with planType: "prolite" for the affected fresh thread.
• The current on-disk Codex provider snapshot includes Astra with isLegacy: true; Sol is marked isDefault: true. Thus Astra is present in T3's provider list, contrary to the initial assumption that it was absent altogether.
• In the v0.0.40 source, apps/mobile/src/features/threads/ThreadSettingsSheet.tsx filters out legacy models unless “Show legacy models” is enabled or the model is already displayed. apps/mobile/src/lib/modelOptions.ts also excludes legacy models from implicit defaults. This explains how the cached flag can cause the reported picker/default behavior; the Android UI was not automated during this check.
• apps/server/src/provider/Layers/CodexProvider.ts already maps prolite to “ChatGPT Pro 5x Subscription” and obtains available models through paginated Codex model/list requests. A plan-specific gate has not been demonstrated.
• Both the v0.0.40 source and installed server bundle list Astra in model-manifest.json under currentModels.codex. ModelManifest.ts classifies models using that manifest. The reason the provider cache nevertheless contains isLegacy: true remains unresolved; investigate snapshot/cache classification and manifest refresh before assuming an entitlement bug. This cache was last checked at 2026-09-13T20:34:00.124Z, so it is evidence of persisted state, not a newly requested live snapshot.
• Correction to GPT 6 Astra not selectable on Pro 5x (prolite) plan #11632: installed v0.0.40 defaults to gpt-5.6-sol, not Astra. DEFAULT_MODEL = "gpt-6-astra" is on newer upstream main, introduced by fix(models): default to astra medium and fable 5.1 medium #11347 (commit 1f73a89fc4d5c8b3e188282aeb8173f8f8bf257b, September 12). The new thread's Sol selection is consistent with the installed default; it alone does not prove an attempted Astra request silently fell back.

Source checked: clean v0.0.40 checkout at 09e8de9c655ae85410bf6b00446f272a01da81c7, plus the installed v0.0.40 bundle and current upstream main. At filing, GitHub's latest stable release is still v0.0.40. The newer default change does not establish that this cached legacy-classification symptom is fixed.

Steps to reproduce

1. Authenticate Codex with a ChatGPT Pro 5x (prolite) account that can successfully execute gpt-6-astra directly.
2. Connect Android app v1.1.0 to T3 server v0.0.40 and open the Codex model picker with legacy models hidden.
3. In the affected installation, Astra is unavailable in the normal picker and a new thread runs Sol.
4. Inspect the provider snapshot: the affected cache lists gpt-6-astra with isLegacy: true and gpt-5.6-sol with isDefault: true.

Expected: an accessible model listed as current in T3's manifest appears in the normal model picker. A deterministic reproduction of how the incorrect cached flag is generated is still needed.

Version

T3 server 0.0.40, tag v0.0.40, commit 09e8de9c655ae85410bf6b00446f272a01da81c7; Android app 1.1.0 (user-reported).

Environment

Android client connected to a running T3 server on Linux x64 (kernel 6.8.0-139-generic); Node v22.23.2; Codex CLI 0.154.0; authenticated ChatGPT Pro 5x / prolite. Machine facts checked against the generated t3 triage context.

Evidence

Selected fields only; paths, account identifiers, and unrelated payloads omitted:

Provider events, 2026-09-13:
19:50:03Z: fresh thread startup recorded model "gpt-5.6-sol"
19:50:11.570Z: account/rateLimits/updated
  {"planType":"prolite","primary":{"usedPercent":37,"windowDurationMins":10080}}

Codex provider cache, checkedAt 2026-09-13T20:34:00.124Z:
  {"slug":"gpt-6-astra","isLegacy":true}
  {"slug":"gpt-5.6-sol","isDefault":true}

Fresh direct CLI check during this triage:
  codex exec --model gpt-6-astra --skip-git-repo-check --ephemeral --sandbox read-only \
    'Reply with exactly ASTRA_ACCESS_OK. Do not use tools or inspect files.'
  Header: model: gpt-6-astra; provider: openai
  Response: ASTRA_ACCESS_OK
  Exit code: 0

Related issues

• Duplicate/replacement of GPT 6 Astra not selectable on Pro 5x (prolite) plan #11632, filed earlier by the same author through the raw API without the triage template/label. This report supersedes it with checked evidence and a corrected diagnosis. GPT 6 Astra not selectable on Pro 5x (prolite) plan #11632 should be closed as a duplicate of this issue.
• [Bug]: Not recognizing ChatGPT Pro 5x #2214 (closed), “Not recognizing ChatGPT Pro 5x”: similar reported symptom involving Spark and prolite. Current source already recognizes the plan label, so this is historical context rather than proof of the same root cause.
• fix(models): default to astra medium and fable 5.1 medium #11347 changes the upstream default to Astra after the installed release; relevant to the original report's source/version mismatch.

Fix applied or workaround

Direct Codex CLI execution with --model gpt-6-astra was re-tested successfully. The Android source offers “Show legacy models,” which may expose Astra while the cached flag is wrong; this UI workaround has not been tested on the device. No T3 configuration, database, cache, or source changes were applied.

Filed by

Codex (gpt-6-astra), following the T3 triage playbook and generated machine context; independently checked local logs, provider cache, installed bundle, tagged source, and upstream source. Filed using the via-triage template structure at the user's request. Maintainers: please apply the via-triage label. GitHub ignored the requested label on creation and rejected an explicit label update because the reporting account lacks AddLabelsToLabelable permission. #11632 has been closed as superseded by this report.