Description
On vanilla OpenCode, ChatGPT-authenticated Fast model entries send service_tier: "priority", but do not show the speed increase that the same account gets in the official Codex CLI.
Tested with clean upstream checkouts, no plugins, and --pure:
v1.18.10: HTTP and Responses WebSocket
- current
dev (14f0bf64a19493110b51f5fdeb9c1c1bba5dd3f5): Responses WebSocket
gpt-5.6-sol vs gpt-5.6-sol-fast, low effort
- identical fixed prompt producing 603 output tokens
Current dev, 3 alternating runs per model (time from OpenCode step_start to step_finish):
| Model |
Median turn time |
Median output rate |
gpt-5.6-sol |
10.818s |
55.74 tok/s |
gpt-5.6-sol-fast |
10.950s |
55.07 tok/s |
The earlier clean v1.18.10 test was also flat on both transports. In contrast, official codex-cli 0.145.0 on the same account and prompt completed Standard in a median 16.30s and Fast in 11.11s across 4 alternating runs each (1.47x).
A temporary redacted probe at OpenCode's OAuth fetch boundary confirmed the current upstream request behavior:
standard: model=gpt-5.6-sol, service_tier omitted
fast: model=gpt-5.6-sol, service_tier=priority
I am not treating response.service_tier=default as proof because OpenAI has stated that field is not a reliable end-to-end Fast indicator for ChatGPT auth: openai/codex#14204 (comment). The controlled speed result and same-account Codex CLI control are the relevant signals here.
Related but not duplicate: #23267 and #16499 reported Fast feeling no different, but were closed once a Fast model appeared in the picker; runtime routing was not verified. #25059 likewise confirms the catalog design, not the serviced speed.
Could maintainers clarify the sanctioned way for third-party ChatGPT OAuth clients to request Codex Fast routing? If OpenCode needs Codex-specific metadata or another integration beyond service_tier, where should that live? I would be happy to work on a PR once the desired direction is confirmed. If proper routing is not currently available to third-party clients, not advertising Fast for this auth path may be a safer interim behavior.
Plugins
None (--pure)
OpenCode version
v1.18.10 and current dev at 14f0bf64a19493110b51f5fdeb9c1c1bba5dd3f5
Steps to reproduce
- Sign in to OpenAI using ChatGPT OAuth.
- From a clean upstream build, alternate these commands several times with the same prompt:
opencode run --pure --format json --model openai/gpt-5.6-sol --variant low "Output exactly the integers from 1 to 300 inclusive, one per line, with no commentary."
opencode run --pure --format json --model openai/gpt-5.6-sol-fast --variant low "Output exactly the integers from 1 to 300 inclusive, one per line, with no commentary."
- Compare
step_start to step_finish timestamps and verify each response has 603 output tokens.
- As a control, run the same prompt in Codex CLI with Fast off/on.
Operating System
macOS 27.0, Apple Silicon
Terminal
zsh
Description
On vanilla OpenCode, ChatGPT-authenticated Fast model entries send
service_tier: "priority", but do not show the speed increase that the same account gets in the official Codex CLI.Tested with clean upstream checkouts, no plugins, and
--pure:v1.18.10: HTTP and Responses WebSocketdev(14f0bf64a19493110b51f5fdeb9c1c1bba5dd3f5): Responses WebSocketgpt-5.6-solvsgpt-5.6-sol-fast, low effortCurrent
dev, 3 alternating runs per model (time from OpenCodestep_starttostep_finish):gpt-5.6-solgpt-5.6-sol-fastThe earlier clean
v1.18.10test was also flat on both transports. In contrast, officialcodex-cli 0.145.0on the same account and prompt completed Standard in a median 16.30s and Fast in 11.11s across 4 alternating runs each (1.47x).A temporary redacted probe at OpenCode's OAuth fetch boundary confirmed the current upstream request behavior:
I am not treating
response.service_tier=defaultas proof because OpenAI has stated that field is not a reliable end-to-end Fast indicator for ChatGPT auth: openai/codex#14204 (comment). The controlled speed result and same-account Codex CLI control are the relevant signals here.Related but not duplicate: #23267 and #16499 reported Fast feeling no different, but were closed once a Fast model appeared in the picker; runtime routing was not verified. #25059 likewise confirms the catalog design, not the serviced speed.
Could maintainers clarify the sanctioned way for third-party ChatGPT OAuth clients to request Codex Fast routing? If OpenCode needs Codex-specific metadata or another integration beyond
service_tier, where should that live? I would be happy to work on a PR once the desired direction is confirmed. If proper routing is not currently available to third-party clients, not advertising Fast for this auth path may be a safer interim behavior.Plugins
None (
--pure)OpenCode version
v1.18.10and currentdevat14f0bf64a19493110b51f5fdeb9c1c1bba5dd3f5Steps to reproduce
step_starttostep_finishtimestamps and verify each response has 603 output tokens.Operating System
macOS 27.0, Apple Silicon
Terminal
zsh