Usage Limits on KnightLi Blog

Why Did Codex Usage Limits Suddenly Reset? History and Sources

Sun, 17 May 2026 08:36:15 +0800

Codex users sometimes see an odd situation: their usage limits recover even though their normal reset time has not arrived. This kind of unexpected reset is not new, and it does not necessarily mean the quota policy has permanently become more generous. It may come from incident compensation, product promotions, growth milestones, or a backend reset that only applies to certain windows or account states.

This screenshot comes from a post on X by Tibo Sottiaux (@thsottiaux), who leads the OpenAI Codex team. For users tracking limits, the key point is not the model detail but the line saying he would reset usage limits that evening. The context suggests this was a compensating reset, not a normal scheduled refresh.

Short Version

Sudden Codex usage limit resets usually fall into several categories:

Incident compensation: a Codex or model issue wastes user quota, so OpenAI resets limits to make up for it.
Launch or promotion events: a new model, client, or feature ships with temporary extra capacity or a reset.
Growth milestones: OpenAI resets or raises limits after Codex reaches a user-growth milestone.
Backend policy changes: only some quota windows or account states are reset, and the UI may not explain the scope.

The most common misunderstanding is assuming that “reset” means every visible quota window recovered. In practice, Codex may have short rolling windows, weekly limits, model-specific consumption weights, and plan-specific rules. A special reset may only affect part of that system.

What This Screenshot Shows

The screenshot shows Tibo posting an update on May 15, 2026, saying the team would continue monitoring and reset usage limits that evening. It quotes an earlier message saying the team was investigating reports from some users.

For users, there are three practical takeaways:

This was not a normal user-specific reset cycle; it was an active reset by the team.
The reset had a specific event context and was not a permanent limit increase.
The phrase “usage limits” does not by itself clarify whether both short windows and weekly limits were included.

So if your quota recovered, treat it first as a special reset event, not as evidence that future limits have changed.

Why Codex Resets Can Feel Unexpected

Codex limits are not simply “refreshed at a fixed time every day.” The backend may track several things at once:

Short usage windows, such as a few-hour window.
Weekly or longer-period limits.
Different consumption weights for different models.
Different entry points such as local Codex, Cloud Tasks, IDEs, and the CLI.
Plan differences across Plus, Pro, Business, and Team.
Whether an account is eligible for a special reset.

When OpenAI applies a special reset, the UI may not clearly say whether it was a normal cycle refresh or a special compensation event. If only the short window resets, users may assume the weekly limit should also recover. If the weekly limit does not move, it can look like the reset failed.

An issue in the OpenAI Codex GitHub repository raised the same transparency problem: public messaging said Codex rate limits had been reset, but the product UI did not clearly show which windows were reset, whether the weekly limit was included, or whether all paid plans were affected equally.

Historical Patterns

1. February 2026: Launch Period and Temporary Extra Capacity

During the Codex desktop app and GPT-5.3-Codex promotion period, community users discussed usage limit resets and temporary 2x rate limits. Reddit users mentioned that the Codex app launch came with limited-time 2x rate limits and a usage limit reset.

This kind of reset looks more like a launch-period operation: encourage people to try the new client, model, or workflow.

2. March 2026: Random Resets and Abnormal Consumption

Around March, the community repeatedly discussed “random usage reset” and “weekly limit reset daily” behavior. Some users said their weekly limit recovered early, while others connected the behavior to new Codex models, safety blocks, abnormal quota burn, or bug fixes.

These discussions are not official announcements, but they show that users had already observed Codex limits recovering outside their normal schedules.

3. April 2026: Growth Milestones and Paid-Plan Resets

In late April, public reporting said Codex had reached 3 million weekly active users and that OpenAI reset rate limits, with plans to give users more room at later growth milestones.

A GitHub issue also cited a Tibo post from April 28 saying he had reset Codex rate limits for paid plans after a “good week,” so users could build more with GPT-5.5. The same issue noted that the product UI did not clearly explain which quota windows were actually reset or whether the weekly limit was included.

This shows why activity-based resets can still cause confusion: users may hear broad wording but see different behavior in their own account.

4. May 2026: Compensation Reset

The screenshot in this post is a clearer example of a compensation-style reset. Tibo said the team had found issues and would reset usage limits that evening. OpenAI Status also recorded Codex-related elevated errors and degraded latency on May 13, 2026.

For ordinary users, the point is not which model detail caused the issue. The key lesson is that OpenAI may reset limits when a service-side problem causes users to burn quota abnormally.

How to Interpret a Sudden Reset

If your Codex quota suddenly recovers, check in this order:

Confirm whether your normal reset time had arrived.
Check OpenAI Status for Codex incidents, model errors, latency, or degraded performance.
Look for updates from Tibo, OpenAI accounts, or Codex GitHub issues.
See whether community users are reporting the same reset, abnormal burn, or weekly-limit confusion.
Separate short-window resets from weekly limits; do not assume they always move together.

If it is official incident compensation, there is usually a status-page entry, a team announcement, or a cluster of user reports. If it is only a partial backend refresh, there may be no clear public announcement.

How Reliable Are the Sources?

It helps to separate sources by reliability:

OpenAI Status: best for confirming service incidents, error rates, latency, and recovery times.
Tibo / OpenAI official accounts: useful for special reset, compensation, or promotion messaging.
OpenAI Codex GitHub issues: useful for seeing user reports about UI behavior, quota windows, and actual product behavior.
Reddit / X discussions: useful for spotting broad user patterns, but not official confirmation.
Third-party news or blogs: useful for timeline context, but should be checked against original sources.

When writing or making decisions, keep these layers separate. “OpenAI Status recorded an incident” is an official status signal. “Reddit users reported random resets” is community observation. “A GitHub issue reported unclear UI behavior” is a user-submitted product issue.

Summary

A sudden Codex usage limit reset is usually not just “free quota from nowhere.” It may come from incident compensation, launch promotion, growth activity, or a backend policy update. The confusing part is that Codex has multiple quota windows, and a special reset may not include all of them. The UI may also fail to show the reset scope clearly.

When it happens, check your actual client-side quota first, then compare it with OpenAI Status, Tibo’s posts, Codex GitHub issues, and community reports. Do not assume one reset means the long-term rules have changed, and do not assume weekly limits, short windows, and every plan all reset together.

References:

How Codex Usage Limits Work: 5-Hour Limits, Weekly Limits, and Credits

Wed, 15 Apr 2026 22:50:00 +0800

When people first look at Codex usage limits, it is easy to assume that the 5-hour limit is a short-term balance, and that the weekly limit only starts decreasing after the 5-hour quota is used up.

That is not how it works. Codex is better understood as checking multiple limit windows at the same time: a short window prevents burst usage, while the weekly window controls total usage over the week. A Codex request usually counts against both.

So this situation is usually normal:

1
2

5-hour quota still has plenty left
but weekly quota has already decreased

01 The Short Version

You can understand Codex usage with three rules:

The 5-hour limit and the weekly limit apply at the same time.
If the weekly limit is exhausted, you usually cannot continue using the same subscription quota pool even if the 5-hour quota still has room.
Codex is not priced by simple message count. Usage depends on the model, tokens, task complexity, context size, and execution location.

In pseudocode:

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && no other product policy is triggered

When the 5-hour window resets, only the 5-hour quota is restored. It does not restore weekly quota. Weekly quota resets on its own schedule, or you may be able to buy extra credits on supported plans.

02 Why Both Windows Decrease

Think of Codex limits as two gates:

Window	Purpose
5-hour window	Prevents high-frequency burst usage
Weekly window	Controls total weekly usage

Each Codex task creates real usage. That usage is reflected in the relevant rate limit windows.

It is not:

1
2
3

Use 5-hour quota first
After the 5-hour quota runs out
Start using weekly quota

It is closer to:

1
2
3

One Codex request
=> counts toward the 5-hour window
=> also counts toward the weekly window

That is why weekly usage can drop even when the 5-hour quota is not exhausted.

03 Look at Token-Based Credits

OpenAI does not publish a formula that lets users fully reproduce the exact Codex charge. What is public is the rate card, the main factors, and per-model credit pricing.

As of 2026-04-15, the main Codex rate card model is token-based credits. Usage is estimated from input tokens, cached input tokens, and output tokens.

Example official rates:

Model	Input / 1M tokens	Cached input / 1M tokens	Output / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

A rough estimate is:

usage
≈ input tokens / 1,000,000 × model input price
+ cached input tokens / 1,000,000 × model cached input price
+ output tokens / 1,000,000 × model output price

This is not an exact billing formula, but it explains the trend: output is expensive, long context is expensive, and stronger models cost more. The official rate card also says Fast mode uses 2x credits, and Code review uses GPT-5.3-Codex pricing.

04 Do Not Only Count Messages

Ten Codex messages can consume very different amounts.

Light tasks are usually cheaper:

Editing one small function
Explaining a short code snippet
Writing a short paragraph
Making a local change in a clearly specified file

Heavy tasks cost more:

Scanning a large codebase
Running a long agent session
Repeated read, edit, test, and fix loops
Generating lots of code or a long report
Using cloud tasks
Enabling fast mode

So message count is only a rough feeling. It does not tell you the real usage.

05 Local Tasks vs Cloud Tasks

Execution location can make a big difference.

A local task works in your local workspace: reading files, editing code, and running commands. A cloud task is delegated to a hosted cloud environment, which is better for longer and more automated workflows.

Cloud tasks are often more expensive because they involve:

A hosted execution environment
Longer tasks
More tool calls
Larger context
A more complete automation loop

For normal code edits, article cleanup, or small fixes, local tasks are usually cheaper. Use cloud tasks when the job truly needs hosted execution.

06 Why Weekly Usage Drops Fast

If your 5-hour quota barely moves but weekly usage drops a lot, common causes include:

You used cloud tasks.
You used a more expensive model.
You enabled fast mode.
The context was large, with many files or a long conversation.
The output was long, such as lots of code, a long report, or log analysis.
The task chain was long: search, edit, test, fix, test again.
Your quota script mislabeled the limit windows.

If you read fields from something like /backend-api/wham/usage, do not only trust processed labels such as five_hour% or weekly%. Check the raw JSON fields:

limit_window_seconds
percent_left
reset_at
bucket / feature name

Typical windows:

limit_window_seconds = 18000
=> about 5 hours

limit_window_seconds = 604800
=> about 7 days

If your script labels the windows backwards, the quota display will be misleading.

07 How to Save Quota

To make weekly quota last longer:

Split large jobs into smaller tasks.
Prefer local tasks when possible.
Tell Codex the relevant paths to reduce unnecessary scanning.
Avoid dumping huge logs, long files, or unrelated context.
Use cheaper mini models for light work.
Ask for a plan before starting a long task.
Ask for concise answers when you do not need a long report.

A useful mental model:

can continue using
= short window has quota
&& weekly window has quota

usage speed
= model price
× tokens
× output length
× task complexity
× execution location

This model is not exact billing math, but it explains most Codex usage-limit behavior.