[Bug] Multi-Agent V2 child gets service_tier=priority after parent switches to default, even when spawn_agent omits the field

What version of Codex is running?

• Codex Desktop: 26.803.10989.0
• Embedded Codex runtime recorded in the child rollout: 0.147.0-alpha.6.6

What subscription do you have?

ChatGPT Pro (20x)

Which model were you using?

gpt-5.6-sol, reasoning effort ultra, Multi-Agent V2

What platform is your computer?

Microsoft Windows 11 Home, version 10.0.26200, x64

What issue are you seeing?

A parent thread had previously used Fast, then was switched back to Standard. Its effective thread setting and global config both recorded service_tier = "default".

More than two hours after the parent applied default, it spawned a child. The actual spawn_agent function call omitted service_tier entirely; its argument keys were exactly:

task_name,fork_turns,message

Despite that, the newly created child received service_tier: "priority" immediately before task_started. In the model catalog and UI, priority maps to Fast.

This is materially different from reports where the model-generated spawn_agent call explicitly contains service_tier: "priority". Here, the field was absent from the call, yet the Desktop/Multi-Agent V2 child initialization still applied Fast.

Sanitized rollout evidence

Global config at the time:

model = "gpt-5.6-sol"
model_reasoning_effort = "ultra"
service_tier = "default"
multi_agent = true

The latest parent thread_settings_applied event before the affected spawn:

{
  "timestamp": "2026-08-12T15:33:54.725Z",
  "model": "gpt-5.6-sol",
  "service_tier": "default",
  "reasoning_effort": "ultra"
}

The parent spawn call approximately two hours later:

{
  "timestamp": "2026-08-12T17:38:57.519Z",
  "name": "spawn_agent",
  "arguments": {
    "task_name": "<redacted>",
    "fork_turns": "3",
    "message": "<redacted>"
  }
}

The new child session metadata:

{
  "timestamp": "2026-08-12T17:39:02.510Z",
  "originator": "Codex Desktop",
  "cli_version": "0.147.0-alpha.6.6",
  "multi_agent_version": "v2"
}

The child's effective settings, followed by task start:

{
  "timestamp": "2026-08-12T17:39:02.549Z",
  "type": "thread_settings_applied",
  "thread_settings": {
    "model": "gpt-5.6-sol",
    "service_tier": "priority",
    "reasoning_effort": "ultra"
  }
}
{
  "timestamp": "2026-08-12T17:39:02.577Z",
  "type": "task_started"
}

The relevant local rollout records are parent lines 77913 and 80467, and child lines 814–815. Project path, task text, and thread IDs are redacted from this public report.

Steps that reproduce the observed state

1. Configure service_tier = "default".
2. In a long-running Desktop parent thread, use Fast and then switch the parent back to Standard.
3. Verify the parent emits thread_settings_applied with service_tier: "default".
4. Spawn a bounded Multi-Agent V2 child without passing a service_tier field.
5. Inspect the child rollout before its first turn.
6. Observe thread_settings_applied with service_tier: "priority" immediately before task_started.

The behavior may depend on a parent thread that previously used Fast, so a fresh Standard-only thread may not reproduce it.

What is the expected behavior?

When spawn_agent omits service_tier, a new child should inherit the parent's current effective tier. After the parent switches to default, every subsequently spawned child should start with default.

A stale historical Fast setting should never override the current parent setting, and a quota-affecting tier change should be visible before child inference begins.

Why this is severe

Official OpenAI documentation says GPT-5.6 Fast consumes credits at 2.5x the Standard rate:

https://learn.chatgpt.com/docs/agent-configuration/speed

During the incident, the account UI showed a 47-percentage-point weekly usage drop over roughly two hours of multi-agent work. Exact attribution requires backend telemetry, but the rollout proves that affected children were sent through priority despite the parent being Standard and the spawn calls omitting the tier field.

Related issues and key distinction

• #29940 — subagents sometimes spawned with service_tier=priority
• #30407 — Codex App subagents use Fast despite Standard and fast opt-out
• #30756 — model-generated spawn call may silently include service_tier=priority

The suggested workaround in #30756 is to omit the service_tier field so the child inherits Standard. That workaround was already in effect in this trace: the field was absent, yet the child still started with priority.

Possible areas to inspect are stale per-thread service-tier state, Desktop child-thread initialization, config snapshots used by Multi-Agent V2, and the app-server settings applied between child creation and task_started.