The call speed is super slow, but calling the GPT model directly without OpenCodex is very fast

[chessmiller]

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.

[github-actions]

English translation (original: zh)

Client or integration

Codex App

Area

Proxy and routing

Summary

The response speed is extremely slow, even with successful calls, the tokens per second do not exceed 5.

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

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[chessmiller]

这是我使用ocx restore命令后，在codex调用5.6 的速度

[lidge-jun]

Status update after a full source-level diagnosis of the v2.7.35 → v2.7.36 delta:

What we verified

• The hot streaming path (relay, request handling, SSE heartbeat) is effectively unchanged between v2.7.35 and v2.7.36 — the large file restructure moved code but introduced no buffering or blocking on the stream path. No revert of v2.7.36 commits is warranted on current evidence.
• The dominant proxied-session slowness has a confirmed root cause pair, now fixed on dev via PR fix(responses): reconstruct dropped SSE output items + dedupe replayed multi-agent guidance (#334, #326) #350: (1) response.output_item.done items were dropped when the terminal response.completed payload had an empty output, 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.
• One measurement note: the Logs tok/s column 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

• npm latest has been reverted to v2.7.35 while the fixes bake, so npm i -g installs a known-good build today.
• The state-loss and token-inflation fixes are merged on dev and will ship in the next release.

Please retest after the next release (or on dev if 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]

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 < 5 can 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), dev landed 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.