What variant of Codex are you using?

IDE Extension

What feature would you like to see?

Dynamic Mode for Codex — Adaptive Model and Effort Router

Objective

Add to Codex a Dynamic Mode that removes the need for the user to manually choose, before every request, the model and the level of reasoning effort.

The user should be able to simply describe what they want to achieve. The system should automatically choose the model and effort best suited to each individual phase of the work, re-evaluating them when the nature of the work changes.

The goal is not simply "to use the cheapest model", but to achieve the best balance between required capability, speed, reliability, and consumption of the usage allowance.

User experience

In the model selector, next to "Default" and before the list of individual models, an entry such as the following could appear:

Dynamic Mode

When it is active, the user keeps working normally: they write the request and press Enter. They do not have to interrupt their flow to decide each time which combination of model and effort to use.

The model selected at that moment can remain visible in the interface until the work starts. When the router decides to change it, Codex can briefly show the switch, for example:

GPT-6 Sol → GPT-5.6 Terra

The selector should therefore also reflect the model actually being used at that moment, making the behavior transparent.

Specialized preliminary router

When a new request arrives, a lightweight, specialized router steps in before the actual execution.

The router must not perform the task. It must quickly analyze what is needed to perform it and return an operational decision, for example:

• complexity of the work;
• quantity and type of files to inspect or modify;
• risk of regressions;
• need for reasoning;
• tools required;
• planned checks and tests;
• any subsequent steps that are already foreseeable;
• most appropriate model;
• sufficient level of effort.

The router must be designed specifically for this function: not a generic agent chosen at random for each request, but a component with a stable task and a structured response.

Advance analysis of possible branches

Where possible, the initial analysis should also anticipate plausible scenarios.

Example: the user reports that the bottom of some pages gets cut off when the content loads slowly. The analysis might uncover two possible causes:

• Scenario A: a local problem, solvable by modifying a limited part of the code;
• Scenario B: a structural problem that requires a broader change to the architecture.

If the router is already able to identify these scenarios, it should also determine in advance which model/effort combination would be appropriate for each of them.

When Codex asks the user which path to follow and the user chooses A or B, it should not be necessary to repeat the routing analysis from scratch. The decision for that branch is already available.

A new router pass is needed instead if an unforeseen Scenario C emerges during the work or if the nature of the problem changes substantially.

This reduces latency, unnecessary consumption, and duplicated work.

Dynamic routing within the same task

The choice should not happen only once at the start of the session.

A long piece of work can contain phases with very different needs. For example:

1. understanding a complex bug;
2. modifying a delicate component;
3. making a simple change in a second file;
4. running tests;
5. fixing a small regression;
6. committing and pushing.

It makes no sense to necessarily keep the same model and the same level of effort for all of these phases.

Dynamic Mode should therefore re-evaluate the routing when a substantially different unit of work begins, without continuously running unnecessary analyses.

A powerful model can be used for the part that requires it and, once that phase is finished, Codex can automatically go back to a lighter model for simple operations such as routine checks, small modifications, or commit/push.

Likewise, if a phase that was initially simple becomes more complex than expected, the system can escalate to a higher model or effort.

Feedback from execution

The router should not base its decisions solely on the initial estimate of the task. If that first analysis is wrong, the system risks reinforcing the same mistaken choice instead of correcting it, since it has no way of noticing the error.

For this reason, it is useful for the router to also receive a low-cost external signal coming from the execution side: for example, failed tests, unexpectedly modified files, or commands that do not complete successfully.

This signal does not require a full new analysis, but it allows the router to react to what actually happened during the work, rather than simply re-reading and confirming its initial plan. In this way, any escalation or change of course happens based on concrete evidence, not just a new theoretical estimate.

Fundamental principle: sufficient capability, not maximum capability

The criterion should not be:

"Which is the most powerful model available?"

but:

"Which model/effort combination has sufficient capability to carry out this phase of the work well?"

This avoids both the excessive use of the most expensive models and the opposite problem: choosing a model that is too weak, which makes mistakes, loses context, or forces the work to be redone, ending up consuming more resources.

The optimization must therefore consider the overall cost of the useful result, not simply the nominal cost of the individual call.

User control modes

The feature should be optional and coexist with manual selection.

There could be at least two behaviors:

Automatic: Codex performs the switches autonomously and immediately continues the work.

Automatic with confirmation: when the router proposes a significant switch, Codex shows the recommended model and effort and allows the user to confirm before proceeding.

Expert users also keep the ability to manually select model and effort whenever they wish.

Consumption transparency

The router's analysis has its own small computational cost. This should be taken into account and, if possible, made transparent.

The principle is that this overhead must be minimal compared to the real work and justified by the savings obtained by avoiding oversized models, duplicated analyses, or failed attempts with insufficient models.

If Codex shows usage statistics, it would be useful to distinguish the consumption related to routing from that related to task execution.

Complete example

The user writes:

"In my extension some pages get cut off at the bottom, especially when they load slowly. Find the problem and fix it."

1. The router quickly inspects the necessary context.
2. It identifies complexity, risk, and possible branches.
3. It establishes the appropriate model and effort for the initial investigation.
4. Codex automatically performs the switch and starts the work.
5. If two plausible solutions emerge, Codex presents them to the user; the router has already prepared, when possible, the routing for both.
6. The user chooses a solution.
7. Codex immediately proceeds with the combination already planned, without an unnecessary second analysis.
8. If a new and substantially different problem emerges during implementation, the router is called again.
9. Once the complex part is finished, tests and simple operations can be automatically assigned to a lighter combination.
10. The interface makes the switches visible without interrupting the flow.

Why it is different from a simple "automatic model selection"

A feature that merely says "simple task → small model, difficult task → large model" solves only part of the problem.

The proposal described here instead concerns a continuous but non-redundant orchestration system that:

• understands the task before executing it;
• anticipates, when possible, its branches;
• associates model and effort with the different phases;
• reuses decisions already made;
• re-evaluates only when the problem really changes;
• can increase or decrease capability during the same piece of work;
• keeps switches visible;
• always leaves the user the possibility to choose manually or request confirmation.

In essence, the user chooses the result; Codex dynamically manages the resources needed to achieve it.

Expected result

Dynamic Mode should make Codex simpler for those who do not want to learn the differences between dozens of model/effort combinations and, at the same time, more efficient for expert users.

The ideal result is a flow in which the user does not have to keep asking themselves:

"Which model should I choose now, and with which level of effort?"

That decision becomes part of the orchestration of the work, while manual choice always remains available.

dynamic_mode_codex_github_ready (2).md

Additional information

I’m aware of existing proposals for automatic model and reasoning-effort selection. I’m opening this as a separate issue because this proposal is materially different in scope: it describes a concrete dynamic routing mechanism, including preliminary task analysis, anticipated branches, non-redundant re-routing, and model/effort switching between different phases of the same task. The attached proposal explains these differences in detail.

Related issues:

• Automatic cost-aware model routing in Codex #46366 — cost-based automatic routing
• CLI: Make Auto the default model selection and resolve it on the first task #47785 — Auto as the CLI default, resolved once on the first task
• [Feature Request] Per-thread Auto mode that routes both model and reasoning effort #34278 — per-thread Auto mode for model and reasoning effort
• Add a Smart model picker option that automatically routes each task to the right Codex model #43868 — Smart model picker across Codex surfaces
• “Auto” reasoning effort (dynamic tiering) for Codex CLI #8649 — automatic reasoning effort for the CLI

The main difference in this proposal is model/effort switching between different phases of the same task, with pre-computed routing for anticipated branches and re-routing triggered by execution feedback. For example, #47785 explicitly keeps the selection fixed for the session and does not cover switching within an active task.