Skip to content

[Windows Desktop] Slow gpt-6.1-sol medium responses: bounded latency diagnostics without confirmed 429 #54022

Open

Description

@WonSang98

Summary

The Windows desktop user reports unusually slow response generation and asks OpenAI to investigate model/backend latency versus desktop overhead. This is a diagnostic report, not a confirmed inference-speed regression. Please correlate backend timing and desktop streaming telemetry.

Environment

  • Observation: October 15, 2026, approximately 00:50–01:04 KST (October 14, 15:50–16:04 UTC).
  • Windows 11 Home, version 10.0.26200, 8 logical processors, about 31.5 GiB RAM.
  • Installed Windows package path reports OpenAI.Codex 26.1007.9446.0; desktop/app-server logs report client version 26.1007.71326. These are separate observed version fields.
  • Bundled runtime: codex-cli 0.162.0-alpha.17.2.
  • Current conversation model: gpt-6.1-sol, reasoning effort medium. Subscription tier and service tier are not established.

Bounded observations

Seven consecutive within-turn generation intervals were reconstructed from session timestamps, excluding tool execution. Durations / output-token counts:

  • 5.537 s / 105 tokens
  • 4.593 s / 87 tokens
  • 5.078 s / 120 tokens
  • 4.252 s / 45 tokens
  • 6.253 s / 116 tokens
  • 5.684 s / 157 tokens
  • 7.936 s / 264 tokens

Aggregate: 894 tokens / 39.333 s = about 22.7 tokens/s. Individual estimates: 10.6–33.3 tokens/s.
These are request-level estimates that include unseparated request setup, prefill, first-token waiting, reasoning and generation. They are NOT direct streaming decode TPS. Output includes agent/tool-call output, not just user-visible prose. User idle time between turns is excluded.

Per-request input grew from 47,786 to 64,175 tokens in this bounded sample; cached input ranged from 37,504 to 63,744. Later diagnostic calls reached approximately 89k input tokens. The initial request reported 37,706 input tokens and zero cached tokens. The project contributes lengthy instructions, and diagnostic tool output subsequently enlarged the context; this is a confounder, not proof of cause.

Current-thread runtime logs showed no explicit Too Many Requests, status-429, retrying, timeout, disconnect or stream-error signatures in the inspected bounded rows. A trace recorded: "incremental request failed, websocket reuse properties didn't match"; no causal connection to the delay is established.

Local checks

  • codex doctor: desktop app-server initialized; WebSocket connection HTTP 101 successful; active provider endpoints reachable; databases healthy; no failed checks.
  • Doctor also reported missing/unusable rollout references and files absent from the state DB; 79 active rollout files totaling about 2.01 GB. No causal link to active generation established.
  • A 3.012-second CPU sample across ChatGPT/Codex processes used about 20.2% of one logical CPU, equivalent to about 2.5% of this 8-thread machine. This short sample does not rule out transient UI stalls.
  • Aggregate process working sets approximately 5.41 GiB (may count shared pages); available physical RAM approximately 9.2 GiB.
  • OpenAI public status page reported fully operational at inspection time; aggregate status does not establish account/model-specific health.
  • Repeated unknown-feature warnings for code_mode_tool_description_first were present; their latency impact is unknown.

Expected behavior / investigation requested

Please distinguish and expose:

  1. Backend queue time, prefill/cache reuse, time to first token and decode throughput for gpt-6.1-sol medium.
  2. Desktop stream delivery, buffering and rendering delay versus server-side generation.
  3. Whether the websocket reuse mismatch forces avoidable setup/prefill.
  4. Whether long instruction/tool context or local rollout-index inconsistencies contribute.
  5. Whether this overlaps the recent performance reports.

No controlled same-prompt model A/B, clean-context benchmark, backend request timing or renderer frame capture was available; the root cause remains unconfirmed. No setting, authentication, history, security policy or model was changed.

Related: #54004 (broader Windows/model slowdown with reported HTTP 429; this inspected session had no confirmed 429).
Official reporting guidance: https://learn.chatgpt.com/docs/reference/troubleshooting

Privacy: only sanitized versions, aggregate counts and timings are included. No private paths, project source, prompts, conversation/request identifiers, credentials, raw transcripts or logs are attached.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Oct 14, 2026
  2. github-actions commented on Oct 14, 2026

    @github-actions
    Contributor
  3. iAchilles commented on Oct 14, 2026

    @iAchilles

    Even at 1.5× speed, Codex is too slow for me to work productively. A simple linter error fix took 16 minutes. That's just not usable in a real development workflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions