Repository navigation
fix(settings): show one ChatGPT subscription login after Pi 0.99 - #422
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| const providers = statusQuery.data?.providers ?? []; | ||
| const subscriptionProviders = useMemo( | ||
| () => providers.filter((provider) => provider.supportsOAuth), | ||
| () => providers.filter((provider) => showsSubscriptionCard(provider)), |
There was a problem hiding this comment.
🔴 ChatGPT login offers unavailable models
After ChatGPT signs in through openai, the model list falls back to Pi's unfiltered catalog. Account model sources filter ChatGPT plans only under openai-codex and recognize openai API keys only. Users can select models their subscription rejects.
Learn more
Pace filters model catalogs per provider to the signed-in account's allowed models. The new Subscription entry signs users in under openai, but the account-model sources use ChatGPT's account model endpoint only for openai-codex. The openai source identifies only API-key credentials, so its refresh skips filtering an OpenAI OAuth login. The OpenAI catalog remains available and can contain models outside the ChatGPT subscription; choosing one fails when the session calls the provider.
Example: A user signs into ChatGPT under openai and sees a catalog model unavailable on their plan. They select it in the composer, and the model request fails instead of the unavailable model being omitted.
Recommended fix: Extend the openai account-model source to detect OAuth versus API-key credentials, use the ChatGPT account endpoint for OAuth, and retain the existing API-key model-list behavior. Cover both credential types with account-model runtime tests.
Was this helpful? React with 👍 or 👎 to provide feedback.
| const providers = statusQuery.data?.providers ?? []; | ||
| const subscriptionProviders = useMemo( | ||
| () => providers.filter((provider) => provider.supportsOAuth), | ||
| () => providers.filter((provider) => showsSubscriptionCard(provider)), |
There was a problem hiding this comment.
🟡 ChatGPT model mislabeled as API
When both ChatGPT providers expose the same model, openai OAuth rows display “OpenAI API.” The channel label still assumes every openai model uses an API key.
Learn more
The model selector adds channel labels when two providers expose the same model. The channel label map says openai is always "OpenAI API", while the model selector selects this label based only on provider ID. The new OAuth entry lets ChatGPT subscriptions use openai, making the label false when an old Codex login also exposes the model.
Example: A user keeps an existing openai-codex subscription and also signs into openai through ChatGPT. If both list gpt-5.5, the selector calls the openai row "OpenAI API" even though it uses the subscription.
Recommended fix: Derive the channel label from the active auth mode as well as provider ID, or remove billing-specific labels when the mode cannot be determined. Test the duplicate-model case with openai OAuth and legacy Codex OAuth.
Was this helpful? React with 👍 or 👎 to provide feedback.
No linked issue: release blocker found by the v0.1.0 Release run (Linux packaged E2E, https://github.com/bubbleptr/pace/actions/runs/36863765098).
Summary
openaiprovider and renamedopenai-codexto "OpenAI Codex (legacy)", so Settings → Providers → Subscription showed two ChatGPT logins ands3-provider-settings.spec.tsfailed.@pace/core:LEGACY_SUBSCRIPTION_PROVIDERS+showsSubscriptionCard(); the legacy codex card shows only for an existing codex OAuth sign-in (status, Check, sign-out stay reachable).FEATURED_PROVIDER_ORDERputsopenaifirst.supportsOAuth); dev mock mirrors Pi 0.99 (openai.supportsOAuth = true).Test plan
openaishownbun run typecheck/lint/build/test(1968) green--max-failures=0): 34 pass, 2 conditional skips; the one other failure was local env leakage (ANTHROPIC_API_KEYin the shell) and passes 6/6 with a clean env