[Feature Request] Per-thread Auto mode that routes both model and reasoning effort

Windows reproduction evidence from Codex Desktop supports this request.

Environment:

• Codex Desktop / app-server CLI runtime: 0.146.0-alpha.3.1
• Windows, local projects
• Global model and model_reasoning_effort keys absent
• No per-task or per-agent model/effort overrides supplied

Controlled test:

1. New workflow, bounded configuration validation task.
2. Existing workflow, trivial read/count task.
3. Existing Git workflow, cross-layer diagnostic design task.
4. Spawned worker asked only to calculate 2+3.
5. Spawned worker asked for a compact multi-layer fault-analysis plan.

Observed effective runtime route from session turn_context metadata:

• All three top-level tasks: gpt-5.6-sol.
• Both spawned workers: gpt-5.6-sol with medium reasoning.

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:

• legacy-route migration into the current GPT-5.6 family by workload role;
• phase-boundary reassessment within an existing thread;
• manual override as authoritative;
• user-defined model/effort caps and risk floors;
• hysteresis to avoid route oscillation;
• no automatic rerun after side effects;
• privacy-preserving routing telemetry;
• evaluation by total completion cost (quality, retries, latency, token usage, and failure cost), not per-turn price alone.

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.

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:

1. hard constraints and risk floors;
2. independent model and reasoning-effort scoring;
3. reassessment at phase/failure/contradiction/context/risk changes;
4. immediate escalation plus evidence-gated de-escalation (hysteresis);
5. budget governance that may defer admission but never silently crosses the selected quality/risk floor.

The prototype remains read-only shadow routing. It does not modify workflows, invoke a model, or submit Codex turns.

Sanitized validation snapshot:

• 16 curated roots plus 42 trusted active registry roots, with 12 overlapping: 46 unique shadow-discoverable roots.
• Deterministic stratified sample: 13 roots across deterministic content, software implementation, research/analysis, operations/diagnostics, and high-consequence strata.
• Shadow routes: Terra/low 3, Terra/medium 3, Terra/high 3, Sol/high 4.
• Task-admission smoke cases separately produced Luna/low for a deterministic count, Terra/medium for ordinary implementation, and Sol/xhigh for an irreversible production migration.
• 26 unit/state-machine/privacy/sampling/transition tests passed.
• Exact replay of all 13 sampled events produced 0 new decisions, 13 duplicate detections, no extra budget charge, and an unchanged state hash.
• Public telemetry uses a strict allowlist: route, effort, confidence, layer outcomes, budget action, reasons, and a run-local numeric index only. It excludes workflow/case identifiers, paths, prompts, assistant text, and attachments.
• Run identity and the final commit bind hashes for the sample, policy, router, runner, classifier, sampler, state, summary, and public decision log.

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.

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:

• The current Subagents documentation says that, when model and model_reasoning_effort are 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.
• OpenAI Support case 12256212 stated that an unpinned Codex Desktop task uses the current/default selection and is not automatically re-routed per task or per turn; supported user controls are the picker, /model, or launch-time model selection.
• In the Windows Desktop controlled sample already posted above, 0 model/effort pins still yielded Sol/medium for trivial and complex top-level work and for both trivial and complex spawned workers.

Could maintainers clarify the intended contract?

1. Is the task-sensitive statement limited to custom agent/subagent configuration, ChatGPT Work, or a staged rollout, rather than ordinary Desktop top-level tasks?
2. When turn/start omits model and effort, does the app-server invoke a task-aware selector, inherit the thread route, or resolve the current global/default route?
3. Can an existing thread ever reassess its route at a phase boundary, or is a fresh thread/subagent required?
4. Can the transcript/app-server expose both the effective route and a machine-readable selection reason so users can distinguish native auto-selection from default inheritance?
5. Is there a supported atomic pre-submit operation for applying both model and effort, or is this still unavailable?

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.

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

1. Deterministic local fast path

• Extract only bounded features: task type, requested actions, file/scope count, context growth, tool requirements, failure history, reversibility, and risk.
• Apply hard constraints, privacy rules, user caps, and risk floors without a model call.
• Immediately route obvious low-risk or high-risk cases.

1. Tiny semantic router for ambiguous cases

• Use a distilled classifier or other small purpose-built model, not a general-purpose coding agent.
• Return only structured output: demand class, confidence, recommended model family, effort range, and reassessment triggers.
• The router could run locally in the client for privacy/latency, or server-side where OpenAI can use the current catalog, availability, price, and quality telemetry.
• If server-side, routing overhead should not silently consume the user's primary Codex allowance. It should be platform overhead or separately visible and bounded.

1. Native atomic admission

• Apply model and reasoning effort before the message becomes a turn.
• Preserve the draft and attachments.
• Create exactly one user message and one turn.
• Fail closed if the selected route cannot be applied.

1. Event-triggered reassessment, not per-message analysis

• Reassess at task start and only when phase, ambiguity, risk, context, validation burden, contradiction, or repeated failure changes materially.
• Use hysteresis: escalate immediately when evidence requires it, but downshift only after stable evidence.
• Do not attempt to predict the entire future task at admission. Use rolling reassessment at observable phase boundaries.

1. Closed-loop evaluation

• Optimize total completion cost: quality, retries, model cycles, cached/uncached input, output/reasoning, latency, compaction, validation, and recovery cost.
• Compare the chosen route with privacy-safe shadow alternatives on a small sampled fraction.
• Detect routing regret: a cheap route that causes retries can cost more than starting stronger; an expensive route that over-processes a mechanical edit is also a failure.

Required user controls and observability

• Auto model pool and per-model effort bounds.
• Explicit quality/risk floor; Max/Ultra require opt-in.
• Manual selection always wins.
• Effective model, effort, route reason, confidence, and reassessment event visible in the UI and transcript/app-server truth.
• Separate counters for routing overhead and task execution usage.
• No persistent raw prompts, source text, attachments, or full paths in routing telemetry.
• A zero-model fallback when the lightweight router is unavailable.

Acceptance test

Auto should demonstrate, on frozen representative tasks, that:

routing overhead + routed completion cost < fixed-default completion cost

while 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.

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.

<img width="864" height="432" alt="Image" src="https://github.com/user-attachments/assets/da3990c4-9378-46e0-9681-4d9abd3f03fc" />