[Bug]: Title generation falls back from Codex despite available credits, then fails silently #27792

Activity

1. okunamayanad commented on Nov 2, 2026

   

   okunamayanad

   on Nov 2, 2026

   Last edited by okunamayanad

   More actions

   Note

   Triaged with and comment written by bunx t3@nightly triage (GPT 6.1 Sol)

   I’m seeing this affect commit-message generation and review guides on Windows desktop nightly 0.1.7-nightly.20261101.4048.

   Text generation is configured as Codex gpt-6-luna low, with the dedicated source-control writer disabled. Review guides explicitly use Codex gpt-6.1-sol medium. Both instead invoke Claude Haiku 5.5 and fail with a 429 (as my Claude account is exhaused).

   

   My local Codex account’s weekly allowance is exhausted, but requests route through CLIProxyAPI, which has other accounts with available quota. Those accounts also appear in T3’s Usage panel.

   

   The triage traced this to TextGeneration.generate calling exhaustedUsageWindow on the selected provider’s snapshot and switching providers before attempting the request.

   Unlike the original report, this involves proxy account routing rather than prepaid credits. Harness identity doesn’t necessarily identify the subscription serving a request, so automatically using the aggregate Codex pool wouldn’t reliably solve it either.

   Could fallback respect the selected backend unless its quota source is explicitly associated with that route?
2. KyleDerZweite commented on Nov 5, 2026

   

   KyleDerZweite

   on Nov 5, 2026

   More actions

   Note

   🤖 GPT-6.1 Sol responding on behalf of Kyle

   This also affects commit-message generation in T3 Code Desktop 0.1.7 on Linux with a local server.

   My configured generation model is codex / gpt-6-luna. My included Codex allowance is exhausted, but I still have credits available. Commit-message generation nevertheless failed through OpenCode:

   Text generation failed in generateCommitMessage: OpenCode could not generate the text.
   

   The server trace records Free usage limit reached as the underlying error. The exact in-memory quota snapshot at failure time was not captured.

   Separately from the credit-aware fix in #27824, configurable fallback models for text generation would help. This path currently uses a fixed provider order and provider default models rather than the configured chat fallback. An explicit fallback selection or ordered fallback list could allow a working OpenCode/OpenRouter model to be chosen, with the attempted provider, model, and underlying error shown when generation fails.
3. softmaxe commented on Nov 10, 2026

   

   softmaxe

   on Nov 10, 2026 – with ChatGPT Codex Connector

   More actions

   Another reproduction on T3 Code desktop 0.1.8, with a different impact: title generation silently falls back to Pi's default local Ollama model, causing sustained GPU load.

   What happened

   The Text generation model setting shows Codex / 6 Luna / Low. A normal Codex conversation was still working, but its background title generation used Pi instead. Pi defaults to a local Ollama model of approximately 27B parameters on this machine (custom model alias redacted).

   The user observed approximately 98–99% GPU utilization and about 15.7 GiB of model memory, then manually stopped the local model. These resource measurements come from the user's supplied screenshot; this triage did not repeat the inference or independently resample GPU utilization.

   Evidence

   • The local environment endpoint reports serverVersion: 0.1.8. This is the desktop app's bundled local server, not merely the triage CLI version.

   • Two affected threads use Codex gpt-6.1-sol for their conversations.

   • server.trace.ndjson and its rotated copy show successful PiTextGeneration.generateThreadTitle spans:

     2026-11-10T09:44:13.405Z  duration ~170616 ms  exit=Success
     2026-11-10T09:49:33.878Z  duration ~91848 ms   exit=Success
     

   • A Codex account/rateLimits/updated event at 2026-11-10T09:44:25.890Z, during the first title generation, reports session usage 0%, weekly usage 100%, and credits.hasCredits: true with a positive balance. rateLimitReachedType and spendControlReached are both null. No exact credit balance or account identifiers are included here. The exact in-memory snapshot at the instant routing occurred was not captured.

   • During triage, Codex and Pi status snapshots are installed, authenticated and ready. Codex's weekly window remains at 100%; Claude's weekly window is also at 100%. Cursor, Grok, Muse and OpenCode are disabled. Pi is enabled.

   • The persisted text-generation selection is omitted because it equals the schema default: Codex gpt-6-luna, reasoning effort low. The omission is normal and does not indicate that the setting was lost.

   • Pi's global configuration sets defaultProvider: "ollama" and points defaultModel to that local model (custom model alias redacted); there is no project-level Pi settings file in the affected workspace.

   Source diagnosis

   Checked the exact v0.1.8 release, commit bf469bb19669671d0df2efda74ed73867a7137c0:

   • TextGeneration.generate checks exhaustedUsageWindow before invoking the selected provider and substitutes the first usable fallback.
   • exhaustedUsageWindow treats a non-reset 100% usage window as exhausted without considering spendable Codex credits.
   • Fallback selection uses a fixed provider order and each provider's default text model.
   • Pi's default model is default. Pi text generation does not send set_model for that selection, so Pi uses its configured Ollama model.

   This is consistent with the credit-unaware routing problem in this issue. Unlike the original failed OpenCode fallback, the fallback succeeds here and unexpectedly starts expensive local inference. The model picker continues to show Luna, without indicating that title generation used Pi.

   Reproduction conditions

   1. Select Codex gpt-6-luna / low for Text generation model.
   2. Have a Codex account reporting an exhausted weekly included allowance while Codex conversations still work and credits are reported available.
   3. Enable Pi with a local Ollama model configured as Pi's default; ensure earlier fallback candidates are disabled or considered exhausted.
   4. Start a new Codex thread or regenerate its title.
   5. Observe Pi title-generation spans and local Ollama inference despite the Luna setting.

   These steps describe the observed conditions and source path. Triage did not deliberately trigger another model request.

   Environment and workaround

   • macOS arm64, M2 Pro, 32 GiB unified memory.
   • T3 Code desktop and local server 0.1.8; triage CLI also 0.1.8.
   • Codex CLI 0.167.0; Pi 1.5.1.
   • The user manually stopped the local model. Triage made no configuration or database changes and did not patch the application.

   The user wants title generation to stay with the selected Luna model and does not consent to an unrelated local model being started as a silent fallback. Temporarily disabling Pi in T3 would prevent this particular fallback, but also disables Pi conversations and does not itself correct Codex routing.

   Investigated and drafted by Codex (GPT-6 family; exact model variant not exposed in this session) via t3 triage.
4. Nyxalium commented on Nov 13, 2026

   

   Nyxalium

   on Nov 13, 2026 – with ChatGPT Codex Connector

   More actions

   This also affects a configured fallback for new conversations, rather than only background text generation.

   Observed on T3 Code desktop 0.1.7, Linux, with the bundled local server:

   • Default model: Claude Sonnet 5.5.
   • Fallback model: Codex GPT-6.1-Sol, High reasoning effort.
   • Claude's weekly allowance is exhausted.
   • Codex's included weekly allowance is also exhausted, but the account has a positive purchased-credit balance.
   • Opening a new conversation still selects Claude. Sending the first message fails with Claude's weekly usage-limit error.
   • Manually switching the conversation to Codex allows requests to run.

   Read-only inspection confirmed that the default and fallback selections are saved correctly. The cached provider snapshots mark both weekly windows as 100% used; the Codex snapshot retains quota windows and a banked reset credit, but no purchased-credit balance. The installed resolveNewThreadModelSelection rejects the fallback when exhaustedUsageWindow(fallback, ..., fallback.model) returns a window, then leaves the default selected.

   The cache was inspected after the failed Claude request, so the exact in-memory snapshot at conversation creation was not captured. The positive purchased-credit balance was verified separately in the account's credits UI; the raw Codex credits response was not captured.

   This provides another scenario to validate for #27824: an exhausted Claude default with a Codex fallback whose included allowance is exhausted but which can still use existing credits. Under an applicable policy permitting that credit use, Codex should remain an eligible fallback; depleted credits or a provider spending block should retain normal exhausted-provider handling.

   This report does not request automatic credit purchases, auto-reload, or changes to account billing settings.