How Codex usage limits work

A Codex reset announcement and the timer in your account answer different questions. The announcement describes a public action. Your account describes the access available to you, under your plan, at that moment. Reading one as a substitute for the other is the quickest way to mistake a useful tracker for a promise it cannot make.

Start with your own usage dashboard when deciding whether to begin a task. Use the reset history to understand public events, and the announcement archive to read their wording. This guide explains how those pieces fit together without assigning a universal number of messages to every developer.

Three questions, three kinds of evidence

When a task stops, write down the question you are trying to answer. “How much can I use right now?” needs account-specific information. “What did the service announce?” needs a source post. “How often have announcements occurred?” needs a historical dataset. Those questions sound similar in a hurried conversation, but each needs different evidence.

Imagine two colleagues reading the same announcement. One has nearly exhausted a usage window; the other has just started working. Even if a public event applies to both accounts, their next few hours of activity can look different. A shared announcement does not make their task sizes, selected models, or subsequent usage identical.

A practical note can contain three lines: the dashboard message, the public announcement URL, and the time you checked. That small record is more useful than a screenshot of a relative “days ago” label alone. It preserves what was observed without adding an unsupported explanation for why it happened.

Why a message is not a fixed unit of work

OpenAI’s Codex pricing documentation explains that usage varies with task complexity, model, context, and execution mode. It describes shared local and cloud usage windows and notes that additional weekly limits can apply. Its message ranges are estimates, so they should not be treated as a fixed allowance for every task.

Consider two requests you might send during a refactor. The first asks the assistant to rename a parameter in a small function and update its immediate callers. The second asks it to trace an intermittent integration failure across a large repository, run several suites, inspect logs, and propose a migration. Counting both as “one message” describes the chat interface, not the amount of work requested.

That distinction changes how you should budget a session. Counting prompts can be a rough personal habit, but it cannot establish a reliable exchange rate between messages and remaining work. A more useful log records task scope, selected mode, whether the repository was already understood, and whether repeated attempts were necessary.

Read the account timer literally

If an account interface shows a reset time, preserve its time zone and the type of limit it names. Do not replace it with a countdown calculated from public announcements. The public archive has no authenticated access to your account and cannot see your remaining allowance, eligibility, purchase history, or personal renewal window.

Suppose the dashboard gives a time this evening while a public tracker shows the latest announcement six days ago. There is no necessary contradiction. One describes your account window; the other describes the latest recorded public event. Waiting for the historical average to elapse will not make the account timer more accurate.

The same principle applies when sharing information with a team. Say “my dashboard currently shows this time” instead of “Codex resets for everyone at this time.” Add the date and zone. Colleagues can then compare their own evidence without assuming the same personal schedule applies to them.

Public resets are a separate event stream

This tracker labels records as global or banked. The label helps organize the archive, but the linked announcement remains the authority on scope. A short source post may depend on an earlier conversation, refer to a particular incident, or describe a credit rather than an immediate change to every account.

At launch, the archive contains 53 records. Their timestamps and classifications were imported from the public timeline and remain marked for editorial review; their source authorship and full text were checked separately through X. Those are distinct verification steps. Confirming who wrote a post does not by itself confirm that an imported event timestamp represents the exact instant of an account change.

Read the whole post before drawing a conclusion. If the wording mentions a banked reset, consult the banked reset guide. If you need to cite timing, distinguish the recorded event time from the post’s publication time. That distinction matters most around rollouts and follow-up announcements.

Plan sessions around deliverable checkpoints

A useful session plan names a deliverable small enough to inspect. For example: “Reproduce the failure, identify the responsible function, and save the failing input.” Another session can implement the correction and run validation. Dividing work this way is an engineering decision; it is not a guarantee that a particular limit will last longer.

Make the stopping point explicit before work begins. Ask for the current hypothesis, modified files, commands already run, and the next unresolved question. If a session ends unexpectedly, those notes reduce the cost of resuming. They also prevent a fresh session from repeating an expensive investigation merely because the original reasoning was never recorded.

A checkpoint should be useful to a person, too. A teammate ought to be able to read it and understand what is known, what is uncertain, and which result would settle the uncertainty. Avoid a long transcript dump. A short, accurate handoff is easier to trust and keeps irrelevant context out of the next task.

Spend attention on scope before execution

Before asking for a change, identify the relevant repository area and the condition that counts as done. “Improve the app” invites open-ended exploration. “Make the export preserve the selected date range; validate it with the existing export fixture” gives a concrete target and an observable result.

OpenAI’s Codex best practices guide recommends supplying task context, constraints, and success criteria. Treat that as a way to improve collaboration. It does not mean that a carefully worded prompt exempts the task from usage limits or guarantees a smaller bill.

Useful constraints are those that remove uncertainty: the supported runtime, the command used for verification, files that must remain compatible, and the expected user-visible behavior. Unhelpful constraints are long lists unrelated to the change. The goal is to help the assistant choose relevant work, not to surround every request with a miniature policy manual.

Distinguish subscription access from API access

The official pricing page also distinguishes API-key usage from subscription access. An API key belongs to a separate usage and billing path. Do not assume that a public subscription reset announcement replenishes an API balance or changes an organization’s API budget.

Before switching execution paths, identify which account and billing arrangement the tool will use. In a team, this can be a documentation question rather than a technical one: who owns the key, which project is selected, and where can the resulting usage be reviewed? A reset tracker cannot answer those questions for you.

Avoid describing a switch as “free extra resets.” It may simply move work to another paid service. A good workflow makes the tradeoff visible before the task starts. If you are comparing tools, measure completion quality and review effort alongside access availability; an available tool is not automatically the right one for a particular repository.

What to do when a limit interrupts work

First, preserve the current state. Record changed files and the last meaningful output, then inspect the account’s own explanation. Second, separate completed work from unfinished assumptions. A partially generated patch may need review even if the assistant sounded confident before the session stopped.

Third, choose the next action based on the actual blocker. You might wait for the displayed window, continue a review manually, or choose a separately authorized execution path. A public alert is useful context, but it should not be the only basis for spending money or abandoning an otherwise productive workflow.

Finally, leave a short restart note. Include the intended outcome, the strongest current evidence, and the next command or inspection. When access returns, resume from that checkpoint instead of asking the assistant to reconstruct the whole story from memory. This is good operational practice regardless of which coding assistant you use.

Use the tracker for what it can establish

The homepage preserves source text so you can inspect an announcement without depending on a third-party embed. Its statistics summarize the recorded sequence. They do not prove a fixed schedule, measure your account, or certify that every historical classification has completed editorial review.

For your next session, keep two bookmarks: the account usage page and the public announcement archive. Check the first for personal availability and the second for public context. If you want to understand the intervals between events, read how we reason about the next reset before turning an average into a deadline.