Repository navigation
Account-wide Codex usage attribution by client, session, and timestamp #28985
Description
What variant of Codex are you using?
Web / CLI / OAuth-backed clients
This request concerns the shared Codex usage accounting exposed through ChatGPT/Codex usage surfaces and authenticated usage endpoints. It is not limited to one local client, because the quota is shared across clients/devices using the same account.
What feature would you like to see?
Please add account-wide Codex usage attribution so users can understand what consumed their shared 5-hour and weekly Codex usage quota.
Today the usage surfaces/endpoints expose aggregate counters such as:
- 5-hour used/remaining percentage
- weekly used/remaining percentage
- reset times
But users cannot determine which client, device, session, or background process consumed the quota. This makes it difficult to diagnose quota drops when the same ChatGPT/Codex account is used across multiple surfaces, for example:
- Codex Web / ChatGPT Codex sidebar
- Codex Desktop / mobile app surfaces
- Codex CLI on one or more machines
- IDE extensions
- OAuth-backed third-party/local tools
- background work such as indexing, memory generation, retries, summarization, or reconciliation
Requested capability:
- Provide an account-wide usage event log or breakdown for Codex quota windows.
- Make it filterable by the same 5-hour and weekly windows used by the quota meters.
- Include, where available:
- timestamp
- client/source, e.g. Web, Desktop, CLI, IDE Extension, OAuth client
- device or installation identifier, preferably user-friendly but privacy-preserving
- model
- session/thread/task id
- foreground user request vs background/retry/indexing/memory/summarization work
- charged usage units or at least percentage impact per event/window
- whether prompt/cache/tool/context usage was involved if that affects weighting
- Surface this in ChatGPT/Codex Analytics and/or the Codex usage UI.
- Ideally expose the same breakdown through an authenticated API endpoint for users who run multiple local clients and need to reconcile local logs with account-wide quota state.
The goal is not necessarily to expose sensitive prompts or content. Even metadata-level attribution would be enough to answer the basic operational question:
What consumed my Codex quota, from where, and when?
Additional information
A local client can only prove its own activity. It cannot prove what happened account-wide.
For example, a local agent integration may be able to log that it used Codex for a specific turn, or that it did not use a specific local profile in a time window. But if the shared account quota drops anyway, the current aggregate usage data cannot distinguish between:
- another Codex client on the same machine
- Codex CLI on a different machine
- ChatGPT/Codex Web
- desktop/mobile app background activity
- IDE extension activity
- another OAuth-backed tool using the same account
- delayed quota reconciliation
- retries or background memory/indexing work
This creates support/debugging ambiguity. Users are left guessing whether quota was burned by their current client, a background task, another device, or an accounting issue.
Related issues that appear to point at the same observability gap, even when framed as quota drain or quota desync reports:
- Codex Desktop open → 5-hour usage decreases after reset despite no active task, no CLI, and no credit-history event. #21966 — idle/desktop quota decreases and explicitly notes lack of attribution/visibility
- Codex usage quota decreases slowly even when I am not actively using Codex #26600 — quota decreases without active usage and asks for detailed usage by session/thread/time range
- Pro weekly usage limit depletes unusually fast on 5.5, worsened by unstable context compaction #19585 — weekly usage depletes unusually fast and asks for detailed usage breakdowns
- Codex quota was exhausted again during a short working session. #28727 — asks for exact charged operations, timestamps, source/client, task/session id, and background/retry/indexing attribution
- Codex 5-hour usage meter appears to consume much faster than comparable historical usage #28823 — compares local usage telemetry with the Codex meter and asks for clarification on accounting changes
There also appears to be local usage-attribution work in the repo, such as #24121 and #24122. That looks useful for local Codex clients, but this request is specifically for shared account-wide quota attribution across all clients/devices that can consume the same Codex allowance.
Expected outcome:
Users should be able to open the Codex usage/analytics surface and answer:
- Which app/client consumed quota during this 5-hour window?
- Was the usage foreground or background?
- Which session/thread/task did it correspond to?
- Did a different device or OAuth client consume the account quota?
- Why did the aggregate 5-hour/weekly percentage move even though a specific local client was idle?
This would make existing quota-drain reports diagnosable without requiring each client/integration to guess from incomplete local logs.
Activity
github-actions commentedon Jun 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Necmttn commentedon Jun 21, 2026
Attribution needs to separate billing/quota truth from local transcript estimates. Useful fields: account window id, client surface, device id, native session/conversation id when available, request id, model, started/ended timestamps, quota units charged, token buckets, and
source=server_account_ledger.Local clients can attach transcript ids later, but account usage should not be inferred from JSONL alone. That would let users explain quota drops by client/session without double-counting background tasks, retries, or MCP startup.
Generated with ax.
phtrillaud-netizen commentedon Sep 1, 2026
I support this request for usage attribution by client, session, conversation, and timestamp. Our experience adds a complementary need: the interface should clearly distinguish the amount remaining from the rate at which it is being depleted.
I am an advanced individual user, but I do not have a strong computer-science background. With Codex’s assistance, I can conduct several documentary, technical, and organizational projects, sometimes with multiple active conversations running in parallel. In that situation, a single aggregate remaining percentage does not show:
This lack of attribution also has an economic consequence. We tested approximately €100 of additional credits to continue important work and explore faster settings. The additional capability was real, but the credits were exhausted without giving us a clear way to connect the expenditure to specific conversations, settings, or the amount of useful work obtained. The problem was not simply the price. It was the inability to predict and control what had been purchased.
In addition to the event log requested in this issue, a useful representation could show:
Color would therefore not simply indicate that a gauge is approaching zero. It could show that one task is currently consuming capacity faster than the others and may soon exhaust the available pool, even while that pool is still relatively full.
We have prepared visual representations that separate the amount remaining from the consumption rate, as well as a complementary proposal for a capped per-task budget. No attachment accompanies this comment. These materials could be shared later as a separate action if the team requests them and after a new privacy review.
— Philippe Trillaud & Codex