Codex Slow or Getting Worse? How to Check
Separate Codex latency, usage limits, early stopping, and incorrect output. Build a small reproducible check before concluding that model quality changed.
Last updated: 2026-10-29
By Stometa · Verification sources and dates are cited in the article.
If Codex feels slower or needs more supervision, first identify what changed. Waiting longer, running out of usage, stopping before checking work, and producing incorrect code are different observations. Each needs a different comparison.
This is an independent diagnostic guide, not a live incident feed or an OpenAI support page.
1. Describe the symptom
- Latency: time to the first response, time spent on tools, or total task duration increased. Record which one you mean.
- Usage limits: the product reports a limit or unavailable capacity. Save the displayed message and timestamp; a quota problem does not by itself establish lower reasoning quality.
- Early stopping: the agent finishes while requested work remains, answers an older message, or claims completion without running the requested check.
- Incorrect output: the task completes but fails a test or a clearly stated acceptance criterion.
Keep the exact error or missing behavior. “The patch fails this test” gives you a stronger starting point than “the model seems worse.”
2. Check the service and your environment
Check OpenAI's official status page for a relevant incident at the time of your run. A green aggregate status does not rule out a problem in your own session.
Record your client version, selected model, reasoning effort, working directory or repository revision, and whether tools succeeded. Keep network failures and tool permission errors separate from the quality of the generated answer. Consult the official Codex documentation for your client before changing configuration.
3. Repeat a small task under controlled conditions
Choose a non-sensitive task with a known expected result, such as fixing one failing test in a disposable checkout.
- Save the starting revision, prompt, instructions, and relevant settings.
- Define completion before the run: which behavior must change and which checks must pass?
- Run a fresh conversation, then repeat from the same starting state a few times.
- Compare against an earlier saved run only when the conditions are comparable. A different model, reasoning effort, repository state, or instruction set weakens the comparison.
- Record failures and retries as well as successes. Note whether you had to ask the agent to continue or verify its work.
Track pass/fail against the acceptance criteria, elapsed time, and the number of manual interventions separately. A small sample can reveal a reproducible failure; it cannot estimate how often every user experiences it.
4. Audit instructions and context
Inspect active project instructions and skills. Check whether an old instruction ends the task too early, forbids needed verification, or triggers for unrelated work. Test any suspected conflict in an isolated copy and change one condition at a time. Preserve authentication, safety rules, and the original files.
If a long conversation behaves differently, compare it with a fresh session containing the same essential task context. This helps isolate context effects, but a new session working once does not establish the cause.
If Codex is slow, locate the wait
For one repeated task, record three things separately: time until the first visible response, time spent on tools when available, and total time until the acceptance checks finish. A long test suite and a long wait before any response call for different investigations.
| What you observe | Next comparison | What it does not establish |
|---|---|---|
| Long wait before a visible response | Repeat the same small task and record the service conditions | That reasoning quality declined |
| Most time spent on commands or network tools | Inspect the slow tool's own output and duration | That a different model would remove the delay |
| Repeated searches or instruction reads | Inspect active instructions and compare a fresh session | That all skills should be disabled |
| Quick final answer with incomplete work | Check the missing acceptance criteria and record follow-ups | That the faster attempt was successful |
Do not remove required checks to make the timer look better. If the run finishes faster because it skipped verification, record incomplete work alongside the shorter duration.
Does a prompt fix slow Codex responses?
A clearer task can reduce ambiguity about scope and completion. It cannot guarantee service latency or remove a usage limit. Specify the input, desired change and checks to run; then compare the same task before and after the wording change.
Does a higher effort setting fix quality problems?
Treat effort as a testable setting. Keep the task and environment fixed, and compare successful completion, elapsed time and manual follow-ups. OpenAI documents reasoning effort configuration for supported models. A setting label alone does not establish that your task improved.
If the failure repeats, preserve the smallest example that still fails. Revisit that example after a relevant client, configuration or service change.
A dated quality update: September 12, 2026
Tibo Sottiaux's update addressed Astra users. It described fixes involving older skills that interfered with checking, an opt-in context experiment associated with early stops or replies to older messages, and a subset of misconfigured engines. The post said the experiment was disabled and the problematic engines removed.
This is evidence of specific acknowledged issues and reported remediation, not proof that every Codex session was affected or that every quality complaint is resolved. Compare your symptoms and run date with the scope of the report.
5. Use benchmarks for the question they actually test
The pelican SVG prompt
is useful for a quick visual comparison. It cannot establish a software-engineering regression. Preserve the model settings and multiple outputs if you try it.
For another perspective, MarginLab publishes a Codex coding-task tracker with its own methodology. Read its task selection and run conditions before applying its results to your work. A public tracker measures its chosen workload; your private repository may behave differently.
Pelican submissions as labelled records
If you try the pelican prompt, read other people's results as labelled records. Nine contributor submissions on this site, posted September 23 to October 9, 2026, show what a record carries: a model label the contributor typed, a prompt, and sometimes a reported html-svg-heuristic-v2 score. None of those verifies the backend model, and two entries labelled gpt-6-astra (ultra) report 93 and 98. These submissions are examples of record-keeping, and they are no evidence that Codex improved or degraded.
- September 23: Labelled “GPT6-Luna medium”; pelican prompt with Simplified Chinese on-screen text; no score shown.
- September 23: Labelled “gpt-6-sol (medium)”, reported 76; English-language pelican prompt; reported score 76/100.
- September 24: Labelled “GPT-6-Sol Xhigh”; English-language pelican prompt; no score shown.
- September 24: Labelled “GPT-6-Astral Xhigh”; English-language pelican prompt; no score shown.
- September 26: Labelled “gpt-6-astra (ultra)”, reported 93; English-language pelican prompt; reported score 93/100.
- September 30: Labelled “SOL6.1 (xhigh)”; prompt for a seagull in a costume, not a pelican, so it does not match the other eight; no score shown.
- October 1: Labelled “gpt-6.1-sol-max”; English-language pelican prompt; no score shown.
- October 7: Labelled “gpt-6-astra (ultra)”, reported 98; English-language pelican prompt; reported score 98/100.
- October 9: Labelled “GPT-6.1 Sol (low)”; pelican prompt with Simplified Chinese on-screen text; no score shown.
Build a useful issue report
Include the date and timezone, client version, selected model and effort, a minimal reproduction, expected behavior, actual behavior, and checks that failed. Remove credentials, private code, personal data, and sensitive paths before sharing logs. The Codex issue tracker is a place to look for matching reports and file a reproducible client issue.
If you cannot reproduce the problem, keep the original evidence and label the conclusion as uncertain. If you can, rerun the same small case after a relevant fix; that provides a clearer answer than comparing impressions from unrelated tasks.
Dated fixes and verification
Browse collected repair reports, original sources and verification status.