Repository navigation
[Feature Request] Per-thread Auto mode that routes both model and reasoning effort #34278
Description
Maintainer triage summary — 2026-08-01
Observed behavior
- On macOS, a third-party prototype could not atomically update both model and reasoning effort before submission. An app-server shim caused
Error submitting messageand was removed. - In an independent Windows reproduction with no model/effort pins, trivial and complex tasks all remained on
gpt-5.6-sol; spawned workers remained on Sol with medium reasoning. - The current subagent documentation says that unpinned model/effort settings can be selected based on task needs, while observed Desktop behavior appears to inherit the current/default route. The intended scope is unclear.
Maintainer decision requested
- When Desktop/app-server starts a turn without explicit model and effort values, is the intended behavior task-aware selection or thread/default inheritance?
- Is there, or is there a plan for, a supported atomic pre-submit operation that:
- applies both model and reasoning effort;
- preserves the draft and attachments;
- creates exactly one user message and one turn;
- exposes the effective route in transcript/app-server truth; and
- fails before submission if the route cannot be applied?
- If a complete Auto mode is not currently planned, would the team consider a staged implementation:
- Stage A: expose the effective model, effort, and selection reason;
- Stage B: provide an atomic set-next-turn route operation;
- Stage C: provide native per-thread Auto with user-defined model/effort bounds?
Cross-surface relevance
The same contract affects Desktop, CLI, IDE, app-server clients, and subagents. Related requests: #8649, #20855, and #26996. Independent Windows evidence is linked in the comments below. Documentation clarification: #36422.
What variant of Codex are you using?
Codex Desktop on macOS. The same capability would also be useful in the CLI and IDE extension.
What feature would you like to see?
Summary
Add a per-thread Auto mode that chooses both the model and reasoning effort before each turn.
With GPT-5.6 Sol, I built a local macOS prototype called Codex Auto to explore this workflow. The user selects 1–5 permitted models and the allowed effort tiers for each model. Before a turn starts, the router makes two separate decisions:
- Model: based on judgment difficulty, ambiguity, risk, and prior failures.
- Reasoning effort: based on execution scope, verification burden, depth, and parallel work.
The selected model and effort should be visible in Codex's native selector, with a short reason. Manual selection must always win.
Why this is needed
Real Codex work is not uniformly difficult. A single thread can move between:
- mechanical edits, searches, formatting, and running known commands;
- normal multi-file implementation;
- unknown-root-cause debugging, architecture, migration, privacy, or security decisions.
A fixed model/effort combination creates two expensive failure modes:
- Over-allocation: a frontier model at high effort spends unnecessary tokens and latency on simple work.
- Under-allocation: a weaker model or low effort misses hidden complexity, causing retries, larger patches, more review, and more total token usage.
The useful metric is not the price of one turn. It is total task-completion cost: tokens + latency + retries + review + risk. An Auto mode should downshift routine work and upshift when uncertainty or consequences justify it.
This should materially reduce wasted tokens in suitable workloads, but the product should measure it with controlled evaluations instead of advertising an unverified savings percentage.
Proposed UX and safeguards
- Per-thread Auto toggle, off by default.
- User-selected pool of 1–5 models; Auto never escapes that pool.
- Per-model allowlist/min/max for reasoning effort; Ultra requires explicit opt-in.
- Quality, balanced, and speed policies.
- Model and effort are routed independently.
- Native selector always displays the effective model and effort.
- A short, inspectable reason is shown for the current turn.
- Manual override/pin is authoritative.
- Hysteresis prevents rapid oscillation, but cannot override a risk floor.
- No automatic rerun after tool side effects.
- If the route cannot be applied atomically, keep the draft and attachments intact and do not silently send with the wrong settings.
- Raw prompts, assistant text, attachments, and full paths are not required for persistent routing telemetry.
Prototype evidence and the important failure
The prototype currently has 334 passing automated tests:
- 287 XCTest tests
- 23 Swift Testing tests
- 24 pytest/Hypothesis tests
They cover per-thread isolation, 1–5 candidate boundaries, per-model effort allowlists, manual override, fallback, privacy, native-selector readback, transcript verification, and single-admission safeguards.
The real Desktop test revealed the most important product boundary: a third-party extension does not currently have a supported, atomic pre-submit primitive for updating both model and effort. A transparent app-server shim could change the visible model, but real Desktop submissions then produced Error submitting message. I removed the shim and restored the official app-server path instead of presenting the prototype as production-ready.
That result is why this capability belongs in Codex itself rather than in a fragile third-party proxy.
Product primitive that would unblock this
A supported host-level operation, conceptually:
set_next_turn_route(thread_id, model, reasoning_effort, reason, policy_revision)
It should:
- validate the model/effort combination against the live catalog;
- apply the route before the user message becomes a turn;
- update the native selector;
- preserve the original message and attachments;
- create exactly one user message and one turn;
- expose the actual model/effort in the turn/transcript truth;
- return a clear failure without starting the turn when the route cannot be applied.
Codex itself could then supply the built-in policy, while an optional extension API could allow local/custom policies within user-defined caps.
Acceptance criteria
- Auto can select different models and effort tiers on different turns in the same thread.
- New threads remain native/off unless the user enables Auto.
- The native selector and transcript agree with the effective route.
- One submit produces one user message and one turn, including with attachments.
- Manual overrides always win.
- Routing failures never silently use an unintended model/effort.
- Evaluation reports total completion cost and quality, not only per-turn token use.
Related
- “Auto” reasoning effort (dynamic tiering) for Codex CLI #8649 — harness-driven Auto reasoning effort.
- Feature request: Model-callable reasoning effort control ("Reasoning Gearbox") for auto mode #20855 — model-callable reasoning “gearbox”.
- Allow changing model/speed after a plan is generated before starting implementation #26996 — different model/speed choices for planning and implementation.
This proposal extends the same direction to joint model + effort routing, with per-thread user control and native Desktop synchronization.
Activity
whatthecodemean commentedon Jul 27, 2026
Windows reproduction evidence from Codex Desktop supports this request.
Environment:
0.146.0-alpha.3.1modelandmodel_reasoning_effortkeys absentControlled test:
2+3.Observed effective runtime route from session
turn_contextmetadata:gpt-5.6-sol.gpt-5.6-solwithmediumreasoning.No model downshift or effort change occurred between the trivial and complex samples. In this build, leaving the route unpinned behaved as default-model inheritance, not complexity-based routing.
There is also a workflow continuity boundary for Git projects: a fresh Codex worktree is created from the committed baseline, so uncommitted routing guidance in the source working directory is not visible to the new task.
The requested native primitive should therefore cover both model and effort, apply before admission of each turn, and expose the effective route in transcript/session truth. It should also support:
A useful role-aware baseline would be Luna for deterministic/high-volume work, Terra for everyday implementation and bounded debugging, and Sol for ambiguous/high-consequence work, with reasoning effort selected independently.
Could the team clarify whether unpinned routes are currently expected to perform any task-sensitive selection in Desktop, or only inherit the current/default Power route? A supported atomic
set_next_turn_route(thread_id, model, reasoning_effort, reason, policy_revision)-style operation would make this implementable and auditable.whatthecodemean commentedon Jul 27, 2026
Follow-up with a sanitized local shadow implementation and validation result.
I implemented a central, five-layer adaptive routing prototype for a large local workflow catalog:
The prototype remains read-only shadow routing. It does not modify workflows, invoke a model, or submit Codex turns.
Sanitized validation snapshot:
Independent review found and the implementation corrected several failure modes: untrusted manual override injection, budget-driven route downgrades, incomplete total-budget enforcement, phase-change hysteresis leakage, archive/alias sampling pollution, unknown legacy-model crashes, deferred events becoming permanently ineligible, same-run duplicate charging, mode injection, and incomplete source binding.
Important evidence boundary: this validates policy behavior, privacy, state transitions, stratified coverage, and idempotency. It does not yet prove better task quality, real token savings, or lower end-to-end completion cost, because shadow routing does not execute the selected model.
The remaining blocker is still a supported atomic pre-submit host operation. A useful primitive would be equivalent to:
set_next_turn_route(thread_id, model, reasoning_effort, reason, policy_revision)It would need to preserve drafts/attachments, create exactly one message and one turn, update the native selector, expose the effective route in transcript/session truth, and fail closed before submission. Without that boundary, a local router can recommend and audit a route, but cannot transparently and safely apply it to every ordinary Desktop turn.
whatthecodemean commentedon Jul 28, 2026
Follow-up after checking the current public docs, Support, and adjacent usage/performance reports.
There is now a documentation/behavior ambiguity that may explain why users expect task-sensitive routing but do not observe it in Desktop:
modelandmodel_reasoning_effortare not pinned, Codex can choose a setup balancing intelligence, speed, and price for the task, potentially favoring Terra for scans and a higher-effort GPT-5.6 configuration for demanding reasoning./model, or launch-time model selection.Could maintainers clarify the intended contract?
turn/startomitsmodelandeffort, does the app-server invoke a task-aware selector, inherit the thread route, or resolve the current global/default route?The cost side is also broader than model choice. Current open reports describe repeat compaction and reprocessing (#35032, #35226), loss of recoverable task state at usage exhaustion (#35784), and large weighted-usage differences from model/tool-call scheduling (#35050). This suggests that a useful native Auto contract should optimize total completion cost—quality, retries, model cycles, context growth, compaction, and recovery—not simply choose the cheapest model for one turn.
A sanitized local five-layer controller now leaves all Codex model/effort fields unpinned and only controls admission, output budget, context thresholds, loop detection, and handoff. It passes 40/40 local tests, but it intentionally does not claim token savings and cannot prove native route adaptation without an observable selector contract.
whatthecodemean commentedon Jul 28, 2026
Product architecture proposal: make Auto routing cheaper than the waste it prevents
The discussion above identifies the host/API boundary. This follow-up describes the product architecture I would now request from OpenAI.
A native Auto mode should not run a full frontier agent before every user turn. That could consume enough tokens and latency to erase the savings from routing. The routing layer should be a lightweight control plane with a strict overhead budget.
Proposed hybrid design
Deterministic local fast path
Tiny semantic router for ambiguous cases
Native atomic admission
Event-triggered reassessment, not per-message analysis
Closed-loop evaluation
Required user controls and observability
Acceptance test
Auto should demonstrate, on frozen representative tasks, that:
routing overhead + routed completion cost < fixed-default completion costwhile meeting the same quality and safety thresholds. Results should be reported by workload stratum rather than as one universal savings percentage.
This architecture would make the feature practical for large workflow catalogs: model releases update the central capability/cost registry and router policy, instead of requiring users to manually edit every workflow. A local rules-only controller can approximate the safeguards today, but it cannot provide semantic routing or atomically apply the route without native product support.
rjbarbour commentedon Aug 5, 2026
This matches my day-to-day Codex workflow. I frequently change model and reasoning effort within the same thread as work moves between mechanical edits, investigation, architecture and verification. I currently have to open menus repeatedly, which makes it harder to manage latency, capability and token usage.
My immediate need is direct manual control: an expandable routing tray beneath the composer with one-click segmented controls for model, reasoning effort and ⚡ Fast. That would already solve frequent in-thread switching and the plan-to-implementation hand-off.
Auto should be opt-in and configured under Advanced, where users can choose the permitted model pool, allowed effort range, speed policy and any cost/latency constraints. When Auto is enabled, the normal tray should still show the effective choice for the next turn—for example Sol · Medium · Fast—plus a short reason such as “routine implementation task”. Selecting any manual control should provide an obvious override.
The important UX principle is that Auto must be visible and inspectable, but it should not replace quick manual control or silently change the route.
whatthecodemean commentedon Sep 4, 2026
Follow-up (2026-09-05): checked on Windows Desktop 26.901.4073.0. The agent-visible task controls now expose model and reasoning overrides, but their documented omission semantics are different: new tasks use the user's configured default; follow-up messages keep the existing task settings. Neither is evidence of complexity-sensitive Auto routing.
For users with many existing tasks, the remaining practical gap is a supported reset-to-default/Auto operation that does NOT submit a prompt or start an inference run. Can maintainers identify an API or UI operation for this, including a conditional idle-only bulk update that skips running tasks and preserves drafts/attachments? Shared project/global config changes are not equivalent because they can affect active tasks.
The current Subagents documentation now describes explicit spawn values, [agents] defaults, parent inheritance and custom-agent precedence: https://learn.chatgpt.com/docs/agent-configuration/subagents . This helps explain inheritance (related documentation issue #36422), but does not establish adaptive model+effort routing for ordinary existing Desktop tasks.
No new routing benchmark or token-saving claim is being made here. We have not bulk-started tasks or edited the live task database to simulate this capability. A supported idle-task migration/reset contract and a way to read back the effective route would let users test this safely without manually changing hundreds of tasks.
otikk commentedon Sep 5, 2026
Strong +1 for this direction. The key value is not simply having a stronger model available, but making Codex economically intelligent about when to use it.
A practical workflow should look like this:
Ideally the user could just choose Auto / Fast / Deep, while Auto transparently routes model + reasoning effort within user-defined bounds.
This matters especially because current hierarchical delegation can become additive instead of substitutive: see #41817, where the expensive root continued substantial work while cheaper workers also worked, producing much higher total token activity. A good Auto router should avoid that failure mode by making delegated work genuinely replace expensive parent work where possible.
For real coding workflows, this kind of orchestration would be a bigger usability and efficiency improvement than simply introducing successively stronger default models.
otikk commentedon Sep 9, 2026
One more practical user-perspective follow-up after using Cursor and Codex side by side.
The biggest difference is becoming less about raw model quality and more about routing + billing ergonomics.
In my current Cursor workflow, I can use a strong model for the difficult parts while the product appears to handle a lot of routine work through a faster/lower-cost path (for example Composer Fast). I am not claiming to know Cursor's exact internal routing implementation, but the user experience is noticeably different: I can keep working for long sessions without feeling that every repository search, mechanical edit, test run, formatting pass, or straightforward implementation step is consuming the same expensive reasoning budget.
That is exactly the behavior I would like Codex Auto to provide natively:
The second part is billing UX. For heavy daily Codex use, the current experience can feel like:
subscription -> included allowance -> hard friction -> manually buy more credits.
A much more natural developer workflow would be:
subscription -> included Codex usage -> automatic PAYG/on-demand usage -> user-defined monthly spending cap.
That way a user could simply set, for example, "allow up to $25 additional usage this month" and keep working. No manual credit top-up step, while still retaining strict cost control.
This matters because a strong model is not the problem by itself. The problem is using expensive inference for work that does not require it, then adding billing friction when the allowance is exhausted.
From a user's perspective, Cursor currently feels more efficient for long coding sessions even when the underlying model quality is comparable, because the product gets out of the way. It would be a shame if Codex lost power users primarily because routing and usage UX make the strongest model economically awkward to use.
So my preferred product surface is still very simple:
Auto / Fast / Deep
The important metric should be successful task completion per unit of cost, not maximum model strength on every turn.
mkostrus-gif commentedon Sep 23, 2026
I strongly support this request. I use Codex Desktop intensively and currently choose both the model and reasoning effort manually, often several times within one task.
The target should be a native, opt-in Auto mode that minimizes the total cost of a successfully completed task—not just per-turn price. It should start with the cheapest allowed route likely to succeed, verify the result, and escalate the model and/or effort when ambiguity, risk, failed checks, or repeated attempts justify it.
For trust and control, please include:
This would reduce both over-allocation and costly retries while preserving user control.