Codex Reasoning Effort: Medium, High and Xhigh

On September 16, 2026, Codex Pulse recorded three HTML animation attempts with requested model gpt-6-astra: one each at medium, high and xhigh. Their static scores were 81, 90 and 84. The highest requested effort did not produce the highest score in these three outputs.

This observation is too small to choose a general winner. It is useful for a narrower reason: it shows why an effort comparison needs the original artifacts and a definition of what the score measures.

What reasoning effort changes

OpenAI exposes model_reasoning_effort for models that support it. The official configuration guide gives this example:

model_reasoning_effort = "high"

That is a configuration example, not a recommendation for every task. Check the options supported by your selected model and client. Record the effective setting before comparing outputs; a project configuration or command-line override may change what a user-level file specifies.

What we actually ran

The task requested a self-contained HTML document containing a 2D SVG animation of a pelican riding a bicycle. It asked for the complete HTML in the final response and prohibited tools, file reading, skills, network access and file writing. The caller saved the response. The exact Chinese prompt is part of the archive; an English paraphrase should not be used as though it were the same test input.

Codex CLI 0.154.0 ran three concurrent, independent ephemeral sessions. The command disabled memories and multi-agent behavior; other user and runtime configuration was inherited. The event logs recorded no completed command, MCP or web-search calls. Each result was the first attempt for its setting. No drawing was repaired or selected from retries.

The manifest preserves requested settings, prompt hash and output hashes. Requested model names were not independently verified against a backend snapshot.

What the scores leave out

These are static analysis scores from @ryqdev/pelican-test@0.1.0, using the html-svg-heuristic-v2 ruleset. They must be interpreted within that ruleset. A static score cannot establish that every moving part looks correct in a browser, that the result is aesthetically preferable, or that a model will fix a production bug.

The archived screenshots were captured at 1200 × 900, 1.5 seconds after loading the output in a sandbox with network requests blocked. A screenshot shows one moment; it does not replace inspecting motion. The archive notes describe those capture conditions.

There is only one attempt per effort. The difference between 90 and 84 cannot establish a reliable high-over-xhigh advantage. This article also makes no speed or cost comparison: the table contains neither matched latency measurements nor billing data.

How to choose a setting for your own task

Use your current supported setting as a baseline. Choose one alternative, then give both the same task, starting files, instructions and tool access. Set acceptance criteria before running either condition.

For a code change, record test outcomes, unintended changes, elapsed time and manual interventions separately. For an animation, preserve the source and inspect motion as well as static structure. Repeat each condition rather than selecting a winner from its best output.

A practical decision rule is to keep a change only when it improves the outcome you care about enough to justify its observed tradeoff. That tradeoff may be longer elapsed time, more usage or more manual checking. Measure it in your environment; this three-output example cannot supply it for you.

If neither setting completes the task reliably, inspect the task definition, context and tool failures before increasing effort again. The Codex quality guide provides a symptom checklist. Use the pelican explanation and examples when you need a small visual task.

The next revision of this comparison needs repeated attempts at each effort under matching conditions, with timing recorded separately. Until those exist, 81, 90 and 84 remain descriptions of three saved artifacts.