# Codex Rate Limits Discussion Thread **URL:** \ **Category:** Codex\ **Tags:** rate-limit\ **Created:** [April 4, 2026, 10:54pm UTC](https://community.openai.com/t/codex-rate-limits-discussion-thread/1378553 "2026-04-04T22:54:52Z")\ **Posts on this page:** 1\ **Showing post:** 998
**Author:** ![hortrame](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/hortrame/32/762924_2.png) [@hortrame](https://community.openai.com/u/hortrame)\ **Post date:** [October 8, 2026, 2:13pm UTC](https://community.openai.com/t/codex-rate-limits-discussion-thread/1378553/998 "2026-10-08T14:13:51Z")
Your “5x or 20x of what?” question captures the product-accounting problem cleanly. Even if a disputed event turns out to be ordinary charging, a multiplier over an opaque, behavior-dependent base is difficult to budget or audit. Structured incident records: > > > \# Purpose > > This issue is a public coordination space for users reporting abrupt …changes in Codex/Work usage, Pro value, five-hour or weekly allowance depletion, paid-credit consumption, tier behavior, repeated work, reset behavior, or related accounting/transparency problems. > > It is \*\*not\*\* a declaration that every report shares one cause. Some cases may be explained by concurrent subagents, duplicated context, Priority/Fast service tier, model choice, ordinary charging, or other factors. Those explanations belong here too. > > The goal is to turn scattered anecdotes into comparable evidence without asking people to spend more money reproducing failures. > > \## What we are trying to answer > > 1. \*\*What did the customer buy?\*\* > 2. \*\*What actually consumed the allowance or credits?\*\* > 3. \*\*Can the customer independently reconcile the two?\*\* > 4. \*\*Which cases share a mechanism, and which do not?\*\* > 5. \*\*What provider-side records are needed when the client-side record is insufficient?\*\* > > \## Do not spend money to participate > > Please do \*\*not\*\* buy extra credits or deliberately rerun an expensive failure just to contribute here. > > Natural incidents, existing screenshots, session metadata, logs, support replies, and controlled tests you were already going to perform are enough. > > > > \## Zero-touch agent collection > > If you do not want to fill the incident template manually, give your local AI agent the automation instructions here: > > https://github.com/hortrame-systems/openai\_dispute/blob/main/AGENT\_DATA\_COLLECTION.md > > The collector is designed to run passively from existing local/session evidence. It must not buy credits, rerun failures, alter settings, inspect unrelated data, or publish raw/private material. It can automatically normalize evidence, detect candidate incidents, generate sanitized incident reports, and optionally submit them to this issue after the operator explicitly enables automatic submission. > > \## Minimal incident record > > Copy this block into a comment and fill only what you actually know. > > \`\`\`text > INCIDENT ID: > DATE/TIME: > TIMEZONE: > > PLAN: > SURFACE: Codex / Work / Desktop / other > APP/CLIENT VERSION: > > MODEL: > REASONING LEVEL: > SERVICE TIER / FAST / PRIORITY STATE: known / unknown > PARENT AGENT COUNT: > SUBAGENT COUNT: > > TASK DESCRIPTION (sanitized): > TASK DURATION: > > 5-HOUR ALLOWANCE BEFORE: > 5-HOUR ALLOWANCE AFTER: > WEEKLY ALLOWANCE BEFORE: > WEEKLY ALLOWANCE AFTER: > MONTHLY/RESERVE BEFORE: > MONTHLY/RESERVE AFTER: > PAID CREDIT BALANCE BEFORE: > PAID CREDIT BALANCE AFTER: > > RESET OR RELOAD DURING WINDOW: > KNOWN CONCURRENT WORK: > KNOWN CONTEXT/COMPACTION EVENTS: > > SESSION / THREAD / FEEDBACK ID (sanitized if needed): > SUPPORT CASE: > RELATED GITHUB ISSUE: > > OBSERVED FACTS: > INFERENCES / HYPOTHESES: > ALTERNATIVE EXPLANATIONS: > WHAT WOULD FALSIFY YOUR CURRENT HYPOTHESIS: > > EVIDENCE LINKS: > CORRECTIONS: > \`\`\` > > Unknown fields should stay \*\*unknown\*\*. Do not estimate them just to complete the form. > > \## High-value evidence > > Especially useful: > > \- before/after allowance or credit screenshots; > \- exact local timestamps + timezone; > \- task/session IDs; > \- app/client version; > \- model and reasoning level; > \- whether subagents were spawned; > \- whether Priority/Fast was enabled; > \- sanitized JSONL/log excerpts showing usage or parent/child relationships; > \- support replies; > \- evidence that a dramatic case was actually explained by ordinary charging or configuration. > > Negative evidence is evidence. > > \## Privacy > > Do not post: > > \- credentials or tokens; > \- private prompts; > \- client/customer material; > \- payment-card data; > \- raw account identifiers; > \- secrets or internal business data. > > Sanitize first. Preserve originals privately. > > \## Separate questions that must not be collapsed > > At least four mechanisms may produce superficially similar complaints: > > 1. \*\*Product-value change:\*\* the same subscription provides less predictable or less useful capacity. > 2. \*\*Client/runtime behavior:\*\* repeated work, state loss, unexpected subagents, duplicated context, compaction, etc. > 3. \*\*Tier/pricing behavior:\*\* Priority/Fast selection, model changes, effective credit rates. > 4. \*\*Accounting/reconciliation:\*\* debits or allowance movement that cannot be reconstructed from customer-visible records. > > One incident may involve more than one mechanism. Do not assume it does. > > \## Shared provider-side request > > Where client evidence is insufficient, the useful provider-side fields are: > > \- historical tier/configuration state; > \- authorization provenance; > \- request parentage; > \- request-level usage; > \- account/funding-pool attribution; > \- effective pricing/tier resolution; > \- debit and balance transitions; > \- settlement/reconciliation records. > > Opaque IDs or provider attestations are acceptable where direct disclosure is inappropriate. > > \## Current released reference package > > HORTRAME's minimized public forensic package is one case study, not the master explanation for everyone: > > \- Repository: https://github.com/hortrame-systems/openai\_dispute > \- Zenodo DOI: https://doi.org/10.5281/zenodo.23192953 > \- Public archive SHA-256: \`2735eda6746b271a09526dbda245c706c7cdb3f9df6bc6cb8e9a6d8ad287e67a\` > > It explicitly preserves provider-favorable alternatives and does not claim that a billing defect has already been proved. > > \## What success looks like > > A useful collective result would produce: > > \- a comparable incident index; > \- clusters by version/model/tier/surface; > \- reproducible calculations; > \- documented counterexamples; > \- a correction log; > \- a short common provider-side evidence request; > \- enough portability knowledge that users are not technically trapped; > \- verified corrections/restoration where records show actual errors. > > No one speaks for every participant. No majority vote turns a hypothesis into a fact. Corrections are part of the record. Coordination topic: > [@Codex / Pro usage transparency: community evidence and coordination hub](https://community.openai.com/t/codex-pro-usage-transparency-community-evidence-and-coordination-hub/1404360): > > Many users report abrupt changes in the usable capacity of Codex and Work plans, especially Pro. The immediate question is not whether one universal bug exists. It is: What did I buy? What consumed it? Can I independently reconcile the two? Do not buy extra credits or rerun expensive failures just to investigate this. When an incident occurs naturally, preserve the evidence you already have: date/timezone, plan, client/version, model/reasoning level, service tier if known, parent/subagent coun… Counterexamples and ordinary-charge explanations are explicitly welcome. --- _[View the full topic](https://community.openai.com/t/codex-rate-limits-discussion-thread/1378553)._