Feature request: allow skills or user commands to declare the model used for their invocation

Open 💬 0 comments Opened Jul 14, 2026 by quarrel

What variant of Codex are you using?

all

What feature would you like to see?

Feature request: allow skills or user commands to declare the model used for their invocation

What feature would you like to see?

Allow a user-defined skill or command to specify a model and reasoning effort that Codex applies before invoking the model.

For example:

name = "commit"
description = "Inspect and commit the current coherent repository changes."
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
restore_previous_model = true

Invoking /commit while the active session model is gpt-5.6-sol would then:

  1. resolve the command or skill locally in the harness;
  2. invoke Luna directly with the skill and relevant session/repository context;
  3. add the resulting interaction to the current session;
  4. leave Sol as the active model for the next ordinary user turn.

The important requirement is that Sol should not first receive the request and spawn Luna as a subagent. The model override should happen in the harness before the model invocation.

Why this matters

Different parts of an interactive coding workflow need very different model capabilities.

A high-capability model may be appropriate for architecture, difficult debugging and integration, while a faster model is sufficient for tasks such as:

  • inspecting a completed diff and writing a commit message;
  • running and summarising tests;
  • linting or formatting;
  • updating generated documentation;
  • applying a tightly specified mechanical transformation.

The current options all have significant friction:

  • manually switch models before and after each small task;
  • keep separate Codex sessions;
  • invoke a separate codex exec process;
  • ask the expensive active model to spawn a cheaper subagent.

The subagent workaround is inefficient for small tasks because the active model must first process the request, construct the delegation and later consume the result. It also duplicates context and turns a simple operation into multi-agent orchestration.

A model-bound skill would provide deterministic user-controlled routing without requiring automatic model classification.

Possible configuration

The model selection could live in skill metadata or another command-specific configuration surface:

model = "gpt-5.6-luna"
model_reasoning_effort = "low"
restore_previous_model = true

Possible defaults:

  • inherit the active model when model is absent;
  • restore the previous active model after a one-shot invocation;
  • inherit the current sandbox and approval policy unless explicitly overridden;
  • display the selected model before execution;
  • reject unavailable models with a clear error rather than silently falling back.
Example workflow

The main session is running under Sol:

> Implement the agreed cache invalidation design.

After reviewing the completed change:

> /commit

Codex invokes /commit using Luna directly to inspect the diff and create the commit. The following ordinary user message again runs under Sol without requiring another /model selection.

Relationship to subagents

This is not intended to replace subagents.

Subagents remain useful for parallel exploration, isolated review and substantial delegated work. This feature addresses small, named workflow operations where invoking a parent model merely to delegate the task adds more overhead than value.

Relationship to automatic routing

This request does not require Codex to infer which model should handle arbitrary prompts. The user explicitly chooses the model as part of the skill or command definition, making the behaviour deterministic, inspectable and reproducible.

Additional information

_No response_

View original on GitHub ↗