Usage limits deplete unusually fast with mostly cached input

What version of Codex CLI is running?

• Codex CLI: 0.152.1

What subscription do you have?

The work consisted mainly of reading and editing local Markdown files, analyzing documents, running shell commands, and generating a small PDF. No sub-agents or image-generation tasks Cached context and routine tool interactions should not exhaust almost the entire 5-hour allowance during this workload.

Which model were you using?

• Model: gpt-5.6-sol

What platform is your computer?

Linux x86_64

What terminal emulator and version are you using (if applicable)?

Tabby Terminal

Codex doctor report

Codex Doctor v0.152.1 · linux-x86_64

  Environment
    [ok] system       C
    [ok] disk         sufficient free disk space
    [ok] security     endpoint protection is not inspected on this platform
    [ok] runtime      npm installation on linux-x86_64
    [ok] install      consistent
    [ok] search       bundled search available
    [ok] git          git version 2.53.0
    [ok] terminal     TERM=xterm-256color
    [ok] state        databases healthy
    [ok] threads      rollout files and state DB thread inventory agree

  Configuration
    [ok] config       loaded
    [ok] auth         ChatGPT authentication is configured
    [ok] mcp          1 server · 0 disabled
    [ok] sandbox      restricted filesystem and network · approval OnRequest

  Updates
    [ok] updates      current version is 0.152.1

  Connectivity
    [ok] network      no proxy environment variables
    [ok] websocket    connected (HTTP 101 Switching Protocols)
    [ok] reachability active provider endpoints are reachable over HTTP

  Background Server
    [--] app-server   not running (ephemeral mode)

  19 ok | 1 idle | 0 warn | 0 fail

What issue are you seeing?

During one Codex CLI session, the displayed 5-hour usage increased from 0% to 98% in approximately 2 hours and 14 minutes.

Timeline from local Codex telemetry:

• 2026-09-02 18:10:12 UTC: 5-hour usage 0%, weekly usage 59%
• 2026-09-02 20:24:38 UTC: 5-hour usage 98%, weekly usage 74%

At that point, cumulative token telemetry for the session showed:

• Input tokens: 23,383,708
• Cached input tokens: 22,627,328
• Output tokens: 117,455
• Reasoning tokens: 27,761
• Total tokens: 23,501,163

Approximately 96.8% of the input was reported as cached. Several later interactions showed approximately 140,000–158,000 input tokens each, with most of them marked as cached.

The workload consisted mainly of analyzing local Markdown documents, targeted extracted text from two PDFs, running shell commands, and generating a PDF. No image generation or
subagents were used.

This may be explainable by the unusually long conversation context repeatedly being included in requests. However, the rate-limit consumption still appeared unexpectedly fast given the
high cached-input percentage.

There is also a possible account/workspace meter mismatch: support reported seeing 0% usage on a monthly Codex window for the account available to them, while the CLI showed Team-plan
5-hour and weekly limits.

What steps can reproduce the bug?

Uploaded thread: 01a0634f-68e9-72d1-a54f-950a072290ff

What is the expected behavior?

The CLI usage meter and the usage information visible to support should correspond to the same authenticated workspace and rate-limit window.

Cached input should be accounted for according to the documented discounted cached-token rate. If repeatedly sending a large conversation context can legitimately consume nearly the
entire 5-hour allowance in about two hours, the CLI should provide enough information to explain that consumption clearly.

At minimum, the reported usage should be internally consistent across the CLI and the account/workspace meter, and it should be possible to determine whether the consumption came from
cached input, uncached input, output, reasoning, or another operation.

Additional information

Uploaded feedback thread ID:
01a0634f-68e9-72d1-a54f-950a072290ff

Environment:

• Codex CLI: 0.152.1
• Model: gpt-5.6-sol
• Reasoning effort: medium
• Plan shown by CLI telemetry: Team
• Authentication: ChatGPT sign-in, not an API key
• Service tier: default
• Fast mode: not active
• Platform: Linux x86_64
• Proxy: none
• Codex Doctor result: 19 ok, 1 idle, 0 warnings, 0 failures

The session had a long accumulated conversation history and worked with approximately ten primary text documents plus targeted extracts from two large PDFs. Full PDF files were not
permanently pinned in context, but substantial conversation and tool output had accumulated.

There were 184 local token-count telemetry events during the session. These should not necessarily be interpreted as 184 separate model requests.

After the 5-hour meter reached 98%, I intentionally used one available manual limit reset so I could complete the task. Therefore, the immediate counter change from 98% to
approximately 1% was expected and is not the reported bug.

I am asking for verification of:

1. Which workspace/account the CLI usage was attributed to.
2. Whether the cached-token accounting shown above correctly explains the 98% consumption.
3. Whether a long, insufficiently compacted context caused approximately 140k–158k tokens to be resent on each interaction.
4. Why support sees a monthly 0% meter while the CLI showed Team 5-hour and weekly meters.

The full workspace and organization identifiers can be provided privately if needed; I have omitted them because GitHub issues are public.

Start with the uploaded feedback thread 01a0634f-68e9-72d1-a54f-950a072290ff and the session's local telemetry, including the 184 token-count events. Compare the CLI's Team-plan meters, cached and uncached token totals, and the support-reported account meter; done means the attribution and accounting discrepancy is explained or reproduced with clear evidence.