Repository navigation
“Auto” reasoning effort (dynamic tiering) for Codex CLI #8649
Description
What feature would you like to see?
Title: Feature request: “Auto” reasoning effort (dynamic tiering) for Codex CLI
Summary
Add an “Auto” mode for reasoning effort so Codex can dynamically choose the right reasoning tier (minimal/low/medium/high/xhigh) per turn or per task—similar to how ChatGPT “Auto” adapts effort based on complexity.
Today, I have to manually pick a fixed reasoning effort (via config or /model), but real work swings between:
- fast/light turns (quick edits, short answers, small diffs)
- heavy turns (debugging, architecture, multi-step refactors, repeated failing tests)
Auto would reduce friction and improve throughput while preserving the option to pin a specific tier.
Problem / Motivation
Manual reasoning tier selection is:
- extra cognitive overhead (I often guess wrong)
- inefficient (overthinking simple requests or underthinking hard ones)
- awkward for long-running/agentic workflows where difficulty changes over time
This becomes more important for background/long-running terminal workflows (e.g., servers/builds/migrations) where I want reliability without always forcing xhigh.
Proposed solution
1) New setting value
Allow:
- config:
model_reasoning_effort = "auto" - CLI:
--config model_reasoning_effort="auto"(and/or a dedicated flag) - UI:
/modelincludes “Auto” as a selectable reasoning option
2) Auto policy (suggested behavior)
Auto selects a tier based on signals like:
- user intent: “quick”, “just summarize”, “deep dive”, “debug this”, “root cause”, etc.
- task complexity: size of diff, number of files touched, tool-call count
- failure loops: escalate after N failed commands/tests or repeated errors
- time sensitivity: prefer lower tiers for interactive back-and-forth, higher tiers for “go work” tasks
A simple baseline policy could work well:
- default = medium
- drop to low/minimal for small, single-step turns
- escalate to high/xhigh when (a) tests fail repeatedly, (b) multi-file refactor, (c) ambiguous bug/trace investigation
- de-escalate after success/stability
3) Guardrails
To avoid surprising cost/latency:
- optional caps:
auto_min = "low",auto_max = "high"(defaults sensible) - always show current tier in status bar/logs: “Auto (currently: high)”
- one-command override/pin: “Pin current effort” or choose a fixed tier anytime
UX sketch
/model:- Reasoning: Auto | minimal | low | medium | high | xhigh
- If Auto selected, display the currently chosen tier next to it.
Related
- Existing request/discussion around setting reasoning effort
- Background terminal sessions request (Background Terminal Sessions #3968) — Auto reasoning would pair well with long-running/background workflows
Acceptance criteria
- “Auto” is selectable in CLI + IDE (and visible in status)
- Auto chooses different tiers in practice (with transparent logging)
- Users can cap min/max and pin a tier
- Docs updated + tests for config parsing and request payloads
Additional information
No response
Activity
github-actions commentedon Jan 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
SlipstreamAI commentedon Jan 1, 2026
I couldnt find any duplicates!!
jasonwei1002 commentedon Jan 4, 2026
Actually, the Codex team has said medium=auto
TheDarkchip commentedon Jan 4, 2026
@jasonwei1002 Do you have any sources for this?
jasonwei1002 commentedon Jan 4, 2026
ukerzel commentedon Jan 23, 2026
Feature request: task-type routing + bounded reasoning effort
Goal:
Automatically choose reasoning effort by task type, WITH user-defined bounds.
Example policy:
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:
qiankunli commentedon Apr 24, 2026
Adding another user scenario here rather than opening a duplicate issue.
For day-to-day Codex use, the missing UX is not only an
autovalue in config, but making it easy for Codex to recognize when a specific turn should switch reasoning effort before answering.Concrete examples:
mediumor lower for latencyhigh/xhighA useful UX would be:
autoreasoning mode with user-configurable min/max boundsAuto -> high: multi-file debugging + failed test loop/effort highor natural-language override (answer this with high reasoning)This would reduce manual switching friction without forcing every session to run at the highest reasoning level.
DontAskHow commentedon Apr 29, 2026
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:
Ideally Codex would support one or both of these:
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.
sunjiajunsunjiajun commentedon Jul 16, 2026
I would like to add one UX angle to this request.
Today there appears to be a partial workaround: do not explicitly set
modeland/ormodel_reasoning_effortinconfig.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:
/modelto choose a model/reasoning level persists that choice back to config, so a one-off selection can become the new default.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.
GregKM commentedon Sep 5, 2026
Adding a real-world data point in support of this request.
I recently used Codex for a long production workflow that moved through several very different phases: broad research, competitive analysis, configuration/architecture decisions, implementation, testing, browser/computer interaction, and deployment. I started with GPT-5.6 Sol at Ultra reasoning because the early decisions had a large downstream impact and I wanted to minimize mistakes and drift during a long session.
Ultra was useful during the initial research and architecture work, but once the plan was established and the task shifted toward implementation, it became clear that I was spending too much time and subscription quota on reasoning that was no longer necessary. I manually switched to GPT-6 Astra at Medium reasoning for the implementation/computer-use phase, then down to Low near the end as the remaining work became more routine.
That experience is exactly why an Auto mode like the one proposed here would be valuable. A long-running agent task does not have one fixed difficulty level. Ideally Codex would continuously adapt reasoning effort: start at the lowest level likely to succeed, escalate for high uncertainty, consequential decisions, difficult debugging, or repeated failures, and then de-escalate again once the difficult phase has passed.
I would especially like this to be quota-aware. For subscription users, the objective should be closer to maximizing successful task completion per unit of quota and wall-clock time, rather than simply maximizing reasoning on every turn. User-selectable policies such as Economy / Balanced / Max Quality, plus optional min/max reasoning bounds, could provide control without requiring users to manually change reasoning levels throughout a multi-hour workflow.
Dynamic de-escalation is just as important as escalation. In my case, the model did not suddenly become less capable when the project moved from architecture to routine implementation; the task simply stopped requiring Ultra-level deliberation. I ended up acting as the reasoning controller manually. This seems like something the harness/model should eventually be able to do itself.
avinashkanaujiya commentedon Sep 6, 2026
I'd also like automatic reasoning effort selection, specifically before the main model request is sent for each user prompt.
The desired flow is: submit a prompt → assess the request and relevant conversation context → choose a supported reasoning effort → send the main request with that effort already set. The first response to a difficult request should benefit from the chosen level; escalation only after a failed attempt would not cover this use case.
For example, a simple explanation or small edit could use a lower effort, while an ambiguous bug investigation or architectural request could use a higher effort. This should work with the user's selected model; automatically switching models is a separate concern.
Please expose Auto alongside fixed effort choices, preserve explicit manual overrides, and show which effort was selected. If selection fails, use a documented default. The motivation is to avoid manually judging the thinking level for every prompt while balancing response quality, latency, and usage.
TommyTrader-cpu commentedon Sep 15, 2026
Additional use case: long-running autonomous Codex work, Pro quota exhaustion, and quality-preserving adaptive reasoning
I would strongly support this feature, especially for long-running, goal-driven Codex tasks.
I use GPT-6 Astra for an ML/futures research and engineering project. A goal can run for many hours or days, and the agent decides which subtasks are necessary as it discovers new information. I cannot predict those subtasks at the beginning, so choosing one fixed reasoning level for the entire run is impractical.
A concrete example: after the recent global reset, my available weekly Work/Codex allowance on the $200/month Pro plan was exhausted by the following day while running Astra on Ultra with near-continuous use.
I mean the included subscription allowance, not $200 in API credits. This is a user observation, not a controlled benchmark or proof of incorrect metering. Any account-specific usage investigation should be handled separately through Support. However, it illustrates the practical importance of better compute allocation.
Why manually switching levels does not solve this:
The same run may move between file inspection, test execution, report generation, difficult debugging, architecture decisions, and research-validity checks such as data leakage or execution-model validation. The next critical decision may appear unexpectedly inside an otherwise routine phase.
Keeping everything at maximum effort may waste quota. Lowering effort globally may compromise precisely the decisions that need the most care.
I am also concerned about false savings. In my previous Sol-based workflow, excessive code growth and repeated rework became significant problems. Spending fewer tokens initially is not a saving if it produces fragile architecture, unnecessary abstractions, or research errors that require days of repair.
What would make an adaptive mode useful for this workflow:
In-run adaptation, not just initial prompt routing.
Let the project-aware agent propose reasoning changes as the work evolves, with the runtime enforcing the user's policy. It should automatically downshift again after difficult phases without requiring me to supervise every transition.
A quality-first option that keeps Astra.
Allow adaptive reasoning within the same model. Switching to a cheaper model should be a separate, explicit opt-in, not an unavoidable part of Auto mode. Preserve accumulated project context and checkpoints when changing effort.
Risk-aware escalation with objective checks.
Do not classify work only by prompt length or apparent simplicity. A tiny change can invalidate an entire research pipeline. Consider consequences, uncertainty, failed validations, and predefined critical areas. Escalate before high-risk decisions, not only after failures. Model confidence alone should not be sufficient.
Optimize total cost to a validated result.
Include the main agent, subagents, context processing, retries, repeated tests, and subsequent repair work. Evaluate Max versus Ultra on total completion cost and correctness, not their position in the menu. I am not claiming Ultra is always cheaper; delegation could help some tasks and add substantial overhead to others.
One budget across the entire goal and agent tree.
Provide optional per-goal and daily limits, early burn-rate warnings, and limits on agent fan-out and nesting. Reserve enough allowance to save a useful checkpoint and handover. When the budget is tight, pause safely rather than silently lowering validation standards or purchasing additional usage.
Avoid expensive idle and repetitive work.
Use event-driven waiting or appropriate polling backoff while tests and external jobs run. Detect repeated analysis, redundant investigations, and unnecessary code expansion instead of treating more activity or more code as progress.
Make the trade-offs visible and measurable.
Show effort changes and brief operational reasons, plus usage by phase and agent where feasible. Please also publish representative Astra reasoning-level comparisons against 5.6 Sol, including total usage, correctness, rework, and task duration—not just peak benchmark scores.
The desired outcome is not “always use less reasoning.” It is “spend the necessary reasoning where it protects the result, and avoid wasting it elsewhere.”
I would gladly keep Astra on demanding work. What I cannot realistically do is act as a manual compute scheduler for an autonomous agent pursuing a goal over several days.
robertn702 commentedon Oct 11, 2026
I built a local proxy that does this outside Codex until there's a native option: https://github.com/robertn702/reasoning-router
Before each model request, it asks a small classifier (Jev by default, or Cloudflare Clef, a local Laya model, and a few others) how much reasoning the next step needs and sets that effort on the request. That happens before the main request goes out, so a hard first prompt already gets high effort. It also runs on the requests Codex makes mid-turn after tool calls, so effort can change between phases of one long task. The change is sent as a
configuration_updateitem, so the prompt cache still hits.On a GPT-6 Astra task mix, routed effort solved 44 out of 44, same as fixed high, with about 14% fewer output tokens.
The catch for anyone here worried about Pro quota is that it only works with an OpenAI API key. ChatGPT subscription login isn't supported.