Tune reasoning with evidence

Understand the approach

Reasoning effort gives the selected Codex model more or less computation for a task. Begin with the current client default; a harder investigation may benefit from a higher supported setting, but extra time or output length is not success. This differs from Claude’s thinking keywords, environment variables and /effort interface.

In the app use the model/reasoning control beneath the composer; builds with a Power selector expose exact choices through Advanced. In the CLI use /model to choose a model and supported effort; the IDE uses its model switcher below the composer. A one-run CLI override is model_reasoning_effort. Available labels and values depend on the model, account and build, so choose two values actually offered for the same model.

Use two fresh copies of the missing-both task and identical prompts, tools, permissions and rubric. Change only the supported effort. Retain actual outputs, diffs, elapsed time and available usage; grade both with the same extension checker and baseline suite. The supplied synthetic candidate comparison tests the rubric only. One observed pair is task-specific evidence, not a universal model ranking.

Keep the comparison proportionate

One successful trial can suggest a direction, but does not prove a universal advantage. If the task matters, repeat on representative cases and include failures rather than selecting only the best result. Avoid rerunning a large expensive workflow solely to fill a table. It is acceptable to conclude that a comparison is not worth its cost for a small edit, or that current evidence is insufficient to recommend a change.

Try it step by step

1. Use the app model control or CLI /model; record the actual model, default effort and two supported comparison choices.
2. Create two fresh generated packages, fix the extension prompt and acceptance checks, and keep tools/permissions equal.
3. Run the same bounded implementation in two fresh chats with one effort difference. Save actual outputs and diffs separately.
4. Run extension/check.cjs and the copied baseline suite for each. Record failures, elapsed time and available usage rather than selecting only a convincing answer.
5. Restore the original app selection. If a run is unavailable, label the comparison unmeasured; never borrow the fixture result as a model score.

A useful starting example

Illustration · adapt before use.

/model

# One-run CLI override, keeping the configured model:
codex --config model_reasoning_effort='"medium"'
# Compare only if the same model supports this value too:
codex --config model_reasoning_effort='"high"'

Check your result

• Exact current model/effort controls and both actually selected settings are recorded.
• Inputs and checks remain fixed; both final artifacts are graded, including failures.
• Synthetic evaluator checks, real inference evidence and unavailable observations remain distinct.

Common mistakes

• Requesting hidden chain-of-thought as though it were required evidence.
• Changing model, prompt, repository, and effort together, then attributing improvement to one control.