Improve subagent provider visibility

Open 💬 5 comments Opened Apr 10, 2026 by bakaburg1
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

The Codex app currently makes provider selection and subagent provider behavior hard to control and hard to understand in the UI.

I would like three related improvements:

  1. Add an easy provider picker in the Codex app UI for chat threads.
  • This should make it possible to switch a thread from one provider to another without editing TOML.
  • If switching providers invalidates or reduces the usefulness of cached thread content, that is acceptable, but the UI should warn the user clearly before the switch.
  1. Add a global way to choose a different provider for spawned agents.
  • This should be supported in config.toml.
  • Even better, it should also be exposed in the Codex app settings UI.
  • This is useful because it often makes sense to keep the main thread on one provider while sending subagents to a cheaper provider or a local model.
  1. Fix the Codex app UI so subagents show the correct effective provider/model.
  • Right now the subagent UI can show the provider/model of the calling agent even when the subagent is actually running on a different provider.
  • This makes provider debugging much harder and creates false confidence about what is being used.

Why this matters

Provider/model routing is now a real workflow concern:

  • main agent on one provider
  • subagents on a cheaper provider
  • local models for some tasks
  • remote frontier models only where needed

The app should support this explicitly instead of requiring low-level config work and log inspection.

Concrete example

I configured subagents to use Azure with gpt-5.4-mini while keeping the main agent on OpenAI.

The authoritative child session metadata recorded:

  • model_provider = "azure"
  • model = "gpt-5.4-mini"

But the spawned subagents self-reported and appeared in the UI as OpenAI / GPT-5.

That indicates the effective runtime configuration and the displayed provider/model are diverging.

Suggested behavior

  • Thread-level provider picker in the app UI.
  • Global default provider/model for subagents in config, plus an app settings surface for the same.
  • Subagent UI should display the effective resolved provider/model of the spawned session, not inherit the parent thread display.
  • If provider switching affects cache reuse or thread continuity, show an explicit warning before applying the change.

Additional information

This is partly a feature request and partly a correctness/UI bug:

  • feature request: easier provider selection in app/settings
  • correctness bug: subagent provider/model display does not match actual spawned-session metadata

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #16548
  • #16371
  • #16893
  • #16984

Powered by Codex Action

etraut-openai contributor · 4 months ago

Provider selection is already covered in #10867, which has some upvotes.

I'm going to change the title of this to focus on subagents to avoid overlap.

iraabbott · 1 month ago

This feature will really help me 'read the road' as my 'Spec Before Code' discipline executes on plan. When this (hopefully) lands, I will likely tweak to get feedback for max capability needed (somehow - I'll make it up and try till it flies) so that each wave can 'right size'. 'Wake up Muttley you're dreaming again ...'.

If anyone is interested - my process for keeping large projects 'semantically tight' is documented here, with the last of six instalments quantitative data on document organization and retrieval mechanisms for the history built up. Like everything, it is a work in process, but could provide some feedback on a customer pattern emerging. As a curious item, Opus 5 now spontaneously uses the Claude Code decision picker from the planning phase for the open decisions (PCDN) in this process via agent instructions.

This would be even more cool in the Code App UI, which I really like, BTW.

Link to 'Spec Before Code' article series:
https://www.linkedin.com/pulse/spec-before-code-what-standards-bodies-knew-ira-abbott-3p9le

Drazeelin · 16 days ago

I would like to request a better model/provider switching experience in Codex.

My ideal workflow:

  • Keep using ChatGPT subscription authentication for official OpenAI models (for example GPT-5.6 Sol).
  • Also configure third-party providers such as DeepSeek through API keys.
  • While Codex is already open, switch between them directly from the model picker with one click.

Example:

Model selector:

  • GPT-5.6 Sol (ChatGPT subscription)
  • DeepSeek V4 Flash (DeepSeek API)

Currently, switching between these workflows requires changing provider configuration, authentication mode, or restarting Codex. This breaks the smooth agent workflow.

A coding agent should allow users to choose the best model for each task:

  • Use the subscription GPT model for complex reasoning and large refactors.
  • Use lower-cost third-party models for quick edits, exploration, or routine tasks.

The UI should handle provider switching explicitly, including authentication differences, instead of requiring users to manually edit config files.

This would make Codex much more flexible for real-world multi-model workflows.

yitianlian · 15 days ago

I also want this feature