Codex Slow or Getting Worse? How to Check

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.

1. Save the starting revision, prompt, instructions, and relevant settings.
2. Define completion before the run: which behavior must change and which checks must pass?
3. Run a fresh conversation, then repeat from the same starting state a few times.
4. 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.
5. 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.

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.

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.