Think of a row in that table as a client-side join rather than an invoice. The four columns are the local chat title, its percentage of the five-hour limit, its percentage of the weekly limit, and credits used, sorted by weekly usage unless you pick another field [8]. The percentages are lifetime consumption measured against your current full limits, which is why a conversation spanning several allowance windows can read above 100 percent, and why nothing in the table tells you what is left in the window you are in right now [9].
That denominator is the part to internalise before you compare two rows. It is today's limit, not the limit in force when the work ran [9]. Two chats are only comparable to each other if your allowance did not change across both their lifetimes.
The genuinely useful engineering is one level down. Expanding a row can surface the product, model, reasoning effort, speed and funding source behind the usage [11], and the funding labels separate plan usage, credits, a mix of the two, and tasks that drew down neither [12]. OpenAI's own Codex plan documentation already says consumption varies with model, task complexity, context, reasoning, speed and tools [19]. This is the first place those variables sit on the same line as the number they moved. A distinct label for a task that cost nothing is the sort of thing you only add after somebody asked why a run was free.
Subagent runs are where the attribution logic has to do its hardest work. OpenAI's current documentation warns that usage attributed to a Work or Codex chat may omit work delegated to subagents or run as separate tasks [13]. Build 7868 adds a path that discovers subagent conversations associated with a root chat and asks for their usage as one group, then attaches the result to the originating conversation [14]. The implementation does not guarantee complete attribution, and chats can be omitted when the application cannot fully identify them [15]. An omission arrives as a smaller percentage; the four columns carry no completeness field [8]. Treat each figure as a floor.
Locality matters too. The route ranks up to 100 recent Work and Codex chats [2], and the existing Enterprise Usage and billing dashboard's Top consuming chats ranks locally available conversations by lifetime credit use [16]. A per-seat client view stays scoped to one seat, unlike a workspace view.
Whether anyone can open this is the weakest link in the story. Account conditions and server-controlled gates decide whether the route appears, internal descriptions call it a preview for selected Enterprise and Education members, and RuntimeWire could not confirm activation for customers [18]. The route itself is called Consumer view [2]. Names inside a build are written for the people writing the build.
The evidence is a build diff: RuntimeWire compared consecutive production builds and read the new interface and supporting logic [3], in desktop 26.901.31953 with internal build 7868 and bundled backend 0.153.1, published September 4, 2026 [4], with a published app.asar hash over roughly 285 MiB of bundle [5][21]. The finding was partially reproduced [6], the screenshot is a reconstruction on synthetic data [23], and OpenAI had not responded to a comment request by publication [7]. So: the code is in a shipped binary, and its behaviour for a real account is untested from outside.
For these percentages to transfer to your capacity planning, your limits have to have held steady across the chats being compared, and every child conversation has to have resolved on the machine you are looking at. If both hold, you have a triage ranking [22]; if either fails, what you have is a lower bound wearing a confident-looking percent sign.
