Add a live model-suitability indicator with green/yellow/red recommendations

What variant of Codex are you using?

Codex App and ChatGPT Work

What feature would you like to see?

Summary

Add a small, live model suitability indicator to the model/reasoning selector that continuously evaluates whether the currently selected model and reasoning effort are appropriate for the task.

The indicator could use a simple traffic-light state:

• Green — current model/reasoning is appropriate.
• Yellow — likely sub-optimal; a cheaper or stronger configuration would probably be better.
• Red — large mismatch between the selected configuration and the apparent task requirements.

This is intentionally different from fully automatic model routing. Many users want to keep manual control, but need clear feedback about whether their choice is sensible.

Example UX

For an appropriate selection:

🟢 Terra Medium — appropriate
Estimated task class: moderate troubleshooting

For likely over-allocation:

🟡 Terra High — probably excessive
Recommended: Terra Medium
Expected capability impact: low
Expected usage saving: significant

For likely under-allocation:

🟡 Luna Medium may be insufficient
Multiple unsuccessful diagnostic cycles detected.
Recommended: Terra Medium

A red state could be reserved for a major mismatch, such as a very expensive/high-reasoning configuration on a trivial task, or a lightweight configuration repeatedly failing on a difficult task.

Dynamic behavior

The recommendation should change as the task evolves.

For example, a troubleshooting session might begin green on Luna Medium. If repeated diagnostic cycles fail, it could turn yellow and recommend Terra Medium. If the task later becomes genuinely complex or ambiguous, Terra High might become appropriate and the indicator could return to green.

Useful signals could include:

• task complexity and ambiguity;
• repository/context size;
• expected or actual tool use;
• reasoning/verification burden;
• retries and repeated failed diagnostic cycles;
• task phase (research, implementation, testing, recovery, deployment);
• current model and reasoning effort;
• relative plan-usage cost of available configurations.

The goal is not simply to prefer cheaper models. A model that is too weak can waste more usage through retries. The indicator should recommend the lowest-cost configuration that is still likely to complete the task reliably.

Why this would be useful

Users currently have to understand the capability/cost trade-off between every model and reasoning tier before each task, and that choice can be wrong in either direction.

A live suitability indicator would:

• warn before substantial usage is spent on an unnecessarily expensive configuration;
• prompt escalation when a weaker configuration is demonstrably struggling;
• teach users the model/reasoning hierarchy through concrete task-specific feedback;
• preserve manual control;
• reduce accidental depletion of rolling usage allowances;
• reduce unnecessary inference compute when a lighter configuration can complete the task reliably;
• make the model picker substantially easier to use.

The warning should ideally appear before substantial agent/tool work begins, and then continue to re-evaluate during long-running sessions.

Resource and environmental efficiency

There is also a broader systems benefit. Avoiding unnecessarily powerful models or excessive reasoning effort reduces avoidable inference work: less accelerator time, electricity use, cooling demand, and datacentre load for tasks that do not need that level of compute.

The environmental impact of any individual task is difficult to quantify and should not be overstated. But at product scale, systematically matching task difficulty to the least compute-intensive configuration that can complete it reliably could reduce aggregate energy demand and associated emissions, depending on the datacentre energy mix.

This makes model suitability useful not only for conserving a user's plan allowance, but also for improving compute efficiency across the service.

Relationship to existing requests

This is complementary to existing automatic-routing proposals:

• #34278 — per-thread Auto mode routing both model and reasoning effort
• #34388 — Smart Mode for automatic model/reasoning selection
• #43868 — Smart model picker option for automatic task routing
• #38911 — task-level outcome and usage history for model efficiency analysis

Those issues primarily focus on automatic selection/routing or retrospective analytics.

This request focuses on a distinct UX: continuous advisory feedback for users who manually select the model and reasoning level.

It would also be useful even if Smart/Auto routing is eventually implemented, because the same indicator could explain whether a manual override remains appropriate and why the automatic route was chosen.

Additional information

A key requirement is that the advisory itself should not require a second expensive model turn. It should use product-side/task metadata, a lightweight classifier, or other low-overhead routing logic where possible.

Recommendations should be transparent and actionable: name the suggested model and reasoning effort, state briefly why, and indicate whether the current choice appears overpowered or underpowered.

The issue names no files, tests, or implementation entry points. Start by reviewing related requests #34278, #34388, #43868, and #38911, then determine where the model/reasoning selector and advisory logic live; done means a continuously updated, transparent recommendation that preserves manual control without requiring a second expensive model turn.