Support configured model defaults for skills
What variant of Codex are you using?
App, CLI
What feature would you like to see?
I usually keep a thread on a heavier model for normal coding and review, but some skills are a much better fit for lighter models.
Right now, if I want that split, I have to handle it manually:
- Sometimes create a new thread to keep things clean
- Switch the thread model to something lighter like gpt-5.4-mini or gpt-5.3-codex-spark
- Invoke the skill
- Switch the thread back to gpt-5.4 with high/xhigh reasoning for normal work
Sometimes I can also get the behavior I want by explicitly telling Codex to run the skill on a different model for that one turn. But that is still manual, easy to forget, and not something I want to restate every time.
Because of that friction, I also sometimes just run the skill on gpt-5.4 with high/xhigh anyway, which is not an efficient use of the heavier model.
What I want is a configuration mechanism for skill-level model defaults. I want to set it once, then have that skill automatically use the configured model when invoked, without changing the model for the whole thread.
After the skill finishes, the thread should continue on its original model.
Additional information
Any implementation is fine as long as it is persistent and automatic.
Possible shapes:
- skill metadata can declare a preferred model and reasoning effort
- config.toml can map skill name or path to a model
- some other per-skill default mechanism
The main thing is that this should be configuration, not just a one-off instruction in the prompt.
4 Comments
Skills can be invoked at any time — both explicitly and implicitly, and they can be combined in a single turn or across multiple turns in a thread. For those reasons, I don't think it makes sense to tie skills to model defaults. Those are separate concerns, and tying them together would result in poor composition.
I understand the problem you're trying to solve here, but I don't think this is the right solution.
@etraut-openai Fair point. I agree skill-level defaults are probably the wrong abstraction.
The real pain is the manual model switching around explicit skill use. I thought about subagents too, but those still live inside the same thread, so that does not seem like a clean fit either.
Is this something you guys are already thinking about? If so, I’d be curious what direction you think makes more sense.
Subagents don't live in the same thread. Each subagent gets its own thread, and you can use different models and different reasoning efforts for each subagent. So that might be a good solution for your use case. For more details, refer to this documentation.
@etraut-openai Thanks, my wording there was wrong. I know subagents get their own thread and can use different models and reasoning.
My point is that they still do not solve the workflow friction I was describing. Like skills, subagents still get invoked from within a heavier main thread I might already be working in, instead of having a persistent/default mechanism handle that routing for me.
So I agree skill-level defaults may be the wrong abstraction, but subagents do not really address the ergonomics problem I am pointing at.