The most reliable way to make Codex limits last longer is to reduce work that does not improve the final result: repeated discovery, duplicated instructions, verbose success logs, unnecessary tools, abandoned runs, and redoing completed steps. Give the agent a precise starting point and a measurable finish before reaching for elaborate token tricks.
The Direct Answer
Use this order:
- Describe the failure, expected behavior, relevant file or page, and completion test.
- Use the least expensive capable model for each narrow part of the task.
- Keep global and project instructions short; package repeated mechanics as skills.
- Stop or steer a run when it is clearly going in the wrong direction.
- Return compact success output and full diagnostic detail only on failure.
- Write a small progress record so interrupted work resumes instead of restarting.
OpenAI's current help material says Codex usage varies with the model, task size, repository and context size, reasoning, speed, tools, and execution location. That means no single prompt can create a hard universal cap. A requested “1% budget” is a planning constraint, not an account-level guarantee.
Watch the Full Codex Usage Experiment
Source and credit: The embedded experiment is by Dubibubi. All percentages, prices, model comparisons, and interface observations attributed to the test are creator claims from 15 September 2026. OpenAI documentation is used below to separate supported product behavior from experimental advice.
What the Numbers Actually Prove
| Claim | Evidence shown | How to read it |
|---|---|---|
| Up to 91.75% lower usage | Creator's headline result from hundreds of small experiments. | A best observed result, not a representative average. |
| 33.3% lower usage | Two successful runs fixing the same small button bug. | A useful demonstration, but one trial per condition cannot establish reliability. |
| About 6% from shorter tool reports | Six matched comparisons, according to the creator. | Plausible for noisy tools; depends on report size and required diagnostics. |
| About 23% from providing a file path | Six comparisons, according to the creator. | Most valuable when the baseline spends heavily searching an unfamiliar repository. |
The live “enhanced” condition changed several variables at once: prompt specificity, file location, budget language, subagent model, plugin state, and response style. It proves that the combined setup used fewer measured tokens on that task. It does not reveal how much each individual rule contributed.
1. Give the Task a Budget
A budget prompt forces prioritization: “Complete this task within approximately 1% of my weekly allowance. Stop and report if the scope cannot fit.” This can discourage open-ended exploration and make the model choose a smaller proof before a full implementation.
Treat the percentage as a target. Whether Codex can inspect current usage depends on the client, account, and tools available in that session. Check the actual usage page, banner, or supported /status output. Require a checkpoint before the model expands scope instead of assuming the requested budget is enforced.
2. Delegate Narrow Work to a Cheaper Model
The video has Astra orchestrate lower-cost Luna agents for classification, drafting, and other bounded work, then review the combined result. That pattern can lower cost when the cheaper model is capable and the work has a crisp contract.
OpenAI also documents the counterweight: every subagent performs its own model and tool work, so multi-agent flows consume more total tokens than comparable single-agent runs. Use them when parallelism, specialization, or a cheaper model changes the economics, not as a default.
- Give each subagent one input, one output format, and one acceptance test.
- Do not send the entire repository when three files will do.
- If the main agent repeatedly redoes the result, shrink the delegated scope or stop delegating it.
3. Do Not Build a Workflow Around Gaming Reset Windows
The creator proposes sending a tiny automated message before the workday so a rolling window begins earlier. This behavior is not documented by OpenAI as a stable optimization, may consume usage itself, and can change with plan or accounting rules. It also does nothing to reduce the work performed.
Use the reset time displayed in your own account. If you hit a limit, the supported options may include waiting for the displayed reset, using available credits or a banked reset, or changing plan. Build automations because they complete valuable work, not merely to manipulate a timer.
4. Turn Repeated Mechanics Into Reusable Skills
If a workflow repeatedly packages assets, generates previews, validates filenames, and produces a delivery archive, record that procedure once. A skill can bundle the instructions, reference files, and scripts needed for consistent execution.
OpenAI's skills system discovers available skills and lets Codex select the relevant one for the task. Keep the skill description precise so it triggers only when useful. Move deterministic operations into scripts: a tested script is often cheaper and more reliable than asking a model to reinvent the same transformation.
5. Save Preferences Once, but Keep Them Lean
Global preferences belong in user-level instructions; repository conventions belong in an applicable AGENTS.md. This avoids repeatedly explaining naming, testing, formatting, and review expectations.
Those instructions are still context. OpenAI's agent-loop documentation says applicable AGENTS.md files are injected near the beginning of the conversation. Remove duplication, outdated rules, biographies, and instructions unrelated to the repository. Prefer the shortest rule that changes behavior.
6. Correct a Bad Run While It Is Still Working
If the agent is implementing the wrong design or exploring the wrong module, intervene immediately. Steering cannot recover usage already spent, but it can prevent another ten minutes of irrelevant work. Use queued follow-ups only when the new instruction genuinely belongs after the current task.
Make the correction operational: “Stop editing. The bug is in the checkout route, not authentication. Re-read the failing test and continue only from that evidence.” A vague “no” can create another exploration loop.
7. Disable Tools and Plugins That the Task Does Not Need
Tool definitions, plugin metadata, MCP capabilities, and retrieved results can add context or create additional calls. Start each task with the smallest useful toolset. Image generation, browser control, web research, and large MCP servers should be present because the task needs them, not because they were useful last week.
Do not remove a tool that provides the required verification. Saving context by disabling browser testing on a visual change can create a cheap run and an expensive defect. The goal is relevant tools, not zero tools.
8. Keep Successful Tool Reports Short
Tools often return far more text than the agent needs. For batch checks, return a count and concise success state; include full paths, stderr, stack traces, and failing records only when something breaks. The creator reports about 6% lower token use across six comparisons after shortening these reports.
Implement this at the command or script level where possible:
- quiet mode on success;
- bounded output and a summary count;
- full diagnostics saved to a file and surfaced only on failure;
- no repeated printing of unchanged files.
Never hide the line needed to diagnose a failure. Test compact output against known failing cases before making it the default.
9. Ask for the Shortest Response the Job Allows
Output also consumes usage. For a focused edit, ask for the result, verification, and remaining risk rather than a long narrative. Keep detailed explanations for architecture decisions, incidents, teaching, and reviews where they provide real value.
A durable instruction can be simple: “Be concise. For completed changes, report what changed, verification, and blockers. Expand only when the decision is non-obvious or I ask for detail.” Avoid novelty styles that make technical information harder to scan.
10. Tell Codex Where to Start
“Debug my website” forces the agent to discover the application, reproduce the issue, locate the route, and infer the expected behavior. A better request provides:
- the failing URL or command;
- the exact action and observed result;
- the expected result;
- the likely file or component when known;
- the test that proves the fix.
The creator reports about 23% lower total tokens in six comparisons when the correct file path was supplied. A few accurate words can remove an entire repository search. Do not guess a file path: wrong specificity can send the agent confidently in the wrong direction.
11. Leave a Small Record of Completed Work
Long tasks should maintain a concise, durable checkpoint: completed items, artifacts and paths, failed attempts, decisions, verification state, and the next action. If the task is interrupted, the next run reads the record instead of repeating discovery and production.
Keep the record factual and small. Update it after meaningful milestones, not every tool call. Remove stale plans once the work is complete, or they become another source of context and confusion.
Run a Fair Usage Comparison
- Choose one repeatable task. Fix the repository state, model, reasoning level, tools, and acceptance test.
- Record the baseline. Capture elapsed time, usage or credits shown, tool calls, retries, and whether the result passed.
- Change one rule. Do not combine six optimizations if you want to know which one matters.
- Run several trials. Agent paths vary even with the same prompt.
- Count correction time. A cheap first run that needs a second run is not efficient.
- Measure accepted work. Compare usage per verified result, not usage per prompt.
| Measure | Why it matters |
|---|---|
| Usage or credits consumed | The actual constrained resource on the account. |
| Input, cached input, and output | Shows whether context, cache behavior, or verbosity changed. |
| Tool calls and subagent runs | Reveals hidden work behind a short final answer. |
| Elapsed and reviewer time | Lower usage may trade away speed or require more human correction. |
| Acceptance-test pass rate | Prevents optimization from rewarding incomplete or fragile work. |
Practical verdict: rules 4, 5, 8, 10, and 11 are durable workflow improvements because they reduce repeated reasoning and preserve useful state. Rules 1, 2, 6, 7, and 9 are situational controls that need task-level testing. Rule 3 depends on undocumented accounting behavior and should not be part of a production method.
Video Chapters
- 0:00 - How I stopped hitting Codex usage limits
- 0:42 - Why old token-saving tips do not work
- 1:45 - Rule 1
- 3:36 - Rule 2
- 4:57 - Rules 3 to 5
- 7:41 - Rules 6 and 7
- 9:42 - Rules 8 and 9
- 12:04 - Rules 10 and 11
- 13:18 - Live token-savings demonstration
Sources and Links
- Dubibubi: Never Hit GPT 6 Astra Usage Limits Again
- Dubibubi YouTube channel
- OpenAI Help: Using Codex with your ChatGPT plan
- OpenAI Developers: Codex pricing and plan limits
- OpenAI Developers: Subagents
- OpenAI Developers: Build skills
- OpenAI: Unrolling the Codex agent loop
- OpenAI: Introducing the Codex app