Repository navigation
The call speed is super slow, but calling the GPT model directly without OpenCodex is very fast #338
Description
Client or integration
Codex App
Area
Proxy and routing
Summary
响应速度极慢，即使调用成功 tok/s也不超过5.
Reproduction
正常启动ocx，配置了chatgpt账号和grok账号，gemini账号，账号均有额度使用状态正常。 但就是响应时长非常非常慢！
Version
v2.7.36
Operating system
mac
Provider and model
No response
Logs or error output
Screenshots and supporting files
No response
Redacted configuration
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
[-]调用速度超级慢，但不用opencodex，直接调用gpt自身模型就很快[/-][+]The call speed is super slow, but calling the GPT model directly without OpenCodex is very fast[/+]github-actions commentedon Jul 23, 2026
English translation (original: zh)
Client or integration
Codex App
Area
Proxy and routing
Summary
Reproduction
Normal startup of ocx, configured with ChatGPT account, Grok account, and Gemini account, all accounts have normal usage limits. But the response time is very, very slow!
Version
v2.7.36
Operating system
mac
Provider and model
No response
Logs or error output
Screenshots and supporting files
No response
Redacted configuration
Checks
chessmiller commentedon Jul 23, 2026
lidge-jun commentedon Jul 23, 2026
Status update after a full source-level diagnosis of the v2.7.35 → v2.7.36 delta:
What we verified
devvia PR fix(responses): reconstruct dropped SSE output items + dedupe replayed multi-agent guidance (#334, #326) #350: (1)response.output_item.doneitems were dropped when the terminalresponse.completedpayload had an emptyoutput, so continuation state lost assistant/tool_call items and the model repeated tools ([Bug][死循环]: Codex Desktop tool-call dead loop — OpenAI passthrough drops assistant/tool_call from previous_response_id replay #334); (2) the multi-agent guidance message was duplicated +1 per tool continuation, inflating prompt tokens every turn (Tool-heavy Codex App sessions can enter an unbounded continuation loop with WebSocket forwarding #326). Both defects predate v2.7.36 (reproduced on v2.7.34) but compound exactly into the symptoms here: 90–200s turns, client-abort 499 rows, and timeout 504 rows.tok/scolumn is end-to-end (output tokens ÷ total request duration, including time-to-first-token and any upstream stall) — a long initial stall reads as "<5 tok/s" even when byte cadence after first output is normal.Current state
latesthas been reverted to v2.7.35 while the fixes bake, sonpm i -ginstalls a known-good build today.devand will ship in the next release.Please retest after the next release (or on
devif convenient). If slow token cadence persists after first output with the fixes applied, that would point to a separate cause and we will reopen the trace with TTFT/chunk-timestamp instrumentation. Keeping this issue open until the fixed release is confirmed.lidge-jun commentedon Jul 24, 2026
Thanks for the report. As filed this isn't reproducible on our side — there are no logs, provider/model, or config attached, and
tok/s < 5can come from many places (the routed provider itself, a slow web-search/vision sidecar turn, or network), not necessarily the proxy.Since v2.7.36 (your version),
devlanded substantial streaming/throughput work that directly affects perceived speed: pull-driven backpressure for routed SSE streams, bounded runTurn event backlog with a fixed fetch-to-reader abort race, and treating upstream keepalives as adapter activity. Separately, we just bounded the web-search sidecar deadline (200s → 60s) in #416, which was a common cause of a whole turn stalling.Closing as not-reproducible for now — please update to the latest release, retry, and if it's still slow, reopen with: the OpenCodex dashboard per-request timing for a slow turn, the provider + model, tok/s vs calling that provider directly, and whether web-search or the vision sidecar was active on that turn. That'll let us attribute the latency precisely.