Will the Day Come When My Users’ Subscriptions Pay for My App’s AI? — Sign in with ChatGPT and MCP Events#

2026-10-11

A Conclusion From Two Months Ago Got Shaken#

In August I wrote an essay titled Why an AI Subscription Is Not a Cheap API. Its conclusion was that the economics of a subscription hold only inside the products the provider allows, and that a third-party business has to be built on the separate economics of the API (Application Programming Interface).

From the perspective of someone building third-party apps, that was an uncomfortable conclusion. The amount of compute an individual gets from a $20-a-month subscription, used all day long, costs several times more when paid for through the API. The user is already paying for an AI subscription, yet if they want to use the same model inside my app, I have to pay API fees all over again. Costs grow with every user, and if I pass them back to the user, the user ends up paying for AI twice.

Then, on September 29, OpenAI DevDay delivered an announcement that attacks this premise head-on: Sign in with ChatGPT. When a user logs in to an outside app with their ChatGPT account, that app’s AI requests are deducted from the user’s ChatGPT subscription. In the keynote, Sam Altman said developers no longer need to cover their users’ token costs.

As I put this news into the AI news brief, I had one question: does this solve the AI cost problem for third-party apps? After reading the official developer documentation, the help center, and the partner directory, and checking where the other providers stand, here is my answer up front.

The door is definitely open. But it is still a narrow door, and both the apps and the users who can pass through it are limited. The premise has changed, but not yet enough to change the design.

This essay first looks at what Sign in with ChatGPT is, then measures how far the door is open from the app side and the user side. Next it compares where Anthropic, Google, and GitHub stand on the same question. Finally it explains how MCP Events, announced the same day, fits into this picture and suggests what you could build with it.

Sign in with ChatGPT Has Two Layers#

The following is based on OpenAI’s developer documentation, the DevDay announcement, and help center articles as of October 2026.

From the name alone, it sounds like a social login such as “Sign in with Google” or “Sign in with Apple.” The first layer is exactly that. But the reason this feature is getting attention lies in the second layer.

Layer One: Identity#

The outside app signs the user in to their ChatGPT account using OpenID Connect, a login standard built on top of OAuth. All the app receives is a stable account identifier plus the user’s name, email, and profile picture. It gets no access to ChatGPT conversations or memory. OpenAI calls this “identity,” and the requested permission scope is openid profile email.

This layer is open to every ChatGPT user worldwide. Free users can sign in, and so can members of Enterprise organizations.

Layer Two: Plan Usage#

If the user grants additional consent, the app receives an access token carrying a separate permission called chatgpt.tokens.use.direct. The app puts this token in a Bearer authorization header and calls OpenAI’s public Responses API directly, and the request is deducted from the ChatGPT Work and Codex usage included in the user’s ChatGPT plan. The app developer needs no API key and no partner key. OpenAI calls this “ChatGPT plan usage” or “token sharing.”

The user side has controls. In the usage screen of ChatGPT settings, users decide for each app whether to allow plan usage, what percentage of their weekly usage the app may consume (from 10% to 100%), and whether the app may draw on credits after the plan limit runs out. The per-app limit is a cap, not a separate allowance, and for Plus users the five-hour limit is shared across all apps.

The separation of the two layers matters. OpenAI repeatedly stresses that signing in and using the plan are “separate permissions.” A user can decline the second layer and use only the first. And if the token the app receives lacks the second permission, inference requests made with that token are rejected.

Measuring the Door From the App Side#

The first thing I wanted to know was whether I could attach this to a web service or mobile app I build today. The developer documentation divides integration into three paths, each at a different stage of availability.

Only the last row is open, because its structure is different. The open-source path starts authorization with client_id=dynamic_agent_client, and the moment the user consents, a client ID is issued dynamically for that app. There is no registration to apply for and no client secret. In exchange, the login callback is fixed to the 127.0.0.1 loopback address, so only a CLI (Command Line Interface) or desktop app running on a machine with a browser can use it. The documentation explicitly says that anyone wanting to offer this in a paid or remotely hosted app should fill out the interest form.

The DevDay announcement spoke of 16 partners, and as of October the partner directory shows the same structure. Apps with plan usage number twelve: Amp Code, Conductor, Dactyl, Devin, Hermes Agent, Hyperagent, Kilo Code, Notion, Vercel, Vorflux, Warp, and Lovable (coming soon). Apps with sign-in only are five: Airtable, Canva, GitLab, HubSpot, and Supabase. Open-source integrations are four: OpenClaw, OpenCode, Pi, and T3. Of the twelve with plan usage, nearly all except Notion are coding agents or developer tools.

This list shows that the picture of “the user’s subscription paying for an outside app” is, for now, a program aimed at the coding-agent market. The fact that the deducted usage comes from the ChatGPT Work and Codex allowance points the same way. The door for general consumer apps exists only as a blueprint so far.

Measuring the Door From the User Side#

Even assuming the app gets approved, a second question remains. How many of that app’s users can actually pay for AI with their own subscription?

The help center states that the option to use a plan in commercial apps is offered “only on Go, Plus, and Pro.” The DevDay announcement named Plus and Pro, and the help center updated in early October added Go. The scope is widening, but members of business plans are still left out.

More important is that OpenAI hands ineligible users over to the app developer. The developer documentation says that when the app receives a token without plan-usage permission, “a coding harness still needs a way to pay for inference,” and tells the developer to offer the choice of enabling plan usage or configuring another billing path such as the user’s own API key. OpenAI also states flatly that it does not silently switch such requests to another billing path.

So the app developer is left with three choices: give no AI features at all to users who are not ChatGPT subscribers (gating), have users enter their own API key (bring your own key), or return to the conventional model where the developer pays API fees and recovers them through its own pricing. The first two cost the developer nothing but narrow the audience.

Looking at what the launch partners actually do gives the answer. As far as I could verify, Warp, Amp Code, Devin, and Notion all kept their own paid plans in place and added ChatGPT plan usage as an extra option. No commercial app made the user’s plan its only source of AI. Sign in with ChatGPT today is not a way to eliminate cost but a way to reduce it by the share of users who are subscribers.

The Preview Also Comes With Feature Limits#

Even after passing through the door, the features you can use are restricted. Responses API calls on the plan-usage path must set store: false and stream: true, and previous_response_id for referencing an earlier response is unavailable, so the conversation history has to be sent in the input every time. Common parameters such as temperature and maximum output tokens are not accepted either.

The tool restrictions are larger. Function tools work, but image generation, file search, Code Interpreter, native computer use, and OpenAI-hosted MCP connectors are not supported on this path. What Sign in with ChatGPT can do today is “lightweight Responses calls running on the user’s wallet.” It is not a channel to OpenAI’s full set of hosted tools.

These limits line up with the principle of subscription economics I inferred in the August essay. A provider can supply compute at subscription prices only when it controls the workload. Even when it opens the plan to outside apps, it has to narrow the scope to simple requests that do not store, that stream, and that avoid hosted tools, in order to keep that control.

Where the Other Providers Stand#

What answers have the other providers given to the same problem? Compared with when I wrote the August essay, the landscape has split more clearly into two camps.

GitHub Copilot: A Door Quietly Opened First#

The surprise was GitHub. The OAuth setup documentation for the Copilot SDK, which reached general availability in June 2026, says: “Copilot requests are made on behalf of each authenticated user, using their Copilot subscription.” The app signs the user in through a GitHub OAuth App, passes the token to the SDK, and the requests go out on that user’s Copilot subscription. There is no partner approval process.

There are conditions. Each user needs an active Copilot subscription, per-user rate limits apply, and token management is the app’s responsibility. And the Copilot SDK is closer to a runtime that embeds the Copilot agent inside your app than to a free-form model API. Still, considering that Copilot is a subscription that carries GPT, Claude, and Gemini models alike, it is interesting that “a third-party app using Claude models on the user’s Copilot subscription” becomes possible by an indirect route.

Anthropic: The Clearest Prohibition#

Anthropic’s Claude Code legal and compliance page currently reads:

Anthropic does not permit third-party developers to offer Claude.ai login into their own applications, or to route requests through Free, Pro, or Max plan credentials on behalf of their users.

Developers building products are told to use API keys, and an app collecting or intermediating a user’s subscription credentials is itself prohibited. This is the exact opposite of Sign in with ChatGPT. The only permitted form is running the unmodified Claude Code binary inside a product and having the end user sign in with their own subscription themselves. The app may not pay for or intermediate that usage.

Anthropic’s policy swung several times this year. According to press reports, subscription OAuth for third-party tools was blocked in January, the prohibition was written into the terms documentation in February, an announcement in May said Agent SDK usage would move to a separate monthly credit, and that change was paused on June 15, the day it was due to take effect. As of early October the support page says that Agent SDK and third-party app usage still draws from subscription limits, but that describes users spending their own subscription in their own tools. A developer attaching users’ subscriptions to their own product remains prohibited, exactly as the legal page says.

In the August essay I wrote that Anthropic keeps subscription limits fenced inside Claude products. In two months that fence has turned into a more explicit sentence.

Google: No Path, and No Answer#

Google is the quietest. In July 2026 an iOS app developer asked on the Google AI developer forum whether there is or will be an official program for third-party apps to use a user’s Google AI Pro / Ultra subscription. The post itself acknowledges that “no sanctioned path currently exists” and notes that unofficial proxying of Gemini CLI tokens had been enforced against. As of October, no reply from Google has appeared.

The Antigravity documentation treats using third-party software with an Antigravity login as a violation of the terms of service. The developer benefits of Google AI Pro / Ultra amount to higher limits inside AI Studio and are not open to outside apps. The “strongest boundary” I observed in the August essay remains in place.

Two Camps#

In short, OpenAI and GitHub have started using the subscription as a distribution channel, while Anthropic and Google keep the subscription exclusive to their own products. The former open the user’s wallet to outside apps to grow an ecosystem; the latter protect the workload control that underpins subscription pricing.

Compared with August, OpenAI’s position has moved the most. Back then, the channel open on OpenAI’s side was roughly “room to automate Codex, the official runtime.” Now it is an official feature with documentation and a partner program. That the entrance to this official feature is still narrow is the point of this essay.

MCP Events: Same Day, a Door in the Opposite Direction#

Alongside Sign in with ChatGPT, the developer section of the DevDay announcement included MCP Events. I grouped the two into one section of the news brief, but technically they are not directly connected features. There is still a reason to put them side by side. Both are handled by developers of ChatGPT plugins, that is, MCP (Model Context Protocol, the standard by which a model connects to external tools and data) servers, and they connect the ChatGPT account to outside apps in opposite directions.

Sign in with ChatGPT is the direction in which an outside app borrows the ChatGPT account. Identity and plan usage flow toward the app. MCP Events is the direction in which ChatGPT reacts to changes in an outside app. Events from the app flow toward ChatGPT. If one plugin developer uses both, the user connects the plugin via Sign in with ChatGPT, and that plugin wakes ChatGPT up via MCP Events. The result is that the OpenAI account becomes the hub for identity, billing, and event reception.

From Pulling MCP to Pushing MCP#

Until now MCP has been a pull model in which the model calls tools. A person talks to ChatGPT, and ChatGPT calls the MCP server’s tools. If something changes on the server side, ChatGPT does not know until someone asks.

MCP Events adds a path in which the server pushes events. Based on OpenAI’s MCP Events documentation, it works like this.

1. The MCP server adds events to its capability declaration and implements three methods: events/list, events/subscribe, and events/unsubscribe.
2. The user tells ChatGPT what to watch and what to do, for example “watch bug reports in this channel and open a draft PR with a fix and tests.”
3. ChatGPT requests a subscription from the server, passing a callback URL and a signing secret. The server verifies the callback with a one-time challenge before it starts delivering.
4. When a matching event occurs, the server sends events one at a time by webhook (an HTTP call the server makes to a designated URL). Signatures use Standard Webhooks HMAC, and the body is limited to 256 KiB.
5. ChatGPT receives the event in the chat where the subscription was made and handles it as the user instructed in advance.

Three constraints are worth knowing. First, it works only in ChatGPT’s Work chats and in dots, not in regular chats. Second, it requires MCP 2.0 (protocol version 2026-07-28) and supports webhook delivery only, with no polling or streaming. Third, events can arrive out of order, and for event types without replay, anything missed during an outage cannot be recovered, so write tools that react to events must be idempotent (producing the same result even when the same request arrives more than once).

It Is Not a Specification Yet#

The OpenAI announcement calls it the “proposed MCP Events specification,” and the link goes to the charter of the MCP Triggers and Events Working Group. Reading the charter makes the feature’s position clear. The working group was formed in March 2026 and is led by engineers from AWS and Anthropic. As of October, the item “SEP: Events in MCP v1” has the status Ideating and its champion is TBD. None of the listed success criteria, an accepted SEP, reference implementations in at least two Tier-1 SDKs, and conformance tests, exists yet.

In other words, ChatGPT has implemented the working group’s draft ahead of time. As far as I could verify, ChatGPT is the only client that subscribes to these events; Claude Code and Cursor do not yet support them. If the specification changes, a server built today may need to be revised.

There is a gap on the security side too. ChatGPT does not support the draft specification’s terminated notification, so even after a user’s permission is revoked, events can keep flowing until the subscription expires. All the server can do is grant short lifetimes, reject indefinite subscriptions, and re-check permissions on a fixed schedule. Remember also that the text of comments or messages carried in the event body goes straight into the agent’s input. OpenAI’s documentation says to treat user-authored text as data only and to test that a task reacting to an event does not modify the originating app’s data in a way that triggers another event, creating a feedback loop.

What You Could Build With MCP Events#

Once the constraints are understood, the right uses come into view. The common condition is that the event happens in an outside app and the reaction is something ChatGPT can do with its connected tools. Four ideas I consider worth trying first:

1. GitHub issues into draft PRs: Attach an issue.created event to your own MCP server and filter by label. When an issue with a specific label appears, ChatGPT reads the repository and opens a draft PR with a fix and tests. This is closest to the example in OpenAI’s documentation, so it is least exposed to specification changes.
2. Applying document review comments: Filter a comment.created event from a document tool such as Notion or Google Docs by document ID. When a reviewer leaves a comment, ChatGPT applies the requested change and replies with the result. This fits a team like my company’s that accumulates documents in Notion.
3. Metric threshold alerts into draft analyses: Define an event such as metric.threshold_crossed on an internal metrics server. When a conversion rate or error rate crosses a threshold, ChatGPT reads the connected dashboards and logs and posts a draft to Slack with hypotheses about the cause and an order of checks. You already receive alerts; turning an alert into a “first analysis” is where this feature earns its keep.
4. News sources into brief drafts: Turn source collection for the weekly AI news brief I write into events. Put an article.created event on the server that aggregates RSS feeds and newsletters, and when a new article arrives, ChatGPT prepares a summary and groups related items in advance. This is also a way to build, on an event basis, the “AI news scout” I named as the first candidate dot in my previous essay.

All four follow the same principles. The event body carries only a summary and the full content is fetched through a read tool; write tools are idempotent; and what ChatGPT produces stays a draft for a person to review. And given that the specification is a draft, separating the event definitions and delivery into a thin layer reduces how much you will have to change later.

I Will Wait, but I Am Not Changing the Design Yet#

The state I wanted was “my service’s AI costs paid by the user’s subscription.” The state I confirmed is missing several pieces of that sentence. Hosted services still require approval, mobile apps have no path, free users and business-plan members cannot pay from their own subscriptions, and hosted tools are unavailable.

So the conclusion of the August essay still holds. Build the cost structure of a third-party service on the API, and treat Sign in with ChatGPT as an additional path that reduces cost by the share of users who are subscribers. Since both camps have changed positions within this year, it is safest to design any subscription-based path so that the API-key path can be restored as the default at any time.

One premise, however, has clearly changed. In August I wrote that a third party using the user’s subscription was the picture providers wanted least. OpenAI and GitHub have turned that picture into official programs. The difference between providers is no longer a difference of policy but a difference of strategy.

Four indicators are worth watching: when hosted commercial apps are opened up, whether Business and Enterprise plans are included, whether Anthropic and Google follow this trend, and whether the MCP Events SEP moves out of Ideating. When two or more of these move, that will be the time to change the design.

This essay is based on public documentation from OpenAI, GitHub, Anthropic, and Google as of October 11, 2026. Plans, eligibility requirements, partner lists, and terms can change at any time.

References#

• OpenAI — Sign in with ChatGPT developer documentation
• OpenAI — DevDay 2026 Recap
• OpenAI Help Center — Using your ChatGPT plan in other apps and sites
• OpenAI Help Center — Sign in with ChatGPT
• ChatGPT Learn — Sign in with ChatGPT partner list
• OpenAI — MCP Events documentation
• MCP — Triggers and Events Working Group charter
• GitHub — Copilot SDK OAuth setup
• Anthropic — Claude Code legal and compliance
• Anthropic Support — Use the Claude Agent SDK with your Claude plan
• Google AI Developers Forum — Gemini subscription access for third-party apps
• Why an AI Subscription Is Not a Cheap API
• A Hand-Assembled Agent Stack vs. OpenAI’s Finished Product — Looking at dots and ChatGPT Space