Repository navigation
Automatic cost-aware model routing in Codex #46366
Description
What variant of Codex are you using?
Codex desktop app
What feature would you like to see?
Please add an Automatic model/reasoning mode that chooses the least-expensive capable option per task or turn, escalating only when the task actually requires more capability or reasoning.
Today, users have to manually choose among Terra, Sol, Astra, and multiple reasoning levels. For typical mobile development across an iOS app and Firebase, it is difficult to predict when a task needs Terra Medium, Terra High, or Sol High. Leaving a higher setting enabled can consume usage quickly even for routine work.
The automatic mode should make a sensible default choice, escalate when it encounters ambiguity, cross-system work, auth/data risk, or repeated failure, and ideally show a brief indication of what it chose and why.
Additional information
I recently moved from a Claude 5x plan to Codex and strongly prefer Codex's overall agent experience. In Claude I rarely had to think about model selection or watch usage get consumed this quickly.
A cost-aware automatic mode would make Codex much easier to adopt as a daily programming agent: let the system manage the model/reasoning tradeoff while users stay focused on the work.
Activity
github-actions commentedon Sep 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
biuda0090-cmd commentedon Sep 27, 2026
Implementation and evaluation proposal: quality-preserving Auto for non-developers
Adding concrete requirements to this existing request from the perspective of a non-developer using the Codex desktop app on Windows for websites, content, analytics, and external administration. The goal is efficient verified task completion, not merely choosing a cheaper model.
Problem and requested outcome
Non-developers use Codex for work involving websites, content, analytics, and external administration. They can describe the outcome and consequences of mistakes, but cannot reliably choose the appropriate model or reasoning level. Selecting the strongest configuration for every step may waste allowance; selecting a cheaper configuration without adequate evidence may introduce omissions or operational errors.
Please provide an opt-in Auto mode that selects the least costly validated configuration meeting the task's required quality, risk, and authorization constraints. Select model, reasoning effort, and verification together. Manual selection and an explicit model lock must remain available. This is a product proposal, not a claim about current availability or a promise of error-free execution.
Quality contract and user control
Task difficulty, required quality, and consequences of failure must determine the execution requirements. Subscription tier constrains available models and credits; it must not define the quality a task needs.
Auto should operate only within an explicitly enabled routing policy and authorized allowance. A manual model lock must prevent switching unless the user changes it. If the available configurations or allowance cannot support the required quality and checks, disclose that limitation and preserve a checkpoint. Do not silently downgrade quality, remove required verification, exceed the allowance, purchase credits, or enable a paid upgrade.
Do not repeatedly ask non-developers to choose model names. Explain the relevant limitation in terms of the work: what can be completed reliably, what remains unverified, and which action needs a decision.
Execution and state guarantees
Route at meaningful task boundaries. Consider reversibility, public or financial consequences, conflicting instructions, missing evidence, multimodal requirements, available tools, and validated performance for the task family. Thread length alone should not determine routing. Escalate an uncertain subtask without rerunning completed work.
Maintain a versioned task record containing current intent, latest corrections, permissions, exclusions, deadlines, spending limits, completed actions, evidence timestamps, and unresolved uncertainty. Every model handoff and resumed session must use the current record. Check that recorded authorization still covers the proposed action. Historical permissions must not override a later restriction; switching models must not broaden consent.
Use deterministic checks where possible and relevant tool results or public-state verification for external changes. Escalation should depend on failed checks, conflicting evidence, repeated retries, and independently measured task-family reliability, not self-reported model confidence alone. Authentication failures and policy blocks must remain boundaries.
Parallelize independent work only. Protect shared files and external objects against conflicting writes, and include duplicate-context and review overhead in cost estimates. Higher reasoning or more workers should not automatically be treated as better value.
Three-stage MVP
Instrumentation and shadow routing. Record sanitized task-family and risk labels, constraint snapshots, configuration choices, validator outcomes, latency, and actual credits. Recommend configurations in shadow mode without changing execution. Existing user selections are not ground-truth optimal labels.
Opt-in bounded Auto. Start with supported read-only tasks and reversible local edits. Route only among configurations validated for each family. Preserve approval requirements and model locks. Unsupported tasks should retain the selected configuration when suitable, or surface the limitation; they must not silently fall back to an inadequately validated cheaper configuration.
Staged external-operation support. Add consequential workflows only after passing evaluation gates, with independent validation before writes where appropriate. Version the policy and state format, provide a kill switch, and support rollback to the last validated routing policy. Recover external changes only when safe and authorized.
Evaluation and release criteria
Compare Auto against both a strong fixed configuration and realistic economical fixed configurations on representative tasks. Use paired scenarios, randomized assignment, and blinded assessment where feasible. Include novice users, multi-turn corrections, interruptions, stale records, expired authentication, deadlines, and public/private state differences.
Pre-register sample sizes, severity categories, and task-family non-inferiority margins. A single text comparison cannot establish overall model accuracy, operational reliability, or savings. Report uncertainty intervals and underpowered results rather than declaring equivalent quality.
Measure:
Release only when family-specific quality meets predeclared margins, critical-failure upper confidence bounds meet release limits, hard constraints survive handoffs, and measured savings justify routing overhead. Zero observed failures in a small sample is not evidence of zero risk.
Explainability and requested follow-up
Provide a compact receipt showing the selected configuration, a brief evidence-based rationale, switches, checks completed, actual credits when available, and remaining limitations. This requires decision summaries, not private chain-of-thought.
Please consider these quality, authorization, and evaluation requirements when triaging this existing Codex product-routing request. Diagnostic sharing should be opt-in, previewable, and sanitized; exclude credentials, customer conversations, account identifiers, and full threads by default.
shay-berman commentedon Oct 18, 2026
+1. I'd like Codex to choose the appropriate model and reasoning effort automatically as a task changes, reducing token usage and cost while preserving quality—without manual switching or a custom harness. A concrete comparison showing savings and task quality would help evaluate this.