“Auto” reasoning effort (dynamic tiering) for Codex CLI

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #8637
• #2640
• #1812

Powered by Codex Action

I couldnt find any duplicates!!

Actually, the Codex team has said medium=auto

@jasonwei1002 Do you have any sources for this?

<img width="1174" height="214" alt="Image" src="https://github.com/user-attachments/assets/3090ec7c-bfc0-40cd-88b1-5076b3358388" />

Feature request: task-type routing + bounded reasoning effort

Goal:
Automatically choose reasoning effort by task type, WITH user-defined bounds.

Example policy:

• If the user request is primarily "write/modify code" → use reasoning_effort=high (never xhigh)
• If the user request is primarily "analysis / planning / architecture / debugging strategy" → use reasoning_effort=xhigh (never below high)

Why:
In scientific/complex codebases we want fast/consistent code-edit turns (high), but deeper thinking for design/debug planning (xhigh). Manually switching is friction and error-prone.

Requirements:

• Configurable rules in config.toml (or profiles), e.g. [routing] with matchers (keywords, intent classification, or explicit commands)
• Hard caps per category (min/max) so it never exceeds xhigh or drops below high
• Optional per-turn override (e.g. /effort high|xhigh)
• Transparent: show which route was chosen and why (briefly), and allow "always ask" mode if uncertain
• Works in CLI + IDE extension

Adding another user scenario here rather than opening a duplicate issue.

For day-to-day Codex use, the missing UX is not only an auto value in config, but making it easy for Codex to recognize when a specific turn should switch reasoning effort before answering.

Concrete examples:

• quick factual/status questions, small single-file edits, or simple command output summaries should stay at medium or lower for latency
• code review, root-cause debugging, multi-file changes, architecture/design tradeoffs, or repeated failing tests should automatically move to high/xhigh
• if Codex is unsure, it could briefly show the selected tier and why, or ask before escalating when the cost/latency impact is large

A useful UX would be:

• an auto reasoning mode with user-configurable min/max bounds
• transparent status like Auto -> high: multi-file debugging + failed test loop
• a one-turn override such as /effort high or natural-language override (answer this with high reasoning)
• optionally remember task-profile preferences, e.g. code review defaults to high while short chat/default command help stays medium

This would reduce manual switching friction without forcing every session to run at the highest reasoning level.

I'd like to add a related use case: changing reasoning effort during an active Codex turn, or allowing Codex to adapt reasoning effort by phase within a turn.

The current fixed-per-turn model is limiting for long agentic workflows. A single request can move through very different phases, for example:

• quick repo inspection or file reads where low/fast reasoning is enough
• deeper planning, debugging, or root-cause analysis where higher reasoning is useful
• mechanical edits or formatting where lower reasoning is again sufficient
• final verification and risk review where higher reasoning may be appropriate

Ideally Codex would support one or both of these:

1. Let the user adjust reasoning effort mid-turn without interrupting or restarting the task, with the new setting taking effect on the next model/tool loop.
2. Add an auto/policy mode that can change reasoning effort based on the type of work being done within the same turn, not only before the turn starts.

This would reduce overthinking simple phases and underthinking complex phases inside the same long-running task, while still preserving manual controls for users who want to pin a specific reasoning level.

I would like to add one UX angle to this request.

Today there appears to be a partial workaround: do not explicitly set model and/or model_reasoning_effort in config.toml. When these are left unpinned, Codex can fall back to its default/model-selection behavior instead of always using a user-pinned model and reasoning effort.

That helps somewhat because the user is no longer forcing every task through the same fixed configuration. However, this behavior is not very discoverable in the CLI:

• The CLI still always shows a concrete active model, so it is not obvious whether the model is user-pinned or selected by Codex defaults.
• Using /model to choose a model/reasoning level persists that choice back to config, so a one-off selection can become the new default.
• There does not seem to be an obvious in-CLI way to return to “use Codex defaults / unpin model and reasoning effort.”
• This makes users choose between always running a higher reasoning mode, which drains quota/tokens faster, or manually switching effort levels when a task becomes complex.

The underlying problem is that task difficulty changes a lot within normal Codex usage. Some turns are simple edits or quick checks; others are debugging, architecture, long-running agentic work, or repeated failure analysis. A fixed reasoning setting is often either too expensive for simple turns or not enough for difficult turns.

An explicit Auto mode would make this behavior understandable and intentional: Codex could use cheaper/faster reasoning for straightforward tasks and higher reasoning for complex tasks, without requiring users to keep high reasoning enabled all the time just to handle occasional complex work.