Skip to content

fix: map service_tier fast to priority for Codex backend#282

Open
icebear0828 wants to merge 1 commit intomasterfrom
fix/service-tier-priority-mapping
Open

fix: map service_tier fast to priority for Codex backend#282
icebear0828 wants to merge 1 commit intomasterfrom
fix/service-tier-priority-mapping

Conversation

@icebear0828
Copy link
Copy Markdown
Owner

Summary

  • -fast / -flex suffixes were completely non-functional since cc1b29d stripped service_tier from both HTTP body and WS request as a workaround for backend rejecting "fast"
  • Root cause: Codex backend expects "priority" not "fast" — confirmed by reading codex-rs source (client.rs:739-741: ServiceTier::Fast => "priority")
  • Now both HTTP and WebSocket paths map fast → "priority" and preserve the field in the request body, matching Desktop behavior

Test plan

  • Unit tests: fast→priority mapping, flex passthrough, null omission (HTTP + WS paths)
  • Full test suite: 1224 passed
  • Real upstream: gpt-5.4-fast returns 200 (previously would have returned "Unsupported service_tier: fast" without the cc1b29d strip)

The Codex backend rejects `service_tier: "fast"` in the request body
("Unsupported service_tier: fast"). The Desktop app (codex-rs) maps
`Fast` to `"priority"` before sending — align proxy behavior to match.

Previously cc1b29d stripped service_tier entirely as a workaround,
making -fast/-flex suffixes non-functional. Now the field is preserved
in both HTTP and WebSocket paths with the correct mapping.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant