{"slug": "subscription-sharing-usage-limit-on-app-blocking-openai-model-usage-after-reset", "title": "Subscription Sharing usage limit on app blocking OpenAI model usage after reset", "summary": "Users of third-party apps that sign in with ChatGPT, including Pi, OpenChamber 2.3.3 (bundled OpenCode 2.0.29) and OpenCode, are reporting a \"Subscription Sharing usage limit\" error that persists after their weekly usage limit resets, according to a GitHub issue filed in the openai/codex repository on October 5, 2026. Affected users report the error \"The ChatGPT user has reached their Subscription Sharing usage limit\" even when their 5-hour and weekly quotas still show 26% and 79% remaining, while the official Codex app and CLI continue to work; one user reproduced the `subscription_sharing_usage_limit_exceeded` error by calling the Responses API directly with a valid OAuth token. A workaround posted in the thread is to sign in with the legacy `openai-codex` provider instead of \"Sign in with ChatGPT,\" which several users say restores access.", "body_md": "## Repository navigation\n\n[authIssues related to authentication and accounts](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22auth%22)Issues related to authentication and accounts\n\n[bugSomething isn't working](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22bug%22)Something isn't working\n\n[rate-limitsIssues related to rate limits, quotas, and token usage reporting](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22rate-limits%22)Issues related to rate limits, quotas, and token usage reporting\n\n## Description\n\n### What issue are you seeing?\n\nAfter using up 100% of my weekly usage limit through OpenAI models in Pi, I used a full reset.\n\nUnfortunately, Pi (and I suspect other apps of its kind with supported OpenAI login as well) does not recognize this, and I'm met with the error \"Error: The ChatGPT user has reached their Subscription Sharing usage limit. Ask the user to try again after their usage limit resets or use an API key instead.\"\n\nLogging out of OpenAI in Pi and logging back in does not fix this problem, and this creates an additional Pi connection on my account that I cannot seem to remove, see the screenshot:\n\nAs limits can't be elevated beyond 100% here, nor that toggling off the setting seems to do anything, I am effectively locked out of OpenAI model usage in Pi, even though my usage works fine in both the codex app and CLI.\n\n### What steps can reproduce the bug?\n\nUse up your full weekly limit in a connected app, reset your usage, and try to use it again.\n\n### What is the expected behavior?\n\n*No response*\n\n### Additional information\n\n*No response*\n\n## Activity\n\n1. added[rate-limitsIssues related to rate limits, quotas, and token usage reporting](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22rate-limits%22) Issues related to rate limits, quotas, and token usage reporting[authIssues related to authentication and accounts](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22auth%22) Issues related to authentication and accountson Oct 5, 2026\n2. 1/ This message started to appear when I hit limits on Codex \n 2/ I had applied reset\n 3/ ChatGPT desktop app and codex cli started to work\n 4/ pi with openai models gives this error\n 5/ Subscription Sharing usage limit = 100% for this app (I was not changing it)Maybe a bug because going over limit and using reset is >100%? Or app limit is stuck at consumed 100% and not reset to 0% when weekly reset applied? Reacted by Ajay Krishnan and sevron-gil\n3. I’m having a similar problem—I don’t know what they did, but it was working fine before.\n4. For anyone running into this issue, I found a workaround: if you sign in using the old provider ( `openai-codex` ), it works correctly.So until this gets fixed, you can use `openai-codex` instead and, at least for now, everything seems to work fine.Reacted by Michael Pilosov, PhD, Ga Satrya, Przemek Harendarz, Valentin Rubio, Plamen Petkov, Vignesh Sankaran, Felix, Thomas Mur, José Miguel Alvarez, Zeldris and 1 more\n5. [@carsan-dev](https://github.com/carsan-dev) that does not work when using daybreak :(\n6. Works when using codex legacy authent on opencode thanks for the tips.\n7. I encountered the same issue with OpenChamber 2.3.3 (bundled OpenCode 2.0.29) on Windows. My 5-hour and weekly quotas still had 26% and 79% remaining, with the app limit set to 100%. Official Codex worked fine, and OpenChamber worked on another machine using the same account. I also reproduced `subscription_sharing_usage_limit_exceeded` by calling the Responses API directly with a valid OAuth token, bypassing OpenChamber/OpenCode.**Confirmed workaround:** Switching from`Sign in with ChatGPT` to`Codex browser (legacy)` immediately restored functionality.Thanks [@carsan-dev](https://github.com/carsan-dev) for the workaround! Hope this helps others.\n8. ### ailee945 commentedon Oct 30, 2026 More actionsI am still encountering this issue in **Pi Agent** when trying to use**GPT Astra** through my ChatGPT subscription.Pi returns: \n\n```\nError: The ChatGPT user has reached their Subscription Sharing usage limit. Ask the user to try again after their usage limit resets or use an API key instead.\n```\n\n However, my ChatGPT account still shows available usage, so I would not expect my subscription quota to be exhausted. I have not confirmed whether my case is related to a banked/full usage reset, or whether the app-specific sharing allowance is out of sync. It seems similar to other reports in this thread where official Codex usage and third-party subscription sharing do not match. **Could the OpenAI team confirm whether this is still a known issue with the Subscription Sharing quota/entitlement checks for third-party apps?** If needed, I can provide the precise remaining usage figures, Pi version, UTC timestamp, and request ID for diagnosis.\n9. This happened to me using version 1.3.0. I tried switching to openai-codex Legacy and the problem persisted. It was fixed when I updated to version 1.5.0.\n10. The same issue occurs with ChatGPT Pro $200 when calling the public Responses API through Sign in with ChatGPT (observed November 3, 2026). \n  - Native Codex reports 22% weekly quota remaining; the app usage cap is 100%.\n  - SIWC returns `subscription_sharing_usage_limit_exceeded` over both HTTP and WebSocket.\n  - A fresh app registration and logout/login of the original registration did not help.\n  - Native Codex and a minimal request through the legacy adapter succeed.\n The underlying cause remains unconfirmed.\n11. Same problem since i switched to pro 200. Less then \"25% usage left\" is not possible :-/ Reacted by Oleg Desyatnikov and Zelayan\n12. Same problem on the plus plan\n13. I am seeing a similar mismatch on a ChatGPT Pro account through Magpie's ChatGPT API / Sign in with ChatGPT integration. Observed on November 6, 2026: \n  - ChatGPT's Usage page shows **83% of the weekly allowance remaining** , with the next reset about 6 days and 10 hours away. The account menu confirms the usage source is the Pro plan.\n  - Requests for `gpt-6.1-sol` with`medium` reasoning were succeeding earlier that day. The last successful request in the inspected account logs started at 12:37 UTC+8.\n  - At 14:14, 14:14, 14:16, and 14:18 UTC+8 (06:14–06:18 UTC), requests returned HTTP **429** with`error.code: subscription_sharing_usage_limit_exceeded` .\n  - The login remains enabled and is not marked as expired by the client. The account has 0 purchased credits, but still shows the included weekly allowance above.\n I have not yet independently verified the app-specific sharing cap, reproduced this outside Magpie, or established whether a usage reset/plan change triggered it. Those details should not be assumed from this report. Could the team clarify whether this mismatch is a known issue and what diagnostics would distinguish an app-specific cap from an out-of-sync subscription-sharing allowance? The current error does not identify the affected limit or its reset time.\n14. ChatGPT's Usage page shows \n15. I found a solution that worked for me. In ChatGPT, I went to Settings → Security and Login → Login connections and revoked \n access for all connected devices and apps. Then I renewed Pi’s OAuth login, and all my apps started working again.I noticed that each time I renewed Pi’s OAuth login, a new app entry appeared in ChatGPT’s Usage menu. My guess is that \nthere may be a limit on how many apps or connections can access the same account at once.\n16. Adding another reproducible case on ChatGPT Pro ($200/month). \n Updating Pi to v1.5.0 did NOT resolve it.Environment: \n  - Three connected apps: two Pi registrations and my own\nprivate harness.\n  - All three have their weekly app usage limit set to 100%.\n  - Model tested in Pi: gpt-6.1-sol.\n Observed behavior: \n  - The errors started several days ago, while approximately\n50% of the weekly allowance was still remaining.\n  - At my most recent check, 19% remained.\n  - The weekly usage reported through the legacy Codex usage\npath matches the ChatGPT website.\n  - The new subscription OAuth / Sign in with ChatGPT path\nhas consistently failed for approximately three days.\n  - Direct Responses API requests reproduce HTTP 429 with\n subscription_sharing_usage_limit_exceeded over BOTH\nHTTP and WebSocket, independently of Pi.\n  - The legacy Codex authentication path still works.\n  - After updating Pi to v1.5.0, even a simple \"hi\" request\nstill fails with the same Subscription Sharing limit error.\n I have not performed any manual usage resets or tried \n revoking and reconnecting the apps.This does not appear to be specific to Pi, and the failures \n started well before the approximately 25% remaining threshold\n mentioned earlier in this thread.Could the team clarify: \n  1. Which quota or entitlement check produces this error when\nweekly allowance remains and the app limit is set to 100%?\n  2. Is there a separate subscription-sharing quota or window?\nIf so, how can users inspect its usage and reset time?\n  3. Is any additional supported configuration required to use\nthe remaining included allowance through this path?\n Related: [#54219](https://github.com/openai/codex/issues/54219) . Without supported usage/reset telemetry for\n the token-sharing path, it is difficult to determine which\nlimit is actually being enforced.\n17. Three connected apps: two Pi registrations and my own\n18. Adding a reproducible case through **Kilo (Sign in with ChatGPT / subscription sharing)** , observed on**November 9, 2026** :\n  - ChatGPT Usage showed **52% of the overall weekly allowance remaining** .\n  - The **Kilo app usage limit was set to 100%** .\n  - Requests through Kilo failed with `Subscription Sharing usage limit` (`subscription_sharing_usage_limit_exceeded` appears to be the corresponding error code reported elsewhere in this thread).\n  - I then **enabled use of purchased credits** and retried the request.**It succeeded, and credits were actually deducted.**\n This suggests the model/OAuth integration can handle the request, but the subscription-funded path is refusing it despite the reported remaining weekly allowance and 100% app cap. I cannot determine whether this is a separate undocumented subscription-sharing quota or a quota-accounting/entitlement error. **Could OpenAI clarify which exact limit is being enforced, where its remaining balance/reset time can be inspected, and why credit-funded requests succeed when the included subscription allowance is still available?**\n19. ChatGPT Usage showed \n20. Follow-up to my report above: **my subscription is ChatGPT ProMax ($500/month)** , not the $200 Pro plan.One possible explanation worth checking is a **plan-tier entitlement mismatch** : could the Subscription Sharing / Sign in with ChatGPT usage check be applying a lower-tier allowance (for example, Pro 100) instead of the actual ProMax allowance, while ChatGPT Settings → Usage displays the correct higher-tier weekly balance?At the time of the failure: \n  - **52%** of the ProMax weekly allowance remained;\n  - Kilo's app limit was **100%** ;\n  - the subscription-funded request was rejected;\n  - permitting purchased credits made the same route succeed, and credits were deducted.\n I realize this is a **hypothesis, not a confirmed diagnosis** , and other reports in this thread involve Pro $200 and Plus accounts as well. Could the team confirm the plan tier and exact entitlement/quota applied by the Subscription Sharing backend to these requests, and whether it matches the plan reported by ChatGPT Usage?Reacted by John Honaker\n\n## Metadata\n\n## Metadata\n\n### Assignees\n\n### Labels\n\n[authIssues related to authentication and accounts](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22auth%22)Issues related to authentication and accounts\n\n[bugSomething isn't working](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22bug%22)Something isn't working\n\n[rate-limitsIssues related to rate limits, quotas, and token usage reporting](https://github.com/openai/codex/issues?q=state%3Aopen%20label%3A%22rate-limits%22)Issues related to rate limits, quotas, and token usage reporting", "url": "https://wpnews.pro/news/subscription-sharing-usage-limit-on-app-blocking-openai-model-usage-after-reset", "canonical_source": "https://github.com/openai/codex/issues/51043", "published_at": "2026-11-12 02:14:44+00:00", "updated_at": "2026-11-12 02:23:02.150940+00:00", "lang": "en", "topics": ["ai-tools", "ai-products", "large-language-models", "developer-tools"], "entities": ["OpenAI", "Codex", "Pi", "OpenCode", "OpenChamber", "ChatGPT", "GPT Astra"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/subscription-sharing-usage-limit-on-app-blocking-openai-model-usage-after-reset", "markdown": "https://wpnews.pro/news/subscription-sharing-usage-limit-on-app-blocking-openai-model-usage-after-reset.md", "text": "https://wpnews.pro/news/subscription-sharing-usage-limit-on-app-blocking-openai-model-usage-after-reset.txt", "jsonld": "https://wpnews.pro/news/subscription-sharing-usage-limit-on-app-blocking-openai-model-usage-after-reset.jsonld"}}