By OpenAI announced Sign in with ChatGPT at DevDay 2026 on September 29. Most coverage treated it as an OAuth curiosity — sixteen partners, Notion and Vercel on the list, another SSO button for your login page. That framing missed the part that actually matters. Plus and Pro subscribers can now authorize your app to spend their ChatGPT plan allowance directly, with no API key from you required. Sign in with ChatGPT is less of a login feature and more of a new payment model — one where your users absorb the AI compute cost instead of your billing account.
Two Features, Not One
Sign in with ChatGPT ships as two distinct integrations that share a name. Understanding which one you are building is the first decision you need to make.
Identity mode is standard OAuth 2.0 / OpenID Connect. Your app receives the user’s name, email, and profile picture. You get a stable account ID for session management. No AI capability, no access to conversations, no API credits. Think of it as Sign in with Google for the ChatGPT audience.
Plan usage mode goes further. When a Plus or Pro user approves the additional chatgpt.tokens.use.direct scope, eligible requests your app makes count against their subscription instead of your API key. You still call the OpenAI Responses API, but the bill goes to the user’s plan, not your platform account.
The scope strings make the difference concrete:
# Identity only
scope=openid profile email
# With plan usage
scope=offline_access resource.invoke chatgpt.tokens.use.direct
resource=https://api.openai.com/v1If you request only identity scopes, you will never touch a user’s plan. The two modes are mechanically separate.
Plan Usage Comes With Hard Restrictions
Plan usage is useful for a specific class of app and useless for another. The restrictions are the dividing line.
Every request funded by a user’s plan must set store: false and stream: true. You cannot pass temperature. You cannot pass max_output_tokens. System-role messages are out. At the feature level, the following are unavailable on plan funds: image generation, file search, Code Interpreter, native computer use, hosted MCP connectors, and tool_search in the Responses API.
If your app needs any of those features, plan usage will not work for those calls. You need an API key fallback path, and it needs to be automatic. When plan-funded requests hit limits, the API returns HTTP 429 with code subscription_sharing_usage_limit_exceeded. That error does not distinguish between three separate causes: the user hit their per-app cap, Plus subscribers exhausted their shared five-hour weekly window, or the overall plan balance ran out. Your fallback logic needs to treat all three identically.
Who Can Build With This Today
Availability is split, and the split determines your timeline.
Open-source and locally-running projects can implement plan usage today using self-serve registration with client_id=dynamic_agent_client. No waitlist, no approval required. CLI tools, local agent harnesses, and open-source IDE extensions can ship this now.
Commercial applications are in a limited trial with sixteen initial partners — Notion, Vercel, Devin, Warp, and others on the plan usage list; Airtable, Canva, GitLab, HubSpot, and Supabase for identity-only. Commercial developers who want plan usage access need to join the waitlist at openai.com. Identity-only sign-in for commercial apps is also in limited trial.
The practical approach while waiting: implement the full OAuth PKCE flow now, request only identity scopes, and structure your code so adding plan usage scopes later is a one-line change. The PKCE flow is identical either way. The OpenAI cookbook has a working implementation guide including the DevKit.
Connection State Is Not Binary
OpenAI does not notify your application when a user revokes access in ChatGPT Settings. You find out when a request returns HTTP 401 with subscription_sharing_invalid_user. By that point, the request has already failed.
Model connection health as at least four states, not a boolean:
granted— plan usage authorized, requests succeedingcapped_or_exhausted— 429 received, cap or limit hitnot_eligible— 403 received, user is not Plus/Prorevoked— 401 received, user disconnected the app
Update these states actively on request outcomes. Never cache a granted state and assume it holds. When limits trigger, link users to ChatGPT Settings directly rather than displaying a generic error — that is where they control their per-app cap.
The Risk Worth Naming
Plan usage is architecturally appealing. Small teams can offer GPT-6.1 Sol responses in their app without absorbing per-token API costs. Users with existing subscriptions get more value from their plan. The economics look clean on paper.
The problem is that OpenAI controls the denominator. The Pro 500 plan’s allowance dropped from 20x Plus to 10x Plus in October 2026 — new subscribers are already on the lower allowance, existing subscribers are grandfathered until October 29. That change was unilateral and outside developer control. Products built on plan usage inherit that volatility. An app that worked smoothly last month may degrade for users whose allowance just shrank.
This is not a reason to avoid the feature. It is a reason to design fallback paths from day one rather than treating plan usage as your only billing path. The WorkOS breakdown of plan usage scope mechanics covers the error handling edge cases in full. For the official DevDay 2026 announcement and partner list, see OpenAI’s DevDay 2026 release notes.
Open-source developers can start now with self-serve access. Commercial developers should implement identity-only login today and join the waitlist for plan usage. Either way, build the API key fallback before you need it — because with this feature, you will need it.
