Feature request: Pre-turn routing hook for plugins to select model and reasoning effort

Open 💬 0 comments Opened Aug 25, 2026 by KokoMango85

What variant of Codex are you using?

Codex App for Windows 26.818.8289.0 (x64), using the plugin and UserPromptSubmit hook system

What feature would you like to see?

Summary

Please add an opt-in pre-turn routing hook that allows a Codex plugin to select the model and reasoning effort after the user submits a prompt, but before Codex creates the turn context or sends the first model request.

The essential requirement is that the selected configuration applies to the same user task. No additional routing turn, model call, thread, or handoff should be required.

A possible name would be BeforeTurn, PreTurnSettings, or TurnSettingsResolver.

Motivation

Users currently have to select one model and reasoning level manually before knowing how difficult a task will be.

Real Codex usage varies substantially:

  • Small edits, searches, summaries, and documentation checks may only require a faster model and low reasoning.
  • Debugging, architecture, migrations, and ambiguous failures may require a stronger model and higher reasoning.
  • Long tasks may benefit from carefully bounded subagents, while simple tasks should avoid agent overhead entirely.

A local optimizer plugin could learn from observed project history and select an efficient configuration automatically. However, the current hook system cannot apply model or reasoning changes to the same turn.

Proposed contract

The hook could receive:

  • User prompt or input metadata
  • Project working directory
  • Current model and reasoning effort
  • Models and reasoning levels available to the user
  • User-defined minimum and maximum limits
  • Project and plugin configuration

The hook could return:

  • Optional model override
  • Optional reasoning-effort override
  • Optional service-tier preference
  • A short user-visible reason
  • Confidence or evidence metadata
  • A bypass decision that keeps the user's current settings

Optional future fields could include selected skill references, default subagent configuration, and agent/tool budgets.

The Codex host should validate the result and apply it before constructing the first and only turn.

The routing policy should be allowed to run deterministically and locally, without invoking another model.

User control and safety

  • Disabled by default and explicitly enabled by the user
  • Manual model selection remains authoritative
  • User-configurable model and reasoning boundaries
  • Strict execution timeout for the hook
  • Safe fallback when a model is unavailable or the hook fails
  • Visible record of requested and applied settings
  • No additional transmission of prompt data beyond the normal Codex request
  • Exactly one Codex task for one submitted user task

Benefits

This extension point could enable:

  • Automatic model and reasoning selection
  • Token- and latency-aware plugins
  • Organization-level routing policies
  • Better use of smaller or faster models for simple work
  • Avoidance of unnecessary high-reasoning compute
  • Fewer duplicate turns and repeated context
  • Transparent, user-controlled optimization
  • A supported alternative to custom clients and brittle handoff workarounds

This could benefit users through lower latency and more appropriate resource usage, while potentially benefiting OpenAI by avoiding unnecessary model calls, repeated context processing, and high-effort execution when a task does not require it.

Additional information

Current limitation and observed workaround

The current UserPromptSubmit hook can add context or block a request, but it does not expose a supported way to change the model or reasoning effort for that same turn.

While prototyping a local optimizer plugin, the only available workaround was:

  1. Start a routing turn.
  2. Analyze the request.
  3. Hand the request to another turn.
  4. Execute with the recommended configuration.

This defeats the optimization objective because it creates additional task and context overhead.

Controlled local observation

Comparable local work was tested using direct execution and the routing workaround.

Direct execution

  • Recorded tasks: 1
  • Model: gpt-5.5
  • Local observed token activity: 205,710
  • Duration: 93.3 seconds

Two-turn plugin workaround

  • Recorded tasks: 2
  • Model: gpt-5.5 on both recorded tasks
  • Local observed token activity: 566,827
  • Duration: 185.2 seconds
  • Recommended model change was not applied to the original turn

Difference

  • +361,117 observed tokens
  • +175.55% observed token activity
  • +91.9 seconds / +98.5% duration

These local counters include cached context and are not presented as API billing or proof of universal cost savings. The experiment only demonstrates that a second routing turn introduces substantial overhead and is not a viable implementation.

A correct implementation should also allow the optimizer to bypass routing whenever predicted savings do not exceed routing overhead.

Acceptance criteria

  • One submitted user task creates exactly one Codex task
  • The selected model and effort apply to the first model request
  • No additional LLM call is required for routing
  • Unsupported decisions are rejected or safely replaced
  • Manual user choices and configured limits are respected
  • Requested and applied settings are observable
  • Hook failure does not prevent normal Codex execution
  • Tests cover valid overrides, invalid overrides, fallback, timeout, and manual override precedence

Related requests

  • #8649 requests built-in automatic reasoning tier selection.
  • #20855 requests model-callable reasoning adjustment for subsequent turns.
  • #22908 requested skill-scoped model and effort overrides and was closed as not planned.

This request is different: it proposes a general host-level extension point for trusted, opt-in plugins to select the initial model and reasoning effort before the same turn begins.

Codex App Server already supports per-turn model and effort fields through turn/start. This request asks for a safe equivalent in the official plugin and hook experience.

I would be happy to test an experimental implementation, provide additional measurements, or contribute a focused proof of concept if the design direction is accepted.

View original on GitHub ↗