Many people pay for ChatGPT Plus or Pro every month, yet when writing code or running local agents, their development tools often require entering a separate API key, billing token usage on a completely different invoice. Since the subscription already includes ample reasoning compute, why can’t we connect this quota directly into our own development environment?
In the past, using subscription quotas with third-party tools required borrowing the public client identities of official clients to invoke private endpoints within a gray area not explicitly forbidden by OpenAI. It was not until September 2026, when OpenAI introduced Sign in with ChatGPT, that an official protocol finally emerged. This article explores the technical evolution of connecting ChatGPT subscriptions to external tools, the specific rules and limitations of the official protocol, and how to weigh trade-offs among three approaches: official API keys, official subscription authorization, and reusing official client subscription identities. At the end of the article, we also provide a runnable reference implementation that we built ourselves.
If you often tinker with AI toolchains locally, the awkwardness of having two concurrent bills should come as no surprise; when teams and companies scale up their usage, this redundant expense becomes even more glaring: on one side is the fixed monthly ChatGPT subscription charged to your credit card, and on the other is the API bill auto-reloading every few days in the OpenAI developer dashboard. You are calling models from the exact same company—why can’t the subscription quota already in hand offset the consumption from coding and running agents?
Why these two accounts don’t communicate starts with how each charges
money. The developer-facing open platform centers around the Responses
API inference endpoint, which bills purely on the actual number of
input and output tokens. Checking the latest official
pricing, the dedicated model gpt-6.1-sol costs $2 per 1
million input tokens and $10 for output; stepping up to the higher-tier
flagship model gpt-6-astra, the output price jumps to $50.
There are lightweight and mid-tier models in between with much cheaper
unit prices, but whenever local tools frequently stuff large codebases
into context and have the model run multiple rounds of long thinking,
the accumulated token costs ramp up quickly.
On the other side are ChatGPT subscriptions aimed at individual users or teams. Individuals have choices ranging from the complimentary Free and lightweight Go tiers, to the primary Plus tier ($20/month), all the way up to compute-tiered Pro plans. Teams are billed per seat; ChatGPT Business plans cost $25 per user per month billed monthly for standard seats, with discounts available for annual billing.
There is also an easily overlooked detail: ChatGPT subscriptions already come with built-in Codex (the official coding capability), and Codex and ChatGPT Work share a single usage pool across all plans. Converting this allowance into equivalent API calls is substantial; estimates from SemiAnalysis suggest that the API-equivalent value of an OpenAI subscription is roughly 12 times the subscription fee, which translates to nearly two to three thousand dollars in API spend for a $200 Pro tier. In other words, you already possess a massive pool of unused compute in your hands yet continue to open a separate API tab for third-party tools, which is precisely what makes wanting to use the subscription so compelling.
These two product lines have always been separate in their billing and licensing frameworks. OpenAI also explicitly clarifies in the Business FAQ that ChatGPT Business subscriptions do not include API usage, and that API usage requires separate payment. Legally speaking, consumer products are governed by the OpenAI Terms of Use, whereas developer APIs operate under the Business Terms, which explicitly state that they do not apply to consumer personal services. Account balances on the two sides are also non-transferable. The reason so many users with premium subscriptions still have to bind credit cards in third-party tools is simply that OpenAI’s business rules keep these two ecosystems segregated.
Faced with these two bills, a natural thought was whether external tools could pose as official clients to draw directly from subscription quotas. This fundamentally involves two things: first, identity authentication, confirming who is initiating the call; second, billing attribution, determining who pays for the call.
API keys easily handle billing, but users must hold a developer
account and keep topping it up. While ChatGPT subscriptions prepay for
compute, OpenAI officially only supported their web, mobile, and desktop
clients. However, their own coding assistant, Codex, was an exception.
The Codex client (for which the aforementioned gpt-6.1-sol
is the default code model) offered two parallel login paths: traditional
API keys, and login
authentication based on ChatGPT subscriptions.
Since the official Codex client already supported logging in with a
ChatGPT subscription, could third-party clients do the same?
Unfortunately, OpenAI provided no public API for it. Consequently, the
open-source community reverse-engineered the official client and
uncovered the entire implementation workflow. As revealed by in-depth
discussions in the developer community, many editor coding
extensions (such as Roo Code) opted to directly reuse the publicly
distributed OAuth client identifier client_id of the
official Codex client, launching a local browser to complete
authorization, and then forwarding inference requests straight to
ChatGPT’s private backend endpoint
chatgpt.com/backend-api/codex/responses.
This approach was technically effective: users could tap into the Codex compute included in their subscription without spending extra money. Contractually, however, it never received formal support from OpenAI.
OpenAI’s stance had always been ambiguous. On February 9, 2026, etraut-openai, an OpenAI maintainer overseeing Codex, shared personal thoughts in a public response in GitHub Discussions when answering developers: speaking as an engineer rather than a lawyer, the official terms of use and open-source licenses were relatively lenient, and open-source terminal coding tools like OpenCode were doing similar things. Many developers at the time interpreted this informal reply as de facto tacit consent.
Yet in official documentation and legal agreements, this domain remained an ambiguous gray area. OpenAI’s terms of use explicitly prohibit sharing account credentials with others, and strictly forbid circumventing any rate limits, technical protections, or security mitigations. Following a compliance audit, the OpenHands software agent development team also noted that major model providers explicitly discourage or outright prohibit automated calls to consumer products via third-party clients, recommending that serious production workloads still rely on official API keys.
This situation persisted until the autumn of 2026: while people managed to get their tools working through private endpoints, everyone knew this was an uncommitted, temporary pathway lacking SLA guarantees, liable to break at any moment from endpoint modifications.
On September 29, 2026, OpenAI officially announced the Sign in with ChatGPT service at DevDay. The core problem it aims to solve is enabling third-party tools to legitimately draw upon quota from users’ own ChatGPT subscriptions upon user authorization. This marked the first time OpenAI publicly acknowledged and authorized such usage, serving as the official entry point for open-source projects and local tools to transition away from private endpoints. Sixteen launch partners were announced right out of the gate.
In the ecosystem announced by OpenAI, open-source software secured a distinct place. According to the official onboarding guide and integration directory, the first batch of open-source integration partners included projects such as OpenClaw, OpenCode, Pi, and T3; commercial trial applications featured products like Devin, Notion, Vercel, Warp, Airtable, GitLab, and Supabase.
This introduced a critical new concept: authorization is divided into
two distinct tiers: 1. Basic Identity Authentication
Layer: Defined in the official quickstart
documentation, its authorization scope encompasses the standard
openid profile email. This layer is solely responsible for
confirming the user’s ChatGPT account identity and returning an ID
token. OpenAI explicitly notes here that basic identity scopes grant no
access whatsoever to the user’s ChatGPT conversation history or OpenAI
API resources. 2. Subscription Quota Sharing Layer:
Defined in the token
sharing specifications for open-source projects, requiring explicit
requests for the
offline_access resource.invoke chatgpt.tokens.use.direct
permission, while setting the resource parameter to
https://api.openai.com/v1. Only when the user checks the
box on the consent screen allowing the application to utilize their
subscription quota can external tools initiate actual model
inference.
In terms of availability, access for commercial applications remains in a limited trial phase; however, for subscription quota consumption, OpenAI stipulated that from the initial launch it is fully open to all open-source projects, locally run personal projects, and selected private clients.
Regarding ownership and billing, the official documentation states that users with Go, Plus, or Pro subscriptions can authorize compatible applications to use their own subscriptions without generating or sharing personal API keys. All eligible requests are counted directly against the usage quota included in the user’s plan. This represents a classic Bring Your Own (BYO) subscription model, preventing everyone from having to share a common account. Users can inspect the active status of authorized tools, monitor compute utilization, and unilaterally revoke authorization at any time in the ChatGPT settings center.
client_id to
the public reserved identifier dynamic_agent_client, while
passing in the unique identifier of the current execution host
ext_agent_host_id along with a tool name hint
agent_name_hint.127.0.0.1:1455/auth/callback. Once verification
succeeds, OpenAI returns a formal client_id bound to the
current user account and selected workspace in the response, which can
be reused long-term for subsequent flows. The entire process requires
neither storing client secrets nor registering commercial API keys as a
developer.api.openai.com/v1/responses. The official
documentation issues a warning in bold font: the aforementioned public
Responses API endpoint must be used, and directing requests to ChatGPT’s
private backend-api endpoints is strictly prohibited.store:false (not saving response state for subsequent
retrieval or continuation) and stream:true (enforcing
streaming output) in the JSON payload. In terms of credential
lifecycles, access tokens are valid for 1 hour, while refresh tokens
support a 30-day sliding window rotation.OpenAI positions the current subscription quota sharing as a preview
stage; compared to completely unrestricted API keys, it still carries
many strict limitations. According to the preview
limitations documentation, callers cannot use common sampling tuning
parameters, and configuring fields such as temperature,
max_output_tokens, prompt,
background, conversation,
metadata, and moderation is unsupported; many
officially provided capabilities cannot be used, such as the built-in
Code Interpreter, file search, image generation, native computer use,
and cloud-hosted MCP connectors; audio and video cannot be passed as
inputs, and file uploads and speech transcription are unsupported.
Furthermore, this endpoint does not support automatic conversation
continuation based on server-stored history; instead, the tool must
manually append historical messages into each request.
The previous section covered the official, sanctioned path. This section looks at an earlier and more direct route, albeit one no longer recommended for long-term dependency: writing the previously mentioned gray path into a runnable, minimal implementation. It serves more like an educational sample whose value lies in laying bare the entire mechanism of exchanging subscriptions for tokens, making it unsuitable as a permanent dependency. We open-sourced it in the chat-gpt-oauth-skill repository.
To be clear, it includes a standalone command-line interface, but you don’t have to use it at all; the CLI itself isn’t particularly meaningful. Its true purpose is to serve as a reference implementation: integrate it into your own agents or sub-agents, turning the act of sending requests via a ChatGPT subscription into a modular component within your toolchain. It thoroughly demonstrates OAuth credential exchange, token lifecycle management, and Codex inference request construction, allowing you to see firsthand from the code what a subscription token looks like and how requests are dispatched.
Installation doesn’t require trudging through documentation yourself.
Simply hand the repository link directly to your AI coding tool (Codex,
Claude Code, or OpenCode all work), let it read through the repo first,
and have it install, configure, and run the demo according to the
instructions inside. By default, it stores the token as plaintext JSON
in ~/.chatgpt_oauth/token.json (with permissions 0600), an
educational design choice deliberately left for debugging and
observation rather than a production-grade security practice.
Its communication target is the official Codex private backend,
representing two pathways addressing the same demand compared to the
official Sign in with ChatGPT from the previous section: the official
protocol targets api.openai.com, whereas this skill reuses
the existing identity of the official Codex client to target private
endpoints. As such, it is not an official SDK; relying on private
endpoints without SLA guarantees, it is suitable only for personal
technical exploration, educational verification, and lightweight local
tools entirely under your own control.
Placing these paths side by side makes it easier to see which one fits whom.
Currently, there are primarily three paths to accessing OpenAI models:
The first is the standard official API
key route. It is a first-class citizen in the OpenAI developer
ecosystem, targeting the standard
api.openai.com/v1/responses endpoint and governed by the
official Services Agreement. This path offers the most comprehensive
capabilities: supporting all exposed parameters for the selected model,
the full official toolchain such as Code Interpreter and file search,
and diverse input modalities. Its cost is pay-per-token billing, with no
ability to share existing quotas from personal ChatGPT
subscriptions.
The second is the official Sign in with ChatGPT subscription quota route. Designed specifically for open-source projects and personal scripts, it provides an officially sanctioned channel for consuming subscriptions, allowing users to legitimately sign in carrying their Plus or Pro subscriptions without exposing high-risk API keys in third-party tools, while retaining the ability to review and revoke authorization in ChatGPT settings at any time. Its trade-off is that it remains in preview, with OpenAI trimming away many advanced tuning parameters and hosted tools, while inputs are restricted to text, images, and files supported by the selected model.
The third is the reverse-engineered protocol route that directly reuses the Codex client identity (such as the chat_gpt_oauth skill). Locally, it can maximize the extraction of Codex-specific model capabilities bundled in the subscription, yet it operates in a gray area without explicit official endorsement, lacks long-term stability guarantees, and is suitable only for personal tinkering and local transition.
Among these three, one opens a separate API bill, while the other two find ways to put subscription allowances to work.
Faced with these options, developers’ selection criteria can be summarized into the following points: - Pursuing zero additional cost and wishing to consume personal idle subscriptions: Prioritize trying Sign in with ChatGPT; if constrained by preview parameter restrictions or in need of a specific Codex interaction experience—and with full awareness of its unofficial nature—a local reference implementation like chat_gpt_oauth can be adopted temporarily. - Pursuing production-grade stability, requiring complex engineering tuning and multimodal tools: Opt directly for official API keys. Paying for usage on a per-token basis trades cost for more complete official API capabilities and commercial agreement protections.
Using personal subscriptions to drive third-party tools instead of pay-as-you-go APIs was, for a long time, limited to exploring gray areas by borrowing official client identities. The launch of Sign in with ChatGPT in September 2026 opened an official door for open-source and local development at the contractual level for the first time. Although this official channel remains subject to strict preview limitations, it marks the beginning of bridging the divide between consumer subscriptions and third-party developer tools.
One final note outside the main thread: if you are solving a different class of problem, such as running programs autonomously in the cloud for extended periods, OpenAI also offers the Agents API. It exposes the long-horizon task orchestration capabilities driving Codex as a hosted service, but bills at standard API rates without consuming subscription quota, so we won’t expand on it here.