Tips and Tricks for using Codex and Rate Limits

Codex
,
21

Check the OpenAI Developer blog

Limited to two replies in a row so appending to second reply.

Make use the slash command /goal

22

Hi guys I wanted to start this thread to see what everyone is breathing with.

Do you have any cool tips and tricks you don’t see on the web to share with devs in this forum? Something simple but efficient. Not complicated to implement not too tied to a specific project but more something that helps you save some time and tokens.

Here is 1 I thought of sharing:

/.feedback

  • AGENTS.md
  • README.md
  • TEMPLATE.yaml
  • /new
  • /claimed
  • /implemented

Placed in the root of your project, with a note in main agents.md file to do before commit preparation: to review the current session agent experience, identify frictions, problems, failed tools, or unclear instructions, as well as any other notes agent considers important to improve its efficiency, quality and overall work in this project.

Then simply ask your agent time from time to review the folder and improve the workflows and/or its instructions.

23

I have another one for readme… now basically part of most of my repos. Codex even figured out how to scan outlines on MD files with regex.

25

One tactic that has helped our team a lot: treat Codex runs like reversible ops loops. Start with a tiny mission card, keep proof for each browser step, and split the closeout into executed, verified, and blocked. It cuts drift fast when you are testing across real surfaces.

26

Tomorrow marks 60 days of coding with codex, doing practically nothing else night and day.

I had no experience or knowledge on how to code, what clean architecture was, but decades of being an end-user of a multitude of software types really helped me get through…

I’ve been playing with the idea of putting a thread together for folks, that approaches the pitfalls someone with little experience in the field should be aware of before going in.

Simple things that most of you fine folks would probably never consider because of your years of experience…

Like how a simple ‘vibe’ prompt can lead to extensive refactoring down the road and how to use the plan feature as well as general tips to consider when prompting that I’ve picked up while in the trench.

In my mind it’s not so much a ‘tips and tricks’ thread, but something along the lines of - ‘never coded before? - codex makes it easy - here’s what to look out for on your first projects’.

Let me know if you would like me to spend time fleshing that out.

:clinking_beer_mugs:

27

Make use of /goal, especially helpful Long-Horizon tasks.

/goal - Give Codex a persistent target to track while a larger task runs.

The credit for this goes to @VeitB who suggested it to me for a Long-Horizon task.

28

Got a notification about a like on this post so there is an update as well. The skill is ready to use. Help yourself.

29

Another useful Codex tip is to control how much command output enters the main conversation.

Test logs, stack traces, recursive searches, and other verbose command output consume context and can eventually make a long session less reliable. Codex may bound very large output and compact older context, but it is still better to avoid unnecessary output in the first place.

When possible, ask Codex to use concise options such as:

  • pytest -q
  • cargo test -q
  • git status --short
  • git log --oneline -20
  • curl --silent --show-error
  • tail -n 100 app.log

For commands without a suitable quiet option, have Codex save the complete output to a temporary log and inspect only targeted sections. Preserve the exit status and useful error messages rather than suppressing everything.

For especially noisy work, ask Codex to delegate it to a subagent. The raw output remains in the subagent’s separate thread, while the main conversation receives a concise summary.

For example:

Use a subagent to run the complete test suite. Keep the routine and
successful test output in the subagent. Return only:

- the command and exit status
- failing test names
- relevant error excerpts
- the likely cause
- the location of any saved full log

Current Codex releases support subagents in the CLI, IDE extension, and ChatGPT desktop app. In the CLI, /agent can be used to inspect and switch between agent threads.

If this should be the default behavior for a project, add something similar to AGENTS.md:

## Command-output hygiene

- Prefer quiet or concise command options.
- Preserve exit status and actionable errors.
- Save verbose output to temporary logs and inspect only relevant excerpts.
- Delegate noisy tests, searches, and log analysis to a subagent.
- Return summaries rather than raw intermediate output to the main thread.

This helps keep the main conversation focused on requirements, decisions, and results instead of filling it with intermediate noise.

31
32

The biggest recommendations is the most fundamental to operators across all professions: respect the machinery.

You don’t need to be a mechanic to drive a car, but you need to know:

  • How to identify when the engine is running poorly
  • How to diagnose common issues
  • How to treat the car with respect

The inability to identify excessive gas consumption is a clear indication of losing control.

Respect is quite simple; you don’t need to polish it. Understand when something is off, and how to formulate enough understand to atleast describe it to someone that can help

If you are swearing and becoming agitated with the model, you have lost control.

There is no sympathy for someone complaining about spending all their gas driving to Kwik-E-Mart when they have 15 fridges strapped to the roof of their sedan

Outside of metaphors. Tell the model to “iterate fast and break loudly”. It’s trained on mostly production code which swallows/nerfs errors and builds way too many tests for an unstable core.

And always always always ask the model for a health check on the codebase.

I can’t tell you how beneficial it is to separate things into modules. Programming best practices are largely about making software easier and safer to understand, change, and verify over time.

Technical debt is REAL

33

Thanks for all the great Codex tips. Watching for more!

35

While Codex can be used for much more than programming, this tip is primarily about software-development projects.

When starting a new coding project, define the required execution environment and validation process early. Otherwise, Codex may repeatedly encounter the same missing dependency, incorrect path, permission failure, or platform-specific assumption.

Before implementation begins, have Codex perform an environment preflight and identify anything that could affect the work:

  • Execution environment: Local machine, WSL, container, virtual machine, Codex worktree, or Codex cloud environment.
  • Operating system: Including the version and any supported target platforms.
  • CPU architecture: For example, x64 or ARM64. Core and thread counts may also matter for parallel builds, tests, or performance-sensitive work.
  • Memory and storage: Available RAM, disk space, and any limits imposed by a container or CI runner.
  • Shell and command syntax: Bash, PowerShell, Command Prompt, Zsh, and so on.
  • Working directory and repository root: Including which folders Codex is allowed to read or modify.
  • Sandbox and approval settings: The sandbox determines what Codex can access; the approval policy determines when it must ask permission. See Sandboxing.
  • Network access: Whether package registries, APIs, documentation sites, Git remotes, or other external services are reachable.
  • Filesystem behavior: Path separators, path-length limitations, filename case sensitivity, symbolic-link support, and expected line endings.
  • Temporary files and caches: Where they may be created, how much space is available, and whether they should be removed afterward.
  • Permissions: File and directory permissions, executable permissions, protected paths, and whether administrative access is required.
  • Languages, runtimes, and tool versions: For example, the required versions of Python, Node.js, Java, .NET, Rust, compilers, package managers, linters, and formatters.
  • Dependencies: How they are installed and whether versions are pinned through lockfiles or other reproducible configuration.
  • Environment variables and secrets: Which variables are required, how they are supplied, and during which execution phases they are available. Secrets should not be placed in AGENTS.md or committed to the repository.
  • External services: Databases, message queues, browsers, Docker, local servers, MCP servers, or APIs needed to build or test the project.
  • Build, test, lint, and type-check commands: Include the exact commands Codex should run and the expected success criteria.
  • Generated artifacts: Where builds, reports, logs, coverage data, and other outputs should be stored.
  • Definition of done: State what must pass before the task can be considered complete.

Stable project instructions—such as the repository layout, supported platforms, build commands, constraints, and verification requirements—can be placed in AGENTS.md. OpenAI’s Codex best-practices guide specifically recommends using AGENTS.md for reusable repository guidance and notes that many apparent quality problems are actually environment-setup problems.

However, avoid hard-coding transient facts such as the machine’s current free memory or temporary-directory contents into AGENTS.md; those can quickly become outdated. Have Codex detect dynamic conditions during its preflight, while keeping stable requirements in version-controlled files.

For reproducibility, encode as much setup as possible in lockfiles, setup scripts, containers, or CI configuration. Codex supports project-specific configuration through .codex/config.toml. The ChatGPT desktop app also supports local environment setup scripts, while Codex cloud environments can define dependencies, runtime versions, environment variables, setup scripts, and internet-access settings.

A useful opening instruction is:

Before modifying any files, inspect the execution environment and repository instructions. Verify the operating system, architecture, working directory, sandbox and network restrictions, available tools and versions, dependency state, and required build and test commands. Report any mismatch with the project requirements before beginning implementation.

37
  1. The most useful practical advice from the thread
    Check background consumption first

Inspect:

automatic code review;
GitHub review integration;
cloud tasks;
automations;
subagents;
background terminal jobs;
Memories;
unfinished browser or Work tasks.

Given the 74.6% auto-review example, this should happen before obsessively shortening individual prompts.
Verify the authentication and billing identity

Check whether the client is using:

ChatGPT subscription authentication;
an OPENAI_API_KEY;
workspace credits;
personal API billing.

After extension or desktop updates, signing out and back in may be worthwhile.
Collect evidence before reporting the problem

For one reproducible run, record:

plan;
model;
reasoning level;
Fast/Ultra setting;
local or cloud;
client and version;
timestamp and timezone;
session ID;
short and weekly percentages before and after;
local token deltas;
background features enabled.

A support report with this bundle is much more useful than “Codex used 40% for one prompt.”
Use controlled comparisons

Test the same bounded task with:

a fresh thread;
the same repository state;
one model changed at a time;
no background reviews or automations;
no Fast mode unless specifically testing it.

That helps separate model cost from accumulated context.
Keep projects resumable

Maintain a concise checkpoint containing:

current objective;
completed work;
remaining work;
architecture decisions;
known failures;
commands and tests;
changed files.

Combine that with small Git commits or worktrees.

This does not fix rate limits, but it dramatically reduces the damage caused by interruptions.
Optimize for completed work, not cheap tokens

Do not automatically assume the smallest model is the best deal.

Measure:

quota consumed per correct, tested, completed task

rather than:

quota consumed per turn.

Stop no-progress loops

One reported operation continued planning, compacting and retrying for hours without completing.

A useful instruction is:

If there is no material progress after N attempts, stop, summarize the blocker, and ask for guidance.

Be careful with banked or bonus resets

Users reported that activating a reset could restart the seven-day clock rather than adding quota to the existing schedule.

If that behavior applies, redeeming a reset while substantial weekly quota remains can waste value.

This was repeatedly observed but not officially documented.

38

Codex tip: Prefer diagnostic text over screenshots when possible

When building an application with a graphical user interface (GUI), there will be times when you are tempted to take a screenshot and include it in the Codex prompt to help diagnose a bug.

Screenshots can be useful when the problem is genuinely visual, but they also require the model to process an image. When the important information can be represented as text, supplying structured text is generally more efficient and makes it easier for Codex to search, compare, and reason about the application’s state.

Since Codex is writing or modifying the GUI code, it often already has a good idea of what diagnostic information would be useful. Consider asking Codex to add a temporary message/debug log panel directly to the GUI. The panel can expose relevant state changes, events, errors, values, and other information that would otherwise have to be inferred from a screenshot.

Then, when something goes wrong, copy the relevant text from the log panel into the Codex prompt instead of supplying another screenshot.

This can be even more effective when combined with a manual test script generated by Codex.

Because Codex knows both the implementation and the diagnostic messages it added, it can create a step-by-step test procedure that tells the tester not only what actions to perform, but also what should appear in the log at each important point.

For example, a test step might say:

  1. Click Connect.
  2. Verify that the status changes to Connecting.
  3. In the debug log, confirm that a connection_attempt_started message appears.
  4. Wait for the connection to complete.
  5. Confirm that the log contains connection_established and does not contain an error message.

This gives Codex two useful sources of evidence: what the user observed in the GUI and what the application reported internally. If the visible result is wrong, the log can help identify which part of the expected event flow failed.

It also makes manual testing more reproducible. Instead of simply telling someone to “try the feature and see what happens,” the test script defines the actions, expected GUI behavior, and relevant diagnostic messages to check.

For diagnostic use, I prefer keeping this log in memory only rather than automatically writing it to a file. Persisting the log introduces another layer of implementation—file creation, paths, permissions, buffering, rotation, cleanup, synchronization, and error handling—and each additional layer can introduce bugs of its own. During debugging, minimizing those extra moving parts can be valuable.

This does not eliminate screenshots. If the defect involves layout, clipping, colors, rendering artifacts, alignment, or some other inherently visual behavior, an image may still be the best evidence. But for application state and event-flow problems, a small structured text log combined with a repeatable manual test script can often give Codex substantially better diagnostic information while reducing the need for screenshots.

39

Codex can see your remaining usage limits: