🚨 Found why Codex quota still drains so fast #30756

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.70822

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex App appears to consume Fast / Priority usage even when I did not explicitly request Fast mode.

I found that when Codex spawns subagents, the generated tool call can include:

"model": "gpt-5.5",
"reasoning_effort": "xhigh",
"fork_context": false,
"service_tier": "priority"

The user request only required a specific model/reasoning setting. It did not request Fast, Priority, or any speed tier.

This is confusing because the spawn_agent schema says service_tier should be omitted unless explicitly requested, but the model can still include service_tier: "priority". In local model metadata, priority is displayed as Fast, so this appears to be the cause of unexpected Fast usage consumption.

Root cause clarification: this is not just a prompt-following issue. The thread's main agent can effectively opt subagent creation into service_tier=priority even when the user never asked for Fast/Priority. Fast/Priority is a user setting and quota-affecting mode, so the main agent should not have permission to silently change it through a generated tool call. This looks like a Harness boundary/design issue: the Harness should enforce the user's selected tier policy, instead of trusting the model-generated service_tier field.

The issue still exists.

What steps can reproduce the bug?

1. Open Codex App.
2. Ask Codex to spawn subagents with explicit model/reasoning requirements, for example:

   Spawn several subagents. Use model gpt-5.5, reasoning_effort xhigh, and fork_context=false.
   Do not use a lower model.
   

3. Do not mention Fast, Priority, speed tier, or service_tier.
4. Inspect the actual subagent tool calls or session logs.
5. Observe that the subagent calls may include:

   "service_tier": "priority"

6. Because priority maps to Fast, Fast/Priority usage is consumed even though the user never requested it.

What is the expected behavior?

Codex should not set service_tier unless the user explicitly requests Fast / Priority / a speed tier.

If the user only specifies:

"model": "gpt-5.5",
"reasoning_effort": "xhigh",
"fork_context": false

then the subagent tool call should omit service_tier entirely.

Expected call:

{
  "agent_type": "explorer",
  "model": "gpt-5.5",
  "reasoning_effort": "xhigh",
  "fork_context": false,
  "message": "..."
}

Not:

{
  "agent_type": "explorer",
  "model": "gpt-5.5",
  "reasoning_effort": "xhigh",
  "fork_context": false,
  "service_tier": "priority",
  "message": "..."
}

More strictly, the Harness should reject or ignore service_tier=priority when it was not explicitly requested by the user or confirmed through UI/settings. A model-generated tool call should not be able to override a quota-affecting user setting.

Additional information

This is especially problematic for users who use many subagents. A single orchestration can silently consume substantial Fast/Priority quota if every subagent receives service_tier=priority.

The UI/model metadata appears to map:

{
  "id": "priority",
  "name": "Fast"
}

So service_tier=priority is effectively Fast mode.

Suggested fix: make service_tier opt-in only, enforce the tool schema guidance at the Harness/tool boundary, and ideally show a warning or confirmation before any generated tool call uses Fast/Priority when the user did not explicitly request it. The important invariant is that Fast/Priority should remain controlled by explicit user intent or settings, not by the main agent's generated subagent call.