OpenAI is building "Subscription sharing" for AI apps

RUNTIMEWIRE INVESTIGATION — Scoop

Original reporting by RuntimeWire, based on reverse engineering.

Why it matters

Subscription sharing could let eligible AI-app interactions draw from a user’s OpenAI allowance, potentially reducing developers’ inference costs while giving OpenAI control over which applications receive access.

Reporting record

The Codex desktop client contains an unreleased settings panel labeled "Subscription sharing." Underneath it, OpenAI's code refers to "ChatPass applications" and prepares to display renewable usage allowances supplied by the company's account servers.

Codex's dormant "Subscription sharing" interface, exposed in a modified local client. RuntimeWire supplied synthetic allowance data to render the shipped component; the image does not represent an active entitlement.

The unreleased feature creates a settings section labeled "Subscription sharing." Copy inside the client tells users the meter shows how much of their subscription allowance is shared with "ChatPass applications." The implementation measures renewable usage windows rather than dollars, transactions or developer earnings.

That makes ChatPass a potential answer to a basic problem facing OpenAI's expanding app platform: who covers the model costs when a third-party application calls OpenAI intelligence on a user's behalf? ChatPass could let the user's subscription supply that compute entitlement, sparing developers from absorbing every inference charge or asking each user for an API key.

The client code does not establish whether ChatPass will serve OpenAI's in-chat plugins, external applications or both. OpenAI has not published ChatPass documentation, eligibility rules or a launch date.

A separate meter for applications

The Codex client fetches account usage through GET /wham/usage, identifying the requesting product with the OAI-App-Brand: chatgpt header. The response schema can include an optional chatpass object containing one or more usage windows.

The following illustrative response shape was reconstructed from fields consumed by the client. The values are synthetic; RuntimeWire did not receive an active ChatPass allowance from OpenAI's server. The reset timestamp reflects the synthetic seven-day test window.

{
  "chatpass": {
    "windows": [
      {
        "used_percent": 0,
        "limit_window_seconds": 604800,
        "reset_at": 1788468559
      }
    ]
  }
}

When the server supplies those windows, the client renders them beneath the separate "Subscription sharing" heading. It converts the percentage consumed into a percentage remaining, recognizes common renewable usage periods, including five-hour, daily, weekly and approximately monthly windows, sorts shorter windows ahead of longer ones and displays each reset time.

ChatPass is kept apart from normal ChatGPT and Codex usage limits, purchased credits and workspace spending controls. The distinction indicates dedicated quota infrastructure controlled by OpenAI's account backend.

RuntimeWire found the implementation in three successive client builds: 26.818.61809, 26.820.60940 and 26.820.71523. It was absent from an earlier build, 26.818.41509, that already contained the app runtime. The sequencing suggests OpenAI first built the machinery for running apps and later added a system for allocating subscription-backed usage to them.

The feature is also localized across 64 language bundles in client version 26.820.71523. No dedicated client-side experiment flag surrounds the panel. Instead, OpenAI's server controls whether it appears by returning or withholding chatpass.windows.

An authenticated request to the same usage endpoint from a Pro account on August 27th omitted the ChatPass object. The shipped client is prepared to display the feature, while the server has not enabled it for that tested account.

The missing economic layer

OpenAI's public plugin architecture allows developers to package skills, server-backed tools and optional interactive interfaces for ChatGPT and Codex. Its plugin UI reference specifies a resource URI that associates a tool with a UI template rendered by the host.

The desktop client separately recognizes app-runtime identifiers including connector_id, plugin_id, canonical_app_id, app_name and resource_uri. ChatPass's usage object does not include those identifiers, at least in the data consumed by the current interface. The meter receives only a percentage used, a window duration and a reset timestamp.

That leaves two supported readings of the architecture. OpenAI could reserve ChatPass allowance for plugins running inside ChatGPT, giving their AI-powered interactions a protected pool of compute. OpenAI could also extend the entitlement to outside applications that authenticate users through ChatGPT.

The second possibility now has public infrastructure beside it. OpenAI's Sign in with ChatGPT lets users access supported external applications with their ChatGPT identity and is rolling out across selected plugins and partner sites. OpenAI says extra application permissions remain separate from the identity flow.

ChatPass could add compute authorization to that relationship. The current code does not connect the two systems, so that remains an inference rather than a confirmed product design.

This is not a developer payout system

Nothing in the implementation resembles a payment product. ChatPass has no prices, currency fields, checkout sessions, payment methods, merchant records, transaction histories or balances payable to developers.

OpenAI's current plugin rules allow commerce only for physical goods and prohibit plugins from selling digital services, subscriptions, content, tokens or credits. The checkout documentation says developers remain responsible for monetizing their experiences and generally send eligible purchases to checkout on their own domains.

ChatPass therefore appears to determine which OpenAI allowance pays for an application's intelligence. The code offers no evidence that OpenAI will compensate developers or share subscription revenue with them.

That narrower function would still remove a material obstacle for app developers. AI applications face variable inference costs that rise with usage. A subscription-backed entitlement could shift some of that cost to OpenAI while giving paid ChatGPT users a portable allowance across supported software.

Usage without attribution

The current interface also exposes an accountability gap. It can tell users that applications are consuming shared subscription allowance without identifying which application used it.

The panel does not render an application name, plugin identifier, connector identifier, per-app consumption figure, consent record or revocation control. A user could see that a weekly sharing limit has 31% remaining and receive no explanation of which applications consumed the other 69%.

OpenAI may hold attribution and authorization data elsewhere. Sign in with ChatGPT already records application identifiers and approved permissions, according to OpenAI's help documentation. The ChatPass panel found in the desktop client does not surface comparable controls.

The implementation also appears to sit above Codex's native rate-limit system. RuntimeWire found no ChatPass string in the Codex engine binary or its generated app-server rate-limit schema. Live rate-limit responses exposed existing Codex buckets without returning ChatPass. The available evidence places ChatPass in ChatGPT account infrastructure surfaced through the desktop shell.

OpenAI has built enough of the system to ship the meter, translations and server-controlled visibility. What remains unresolved is the product boundary: which applications qualify, which subscription plans provide an allowance, whether users must authorize each app, and whether administrators can disable sharing. The code shows the quota layer. OpenAI has yet to show users who will be allowed to spend it.