›_ Codex Issues
Codex Issues / #36468

Weekly usage drains rapidly after reset on GPT-5.6 Sol, with dashboard/rollout discrepancy

Open 💬 4 comments Opened Aug 1, 2026 by FlowTether
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.146.0

What subscription do you have?

ChatGPT Pro 20x

Which model were you using?

GPT-5.6 Sol

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Codex Windows desktop app with integrated PowerShell 7.6.3

Codex doctor report

My weekly Codex allowance was reset to 100% on August 1, 2026. It then fell to 91% between approximately 08:56 and
  13:35 CEST during one local GPT-5.6 Sol engineering session.

  The session used two bounded Codex subagents, but no broad swarm. The previous weekly allowance had also been nearly
  exhausted in approximately 1–1.5 days, requiring me to purchase $40 in additional usage simply to obtain a handover
  and continue working.

  I also observed a possible telemetry discrepancy: a local rollout snapshot showed 7% weekly usage while the account
  dashboard showed 9% consumed.

  This appears related to #35816, but I am reporting a new occurrence because it happened immediately after an allowance
  reset, on GPT-5.6 Sol, and includes differing local and dashboard usage readings.

What issue are you seeing?

Steps to reproduce

  1. Begin with the weekly Codex allowance showing 100% remaining after a reset.
  2. Run one long local engineering session using GPT-5.6 Sol.
  3. Use two bounded subagents without a broad parallel swarm.
  4. After approximately 4.5 hours, observe that the dashboard shows 91% remaining.
  5. Compare the dashboard with the local rollout rate_limits.primary.used_percent value, which showed 7% used.

What steps can reproduce the bug?

Uploaded thread: 019fbc17-cc7a-7f92-a88a-cf64eb9330f5

What is the expected behavior?

Usage should decrease predictably and be attributable to the main thread, context, cached input, reasoning, tool
results, and subagents. Local rollout telemetry and the account dashboard should also reconcile or clearly document
why they differ.

Additional information

This rapid consumption recurred immediately after the allowance was reset. Please inspect the account-level telemetry
associated with the uploaded feedback thread. I will not post account identifiers or billing details publicly.

Then preview it once, make sure no email address or other private account information appears, and submit. It may be
marked related to or duplicate of #35816, but the uploaded thread ID gives OpenAI your specific diagnostic record.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 26 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35816
  • #35463

Powered by Codex Action

zac343 · 26 days ago

The 7% rollout value and 9% account dashboard value should be treated as two snapshots of a server-reported meter, not as two independently metered costs. If their timestamps differ, delayed reconciliation can create a gap even when the local session data is internally consistent.

A bounded local check for this case is:

  1. Group the root session and both child-session rollouts as one workload, but count usage deltas only once. A child transcript copied into an ancestor is evidence of replay, not a second provider charge.
  2. For each assistant turn, retain timestamp, session alias, actual model, input, cache-read, output/reasoning usage, recorded cost, status, and parent/root relationship. Do not infer spend from context-window size.
  3. Separate main work from child work, failed turns, background activity, and blocking waits. Then compare the cumulative local timeline with every rate_limits.primary.used_percent observation.
  4. If the meter jumps between two local requests, label that interval “server reconciliation not locally attributable.” If local deltas explain only 7% while the dashboard reaches 9%, the missing 2% remains an account-ledger question for OpenAI rather than evidence that either subagent alone caused it.

I added a Codex sessions-folder path for this comparison here: https://mailcheck.agentcartai.com/tools/agent-cost-auditor/?platform=codex&utm_source=github&utm_medium=issue-reply&utm_campaign=codex-weekly-subagent-usage-36468

The free analysis runs in the browser and does not upload prompts, messages, API keys, or raw rollout files. It can separate root/child and replayed usage, but it cannot inspect OpenAI's server-side credit ledger. The optional shareable evidence report is 1 USDC on Base Mainnet.

Disclosure: I operate AgentCart AI and built the linked auditor.

FlowTether · 25 days ago

## Major update: Fast/Priority was silently enabled

Today, August 3, the Codex tray unexpectedly showed that GPT-5.6 Sol was running in Fast mode. I had never
knowingly enabled Fast mode, did not know the /fast command existed, and would never have voluntarily selected a
higher-consumption tier while already struggling with rapid weekly-allowance depletion.

Inspection of my global Codex configuration found this persisted setting:

service_tier = "priority"

OpenAI’s documentation says that Fast maps to the priority request tier. It also says that GPT-5.6 Fast provides
approximately 1.5× model speed while consuming credits or included allowance at 2.5× the Standard rate:

https://learn.chatgpt.com/docs/agent-configuration/speed

### Local evidence

  • My retained Codex input history contains no /fast command before the /fast off and /fast status attempts made

today after discovering the problem.

  • A preserved configuration backup confirms that service_tier = "priority" existed no later than **July 27 at 11:03

Berlin time**.

  • The active Sol rollout covering that time was waiting on a test suite and contains no agent tool call that edited

the global Codex configuration.

  • Retained thread metadata subsequently records service_tier: "priority" being applied to GPT-5.6 Sol sessions.
  • The global configuration was rewritten again on August 2 and silently preserved the Priority setting.
  • I did not see a Fast indicator in the tray until today.
  • The normal /status display does not report the service tier at all.
  • My configured status line also did not include a Fast-mode field, meaning the higher-consumption tier could remain

active without any persistent warning in the ordinary status information I was monitoring.

After discovering this, the Priority override was removed directly from config.toml and the configuration was
verified to contain no remaining service-tier override.

This is not merely a cosmetic UX issue. A setting that multiplies GPT-5.6 allowance consumption by 2.5× was persisted
globally without my informed consent and without reliable visibility in the authoritative /status display. I spent
days watching my allowance disappear at an alarming rate, exhausted almost an entire weekly allowance in approximately
1–1.5 days, and purchased $40 in additional usage because I believed something was wrong with the meter. At no point
was I clearly warned that my requests were being charged against the allowance at 2.5× Standard.

The previously reported 7% local-versus-9% dashboard discrepancy may still involve delayed server reconciliation, but
that is now secondary. The silently enabled Priority tier provides a highly material explanation for the overall
depletion and creates a separate consent, configuration, and disclosure defect.

Please investigate:

  1. Exactly when, how, and through which client action or migration service_tier = "priority" was added to my global

configuration.

  1. Whether a model selection, application update, catalog refresh, migration, or UI-state save can enable or preserve

Fast without an explicit /fast command.

  1. Which requests on my account were charged at the Fast multiplier, with a Standard-versus-Fast usage breakdown.
  2. Whether my allowance and the $40 in purchased usage should be restored or reimbursed if Fast was enabled without

explicit informed consent.

  1. Why /status does not disclose the current service tier.
  2. Why enabling a 2.5× consumption mode does not require an explicit confirmation showing the multiplier.
  3. Why Fast can remain globally active without a continuously visible warning in every relevant status surface.

A 2.5× consumption tier should never be silently persisted in an opaque configuration field. It should require
explicit opt-in, display the exact multiplier before activation, remain conspicuously visible while active, appear in
/status, and be itemized in usage telemetry.

Please do not close this as merely a duplicate or ordinary reconciliation delay until the account-level ledger and the
origin of the Priority configuration have actually been examined.

I will not upload sensitive rollout files to the unrelated third-party promotional auditor linked in another comment.
OpenAI already has the uploaded diagnostic thread and access to the server-side ledger needed to investigate this
properly.

[written by codex because I was too spitting angry to be coherent - I had him check his own log of work to ensure that we are showing this ticket with evidence and not my gut feeling that this is all very wrong.]

FlowTether · 25 days ago

> Corrective diagnostics were submitted from the Aster Sol thread. The immediately preceding feedback submission was
> truncated; please disregard its message body. The corrected submission documents the hidden service_tier="priority"
> setting and missing /status visibility. thread ID 019fbc17-cc7a-7f92-a88a-cf64eb9330f5