Repository navigation
Repeated full-history requests can generate hundreds of GB of redundant client upload per month #45971
Description
What happened
A long-running, image-heavy Codex session lost the incremental Responses WebSocket path and began
submitting its full active history over HTTP. Local transport instrumentation measured serialized
request bodies of approximately 22.4–22.6 MiB. Normal model/tool loops could submit that body
multiple times per minute.
Independent UniFi application traffic totals attributed the following traffic to ChatGPT, almost
entirely from the affected workstation:
| Window | Total traffic | Upload | Download |
|---|---|---|---|
| 24 hours | 69.0 GB | 65.9 GB | 3.12 GB |
| 7 days | 309 GB | 292 GB | 17.2 GB |
| Rolling 30 days | 427 GB | 386 GB | 40.9 GB |
The workstation accounted for 99.8% of the ChatGPT-classified traffic in the 30-day view. One
five-minute bucket contained approximately 878 MB of traffic.
During one clearly correlated 35-minute active interval, the router recorded 1.50 GiB total / 1.41
GiB upload—roughly the volume of sixty full 22.6 MiB submissions. In the 45 minutes after the
mitigation below was applied, traffic fell to 27.1 MiB total / 14.0 MiB upload, while work in the
session continued.
The attached 24-hour router graph shows the pattern clearly: sustained work, an idle night, a short
return to work using the old request path, and the drop immediately after the mitigation was
applied.
Why this may matter to OpenAI
The connection is unlimited, so this did not create a meaningful bandwidth cost for the user. It
also did not materially concern the ISP. The unusually large recipient-side cost is easy to miss:
OpenAI still receives and handles every repeated full-history body.
I cannot estimate OpenAI's internal bandwidth pricing, and raw cloud ingress may be free or
discounted. But TLS termination, routing, buffering, deserialization, request processing, and
operational capacity are not made free by the user's unlimited connection. If the observed 65.9
GB/day rate were sustained, it would be approximately 2 TB/month from one workstation.
This is therefore not only a latency or metered-connection problem. It is silent provider-side
resource amplification at fleet scale.
Mitigation that worked
The successful mitigation was:
- Compact the active history with caller-authored guidance.
- Omit inline image bodies from the installed compacted working history, while leaving the
source transcript unchanged and recoverable. - Only after that successful size reduction, allow one explicit attempt to establish a fresh
Responses WebSocket continuation. - If that attempt fails, return to sticky HTTP fallback rather than automatically retrying the
same oversized full body.
The first full request on the fresh WebSocket was approximately 275 KiB instead of 22.6 MiB—an
approximately 84x reduction. Following turns used incremental request items.
The important properties appear to be:
- account for retained media in serialized request bytes, not only model tokens;
- avoid retrying a deterministic oversized full request several times;
- prevent HTTP fallback from turning every model/tool loop into another full-history upload;
- allow a successfully reduced context to re-enter the incremental path without restarting the
thread; - keep the original transcript available for inspection and restoration.
Reproduction shape
- Use a long-running Codex thread containing multiple screenshots or image-returning tool calls.
- Accumulate enough inline media in active or compacted history to make a full serialized request
tens of megabytes even though token accounting remains below the compaction threshold. - Lose incremental WebSocket reuse and enter HTTP fallback.
- Continue through several model/tool loops.
- Observe repeated multi-megabyte full-history submissions and rapidly growing client upload.
The exact trigger for losing WebSocket reuse may vary. The expensive behavior is what happens after
the client no longer has a valid incremental continuation.
Expected behavior
- Normal model/tool continuations should not repeatedly upload the complete accumulated history.
- Inline media bytes should participate in compaction and request-size thresholds.
- The client should avoid multiple retries of the same deterministic oversized request.
- Fallback should remain stable until the context has materially changed or been reduced.
- Codex should expose serialized request size, inline-media bytes, full-versus-incremental mode,
transport fallback, and cumulative bytes resent. - A configurable request/rolling-session byte guardrail would keep one thread from silently
generating hundreds of gigabytes of upload.
Environment
- Linux x86_64.
- ChatGPT Pro subscription.
gpt-5.6-sol.- Custom Codex fork based on
rust-v0.154.0-alpha.4. - The fork added request-size/transport-state observability and the mitigation described above.
The upstream mechanism has independent reports in #45109, #24550, #43015, and #38014. This datapoint
adds the router-scale aggregate, a continued-work before/after comparison, and a mitigation that
restored small incremental requests.
The raw rollout is not attached because it contains prompts, tool output, local paths, and image
payloads. No session IDs, authentication data, or private content are included here.
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
keitacai commentedon Sep 23, 2026
Additional macOS Desktop reproduction on September 23, 2026 (18:00 Asia/Shanghai). I inspected the local session structure and process network counters without publishing prompts, image contents, project paths, thread IDs, or raw logs.
Environment:
codex-cli 0.155.0-alpha.9.2.Observed:
custom_tool_call_output, totaling approximately 50.21 MB of Base64 text. The images were viewed/generated during earlier work.nettopattributed sustained outgoing traffic to the desktop'scodexprocess: roughly 2 MB/s for most of an 18-second sample. A subsequent one-second sample showed 40,506,308 outgoing bytes attributed to that process, including 38,601,425 bytes on its connection to the local proxy (127.0.0.1:7897). The proxy path means these are process-to-proxy bytes, not a direct measurement of WAN payload bytes.This is consistent with the issue's repeated large-context transport failure mode: retained historical inline images appear to drive large uploads on subsequent model steps even when those steps only inspect code. The high cached-token count does not establish that the client avoided transmitting the context. I did not capture or decrypt the request body, so I cannot prove the exact bytes in the 40-MB burst or identify whether that specific request used HTTP fallback versus WebSocket.
Please bound serialized media bytes in active history, avoid repeated full-body uploads after transport fallback, and provide a supported way to remove stale inline image bodies from the model's working context while keeping the original transcript inspectable. This also appears related to #41338 and #28316.
keitacai commentedon Sep 23, 2026
Follow-up with stronger, request-level evidence from the desktop's existing local
logs_2.sqlite. No additional image work or controlled continuation was needed, and I am not attaching raw logs because they contain response headers/cookies.For the same affected thread, between 2026-09-23 17:40:45 and 18:01:52 Asia/Shanghai, I found 28
codex_http_client::requestentries forPOST /responses, each explicitly taggedtransport="responses_http"andCompressed request body with zstd. Summing the logged sizes:Immediately before this HTTP sequence,
codex_core::responses_retrylogged WebSocket failures at 17:40:18–17:40:37:Broken pipe (os error 32)andtls handshake eof. The subsequent request records explicitly identifyresponses_http. The task was later doing text/code-only review, yet those model steps kept preparing approximately 52.2-MB uncompressed / 38.5-MB compressed full request bodies. This strongly ties the repeated upload to HTTP fallback plus retained media history, rather than new image-generation requests.The preceding structural scan found 40 inline image data URLs totaling approximately 50.21 MB in
custom_tool_call_outputhistory. I did not inspect or publish the request content, so the exact byte composition of each serialized body remains unproven; the measured history size and 52.2-MB body size are, however, closely aligned.keitacai commentedon Sep 23, 2026
Sanitized recovery measurement for the same macOS Desktop case:
/compactin the affected thread. The compaction request itself still usedresponses_httpand logged a 38,538,057-byte zstd-compressed body.responses_httpwith 235,109 bytes before compression / 86,498 bytes after compression. It completed successfully. Compared with the pre-compaction 38.54-MB compressed request, this is approximately a 445x reduction for the next model step.This confirms that pruning old image bodies from the working context restores small requests even when the thread remains on HTTP fallback. It is a manual recovery, not a product fix: future image tool outputs can accumulate again, and the client still needs a byte-aware guardrail or durable media-reference strategy. No paths, session IDs, prompts, media, request bodies, headers, or cookies are included in this public comment.
KomorebiLabs commentedon Oct 8, 2026
Same，70G/day，i can‘t believe it：Codex currently has at least several design/implementation flaws:
The image bytes did not actually participate in the context compression and request size threshold determination.
The HTTP fallback will revert to "full retransmission per round," rather than the stable incremental updates.
The client will repeatedly attempt to send large, deterministic requests.
Lack of observability: The request body size, inline media bytes, full/incremental mode, transmission fallback, and cumulative retransmission bytes are not exposed to the user.
Regarding the OpenAI side, the focus is on scaling resources: while users experience unlimited traffic and don't notice the difference, the server still needs to handle receiving, TLS termination, routing, deserialization, and processing these repetitive, full-sized requests.
This is not an isolated incident; the issue also references independent reports #45109, #24550, #43015, and #38014.
guoa985-crypto commentedon Oct 11, 2026
Additional Windows desktop evidence: compaction cuts a 90.9 MB request to 84.7 KB, but new tool images rapidly rebuild large requests
Adding sanitized measurements at the affected user's request to this existing bandwidth tracker. This also relates to #43015. These observations are from October 11, 2026; times below are UTC+8. The measurements were collected by Codex through read-only inspection of retained client logs, session structure, and local proxy counters.
Environment: Windows 11 x64, build 26200; desktop-bundled
codex-cli 0.162.0-alpha.17.2; normal ChatGPT/Codex desktop use through a local proxy. No custom client fork or manual changes to session JSONL/SQLite were used. Client logs recorded HTTP fallback in the affected sessions earlier that morning. The initial network failure's cause is not established.Natural before/after observations across three image-assisted tasks:
The three corresponding compacted replacement-history records contained zero inline image data URLs. By the 11:33 structural snapshot, task B had accumulated 18 new image occurrences totaling 27,242,124 Base64 characters, and C had five totaling 9,478,224 characters. Task B's later uncompressed request was 27,903,254 bytes. These are structural observations, not a claim that the exact content of every outgoing body was captured.
Separately, the local proxy sampler attributed approximately 4.863 GB of upload to
codex.exeon proxied connections over 90.48 minutes of observed intervals through 11:36:38, with several tasks active. Sampling gaps, including 11:25–11:35, were excluded rather than counted as zero. This is process-attributed proxy traffic, not a packet-level WAN measurement or the VPN provider's billing total. Likewise, the table measures prepared compressed request bodies, not proof that every byte was successfully delivered or billed as tokens.The useful new evidence is rapid recurrence after successful manual compaction on a newer desktop-bundled version. Compaction can recover a small working context, but continued legitimate image inspection quickly makes later requests large again. Archiving tasks and changes in workload mean this is not a controlled overall bandwidth benchmark.
Could the maintainers confirm the owning tracker and a supported mitigation, and consider:
The practical impact is unexpectedly high upload consumption on a metered connection. Local file deletion or an AGENTS.md instruction cannot remove image bodies already embedded in active history. Users need a product-supported working-context solution. No prompts, image contents, local project paths, account/session IDs, headers, cookies, credentials, or raw logs are included in this comment.
GameDevBaiyi commentedon Oct 16, 2026
Additional Windows desktop measurements, October 16, 2026
Adding a sanitized follow-up at the affected user's request. These measurements were collected by local diagnostic tasks during multi-session coding/UI work; the reporting assistant did not independently repeat the measurements. The precise desktop app and bundled CLI versions were not captured in this report.
Ten-minute observation (14:01:38–14:11:38 UTC, 600 seconds):
codex.execonnections tochatgpt.com.Separate short idle comparison:
Two equal 50-second windows each covered approximately 48 seconds of observed traffic. Repeated outer agent/tool wait cycles recorded 4,370,553 upload bytes, versus 312,955 bytes with a single local wait, a 92.84% reduction in that short comparison. Five idle workers were also stopped during the broader mitigation work; this was not a controlled benchmark of normal multi-session development. The short idle result should not be treated as a promised reduction during coding or UI work.
The fresh evidence is that substantial upload remains observable during Windows desktop use, and avoidable continuation cycles can materially increase traffic even during a short idle period. This report does not establish that the affected October 16 traffic used WebSocket-to-HTTP fallback or replayed historical image bodies. Those remain hypotheses consistent with this tracker, requiring request-level confirmation. The Windows symptom also appears relevant to #29854.
Please prioritize investigating repeated large-context/media replay and fallback behavior, and expose serialized request bytes, retained media bytes, full/incremental request mode, and transport mode in supported diagnostics. A byte-aware guardrail and a supported recovery within the existing conversation would be valuable; users should not have to abandon or move ongoing sessions to keep upload bounded. Unexpected upload at this scale can carry meaningful cost on metered connections.
No project names, private repository links, prompts, images, local paths, session IDs, raw logs, or credentials are included.