Fast mode / priority service tier is requested, but responses complete with service_tier=default

### What happened?

I have Fast mode enabled for Codex, and local logs show that Codex is sending service_tier: "priority" in the outgoing response.create request.

However, the final response.completed event consistently returns:

"service_tier": "default"

So the client appears to request the Fast/Priority tier correctly, but the backend completes the response on the default tier without any warning or visible downgrade reason.

Environment

• Codex surface: Codex Desktop / local Codex session
• Auth mode: ChatGPT sign-in, not API key
• GitHub issue author: LYY435939
• Codex version shown in local state: 0.142.0-alpha.6
• OS: Windows
• Model: gpt-5.5
• Reasoning effort: xhigh
• Fast / service tier config:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"
service_tier = "priority"

The local model cache also advertises Fast support for gpt-5.5:

"service_tiers": [
  {
    "id": "priority",
    "name": "Fast",
    "description": "1.5x speed, increased usage"
  }
],
"additional_speed_tiers": ["fast"]

Steps to reproduce

1. Sign in to Codex with a ChatGPT account that has Fast mode available.
2. Use a supported model such as gpt-5.5.
3. Enable Fast mode / priority service tier.
4. Start a normal Codex turn.
5. Inspect local Codex SQLite logs or websocket traces.

Actual behavior

Outgoing response.create contains service_tier=priority.

Example sanitized local log summary:

OUT_CREATE thread=... model=gpt-5.5 tier=priority effort=xhigh
OUT_CREATE thread=... model=gpt-5.5 tier=priority effort=xhigh
OUT_CREATE thread=... model=gpt-5.5 tier=priority effort=xhigh

But the corresponding completed responses return default:

response.completed resp_... model=gpt-5.5 service_tier=default status=completed
response.completed resp_... model=gpt-5.5 service_tier=default status=completed

I also observed the same final default tier on some gpt-5.4 completed responses.

Expected behavior

If Fast mode / priority tier is accepted and used, response.completed.response.service_tier should indicate the actual Fast/Priority tier.

If the request is downgraded to default because of entitlement, capacity, quota, rollout state, or any other backend reason, Codex should surface a clear warning or diagnostic message instead of silently showing/allowing Fast mode while the completed response runs on default.

Why this seems like a bug

The client-side request serialization appears to be correct: service_tier=priority is present in the outgoing request.

The issue appears to be that the service completes the response with service_tier=default without making the downgrade visible to the user.

Codex documentation says Fast mode supports GPT-5.5 and GPT-5.4:
https://developers.openai.com/codex/speed

Related issues

Possibly related:

• #14204
• #24661
• #20856
• #26391

This report is slightly different from client-side preference reset issues because the local outgoing request already contains service_tier=priority; the unexpected part is the final completed response returning default.

Additional context

No full prompt, account identifiers, or sensitive payloads are included here. The log excerpts above are sanitized summaries of local Codex SQLite/websocket events.