Allow users to configure the model pool used by Auto mode

Describe the feature or problem you'd like to solve

Auto mode can select from every model available under a user's plan and organization policies, but users cannot define which of those models Auto is allowed to use. This makes Auto's cost and behavior difficult to predict. A user may want an expensive or specialized reasoning model available for intentional manual selection without allowing Auto to select that model unexpectedly during a long-running implementation, review, or research task. Disabling a model globally is not an adequate solution because it removes the model from manual workflows too. Auto mode needs its own model eligibility controls, separate from the normal model picker.

Proposed solution

Add a separate "Auto model pool" setting that allows each user to choose which organization-approved models Auto may select.

The proposed behavior would be:

• Show all models available under the user's plan and organization policies.
• Provide a separate Auto eligibility toggle for each model.
• Allow manually selectable models to remain excluded from Auto.
• Require at least one eligible model before Auto can be enabled.
• Continue routing automatically based on task complexity, model availability, and reliability, but only within the user's selected pool.
• Display which model Auto selected for each request.
• Clearly explain fallback behavior if every selected model is temporarily unavailable.
• Optionally allow users to set a maximum premium-request multiplier, credit threshold, or reasoning-effort level for Auto.

Organization policy should always take precedence. The user's Auto pool would be a narrower subset of the models already permitted by the organization, not a way to enable restricted models.

This would preserve the convenience and reliability benefits of Auto while giving users predictable cost, performance, and control.

Example prompts or workflows

1. Cost-conscious implementation

An organization permits several standard and premium models. A developer configures Auto to use only lower-cost and mid-tier models for routine implementation. Premium reasoning models remain available for deliberate manual selection.

2. Long-running code review

A developer starts a repository-wide review in Auto mode. Auto can escalate between the models in the developer's selected pool, but it cannot select a high-cost model that the developer intentionally excluded.

3. Task-based model pool

A developer enables a fast model for file discovery and simple edits, a balanced coding model for implementation, and one reasoning model for difficult debugging. Auto routes among those models according to the task without leaving the configured pool.

4. Temporary cost ceiling

A developer approaching a monthly usage limit removes premium models from the Auto pool while retaining access to those models in the manual picker for exceptional tasks.

5. Enterprise-controlled availability

An administrator permits Models A, B, C, and D. A user configures Auto to select only Models A and B. If the administrator later disables Model B, Auto automatically respects that policy and continues using only Model A.

Additional context

This request came from a discussion in an internal AI developer guild about unpredictable credit consumption in Auto mode.

One user reported that Auto selected a high-cost reasoning model for a lengthy review task and consumed approximately 4,000 AI credits. The group discussed disabling every model except the preferred options, but that approach would also interfere with intentional manual model selection.

The important distinction is:

• Organization policy defines which models are permitted.
• The normal model picker defines which permitted model a user can select manually.
• The proposed Auto model pool defines which permitted models Auto may select automatically.

Auto should remain intelligent. This request does not ask users to manually route every task. It asks for a user-controlled boundary within which automatic routing can operate.

A helpful UI could display two independent controls next to each permitted model:

• Available for manual selection
• Eligible for Auto mode

Showing the selected model after each Auto request would also improve transparency, troubleshooting, cost awareness, and user confidence.

L’issue ne nomme aucun fichier, test ni point d’entrée. Commencez par localiser la sélection du modèle et la gestion des politiques d’organisation de Auto mode, puis définissez le pool distinct par utilisateur, la priorité des politiques, le comportement de fallback et la visibilité du modèle sélectionné décrits ici.