codex - 💡(How to fix) Fix Support skill-scoped temporary model and reasoning effort overrides

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

Some skills produce simple or static output. For example, a help skill may only need to render a deterministic block of terminal text. Running that through the same high-effort model setting used for planning, debugging, or implementation work adds latency and cost without improving output quality.

In a local experiment with a static $cat:help response, the current inline skill path using gpt-5.3-codex at low took around 40 seconds per first response. Flattening the skill body to avoid extra loading reduced that to about 26 seconds, which helps, but the underlying issue remains: the user must choose one reasoning effort for the whole main agent, even when a skill's work is much simpler than the rest of the session.

Temporarily lowering effort for a simple/static skill would let users keep high effort for the main conversation while avoiding unnecessary cost and latency for predictable skill output.

Code Example

---
name: help
model: gpt-5.3-codex
reasoning_effort: low
# or: reasoning_effort: none
---

---

[[skills.config]]
name = "cat:help"
model = "gpt-5.3-codex"
reasoning_effort = "low"
RAW_BUFFERClick to expand / collapse

What feature would you like to see?

Please add a way for a Codex skill to temporarily override the model and/or reasoning effort used while executing that skill, without changing the model/effort for the rest of the user's main-agent interaction.

A possible shape would be skill frontmatter or skill config metadata such as:

---
name: help
model: gpt-5.3-codex
reasoning_effort: low
# or: reasoning_effort: none
---

or a config-based equivalent:

[[skills.config]]
name = "cat:help"
model = "gpt-5.3-codex"
reasoning_effort = "low"

The intended behavior is scoped and temporary:

  1. User is in a main Codex session using their preferred model/effort, for example gpt-5.5 with xhigh.
  2. User invokes a simple/static skill, for example $cat:help.
  3. Codex executes just that skill's response generation at a cheaper/faster model or effort.
  4. After the skill response is produced, the main session returns to the original model/effort automatically.

Why this matters

Some skills produce simple or static output. For example, a help skill may only need to render a deterministic block of terminal text. Running that through the same high-effort model setting used for planning, debugging, or implementation work adds latency and cost without improving output quality.

In a local experiment with a static $cat:help response, the current inline skill path using gpt-5.3-codex at low took around 40 seconds per first response. Flattening the skill body to avoid extra loading reduced that to about 26 seconds, which helps, but the underlying issue remains: the user must choose one reasoning effort for the whole main agent, even when a skill's work is much simpler than the rest of the session.

Temporarily lowering effort for a simple/static skill would let users keep high effort for the main conversation while avoiding unnecessary cost and latency for predictable skill output.

Expected behavior

Codex should allow skill authors or users to declare a skill-scoped model/effort override, and should apply it only while that skill is executing.

Important constraints:

  • The override should be opt-in per skill, not global.
  • It should not permanently mutate the main session's model or effort.
  • The user should be able to inspect or disable these overrides in config.
  • The UI/status/debug output should make the temporary override visible enough to avoid confusion.
  • If a requested skill-scoped effort is unsupported by the active model/provider/tools, Codex should fail clearly or fall back according to a documented policy.

Alternatives considered

  • Start the whole session with lower effort: not acceptable when the rest of the user's work needs higher reasoning.
  • Have the skill launch a nested codex exec with its own effort: works in principle, but adds tool/handoff overhead, complicates sandboxing, and is often slower for simple output.
  • Use subagents with different model settings: useful for delegated work, but overkill for simple/static skill rendering and not the same as temporarily changing the main skill execution context.
  • Optimize skill instructions only: helpful, but does not solve the broader mismatch between high-effort main-agent work and low-effort/static skill output.

Related issues

This is related to, but narrower than, subagent model/effort configuration requests such as #11795 and #11701. Those focus on separate agents. This request is specifically about a skill-scoped temporary override for the active main-agent interaction.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Codex should allow skill authors or users to declare a skill-scoped model/effort override, and should apply it only while that skill is executing.

Important constraints:

  • The override should be opt-in per skill, not global.
  • It should not permanently mutate the main session's model or effort.
  • The user should be able to inspect or disable these overrides in config.
  • The UI/status/debug output should make the temporary override visible enough to avoid confusion.
  • If a requested skill-scoped effort is unsupported by the active model/provider/tools, Codex should fail clearly or fall back according to a documented policy.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING