Repository navigation
Codex Security Plugin - Weekly usage limit dropped from ~75% to 16% in 19 minutes despite only 98,700 total tokens reported #46681
Description
What issue are you seeing?
I believe there is an issue with the weekly usage calculation in Codex.
I am currently on the 5x plan. At the beginning of this Codex session I had around 75% of my weekly usage remaining. After only 19 minutes and 36 seconds, my remaining weekly usage had dropped to approximately 16%.
The strange part is that Codex reported the following token usage for the entire session:
Token usage: total = 9 8,700 input = 92,869 (+ 1,229,952 cached) output = 5,831 (reasoning 1,562)
So within roughly 19 minutes, about 59 percentage points of my weekly limit were consumed, while the CLI itself reports only 98,700 total tokens.
The task being executed was a security audit using the deep scan coordinator. The output also stated that the audit was still running and that the deep scan coordinator had not yet returned its findings. According to the message, the deep scan has a default time budget that can reach 96 hours.
I understand that there are also 1,229,952 cached input tokens shown in the output, but it is unclear whether those are counted against the weekly limit, how they are counted, or whether usage from the deep scan coordinator and its agents is missing from the displayed total value.
If deep scan agents, subagents, cached context, or background processes consume additional weekly usage, that usage should be visible somewhere. Right now the numbers shown by Codex do not appear to explain how my remaining weekly usage could drop from around 75% to 16% in less than 20 minutes.
What steps can reproduce the bug?
Run the Codex Security Plugin on Astra 6 - Medium.
What is the expected behavior?
No response
Additional information
No response
CLI/SDK project triage, October 13, 2026
Scope: explain complete scan usage accurately. This existing report tracks the visibility/accounting discrepancy, distinct from the parent-task resource-control investigation in #46819.
Public issue #46681, September 19, reports remaining weekly allowance dropping from about 75% to 16% in 19 minutes 36 seconds during a plugin Deep Scan using Astra Medium. The displayed total was 98,700 tokens plus 1,229,952 cached input tokens. The report does not establish whether that display covered the parent only, all child sessions, or the same measurement window. It does not prove billing is wrong.
#46819 supplies a related example of stale usage narration: a 6% reading was repeated when later telemetry showed 69%. Its later analytics follow-up attributed the spike across security scans, subagents, and agent-created tasks.
Fix status: no definitive fix for this reported discrepancy was verified. Open PR #465 addresses attributable priced usage, duplicate rollouts, counter resets, and missing receipts. Open PR #1103 addresses per-child usage reconciliation. These are related candidates, not proof that subscription-quota displays or model-written summaries are corrected.
The merged worker-observation PR #962 reports persisted worker sessions. It does not itself reconcile quota units or guarantee current usage narration. Do not reopen its implemented callback work.
Completion: establish which sessions and time window each displayed number includes, use the latest available usage snapshot, and distinguish parent tokens, aggregate child usage, cached input, estimated cost, and account allowance. Mark unavailable totals as incomplete. Validate the user-facing explanation against authoritative telemetry without claiming a conversion between quota and tokens that the system does not expose.
Medium priority. Preserve the original evidence above and resolve this narrower explanation/visibility question alongside, but not as a duplicate of, the resource-control work.

Activity
github-actions commentedon Sep 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action