The schema is where the design shows. Each window carries three fields, `used_percent`, `limit_window_seconds` and `reset_at` [4], and the client's whole job is to turn consumption into a remaining percentage and print a reset time [6]. Nothing in the payload states tokens, requests or dollars [5]. The denominator lives on the server. A user reads sixty percent left, and the payload never says of what. A meter denominated in percent is convenient for the party that decides what one hundred percent means.
The window sizes say the same thing. The illustrative payload RuntimeWire reconstructed sets `limit_window_seconds` to 604800 [7], which is 604800 / 86400, or seven days [8]. The client also recognises five-hour, daily and roughly monthly periods, accepts an arbitrary number of windows at once, and sorts the short ones above the long ones [9]. Several windows at several timescales against one entitlement amount to a rate limiter. It caps how much a single app can draw in five hours as well as in a week, which is the control you need before you let someone else's code spend an allowance you have already sold at a flat price.
For that to reach a developer, the server has to attribute a call to an app and then decide whether that app's user has a window. The client already parses `connector_id`, `plugin_id`, `canonical_app_id`, `app_name` and `resource_uri` [11], and OpenAI's published plugin reference already lets a tool ship interactive UI through a resource URI [12], which is why RuntimeWire calls the mini-app connection plausible rather than proven [13]. The client code does not say whether ChatPass would cover in-chat plugins, external applications, or both [14].
RuntimeWire reproduced the finding in build OpenAI.Codex_26.820.9563.0_x64 [16], rendering the panel by feeding synthetic allowance data to a modified local client after receiving no active allowance from OpenAI's servers [15]. That leaves the rendering code inspectable by anyone with the build, and the entitlement logic entirely inside OpenAI. RuntimeWire's own framing is conditional: eligible interactions could draw on a user's allowance, cutting developer inference cost and giving OpenAI a say over which applications get access [19].
Before sizing a product around it, I would want the account server to return `chatpass` windows for calls attributed to someone else's app, the attribution keyed to a stable app identifier rather than a user session, and the denominator published so an app can tell a user what one action will consume. None of that is documented today [17], and the company had not responded to RuntimeWire by publication [18]. Until it is, the two options are the ones already on the table, absorb the API charge yourself or ask each user for a key [20].
