Where does the bug appear (feature/product)?
• Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
Local Agents / Composer, including Agents Window worktrees. Not Cloud Agents at cursor.com/agents.
───
Describe the Bug
Cursor uploaded a very large amount of data to *.cursor.sh from this Mac.
Whether this is a retry bug, HTTP/2-over-proxy duplication, or “expected” Agent context upload, this volume is not acceptable. ~80 GiB in one day and ~171 GiB in four days is unusable on a proxied or metered link. I am not looking for “working as designed” that leaves this as my problem. The product needs to stop doing this, or have a real cap / incremental context path so it cannot happen again.
Traffic is from local proxy stats, binary GiB (1024-based). Process: /Applications/Cursor.app/. Almost entirely upload.
• Full month (August): ~195.8 GiB upload / ~0.9 GiB download to cursor.sh. About 95.6k requests, ~2.1 MB uploaded per request on average.
• 4 consecutive days, Aug 17–20: ~170.8 GiB upload. Almost all of the month.
• Aug 17: ~79.7 GiB (peak day)
• Aug 18: ~15.5 GiB
• Aug 19: ~57.3 GiB
• Aug 20: ~18.4 GiB
• July, same machine: 0. Same app, no comparable spike.
This was the majority of this machine’s proxy traffic for the month. I cannot keep running Cursor like this.
Peak-day client logs show Agent streams, not a one-shot repo dump:
• Spans: agent.request → streamFromAgentBackend → writeInitialRequest
• Workspace: tamagotchi-diary plus a local worktree under ~/.cursor/worktrees/tamagotchi-diary/
• Aug 19: 20+ Agent workbenches in the same window
• Agent Exec: shell tool calls about every few seconds
• Session loaded 92 Cursor rules and 92 skills (AgentSkillsCursorRulesService load completed { ruleCount: 92, skillCount: 92 })
• Indexing logs for those worktrees often show Uploading 0 files / empty merkle
• Peak Composer threads on disk are small (~1–2 MB of bubbles), so this is not an imported huge Claude Code transcript
Likely amplifiers:
• HTTP/2 on (default; cursor.general.disableHttp2 not set)
• All *.cursor.sh traffic through a local HTTPS proxy (Surge). The same host fanned out across many proxy nodes (US/JP/HK/TW), which matches timeout-then-retry on another IP.
I have not confirmed per-request payload sizes (protobuf to cursor.sh). Two hypotheses; neither makes ~171 GiB in 4 days OK:
- Every tool round-trip resends conversation + file context + all 92 skills (~2 MB × tens of thousands of calls). If that is the design, the design is too expensive.
- HTTP/2 streaming through the proxy times out and re-sends the same request body. Your forum already describes api2.cursor.sh retrying across many IPs when latency is high. If so, it is a bug, and I still paid for the duplicate upload.
Please do not close this with only “disable HTTP/2” or “use fewer agents” unless you also confirm server-side body sizes and retry counts for the Request IDs below. I can change settings. I cannot accept this as the normal cost of using Agent.
───
Steps to Reproduce
No minimal repro. Conditions when it happened:
- Cursor on macOS, HTTP/2 enabled, local HTTPS proxy in front of *.cursor.sh.
- Open a project with a large always-on skills/rules set (here: 92 + 92).
- Run many parallel local Agents (worktrees / Agents Window) for hours.
- Let an agent loop on shell/tool calls for a long time without starting a new chat.
───
Expected Behavior
• Agent tool loops must not upload on the order of 80 GiB in a day / 170 GiB in 4 days for one user on one project.
• Skills/rules should not be fully re-attached on every tool call if they have not changed.
• If HTTP/2 via proxy retries, the client must not replay a multi-megabyte body over and over.
• There should be a hard or obvious bandwidth bound so a long/stuck Agent cannot silently consume hundreds of gigabytes.
───
Screenshots / Screen Recordings
I can attach proxy graphs for cursor.sh on Aug 17–20 if useful. Not posting chat logs or repo contents.
───
Operating System
• MacOS (Apple Silicon)
───
Version Information
Current install (Menu → About Cursor → Copy may differ slightly):
IDE:
Version: 3.18.6
VSCode Version: 1.128.0
Commit: 66ed23114faa025e9308d6bce1b57763e5745170
The spike happened while this machine was on Cursor 3.18.3, update track dev (update.releaseTrack: “dev”). I have since updated; please do not treat 3.18.6 as the only version in play.
───
For AI issues: which model did you use?
GPT-5 in Cursor Agent / Composer (also Auto / default Agent models for some parallel runs). This is a bandwidth issue, not a wrong-model-output issue.
───
For AI issues: add Request ID with privacy disabled
From Aug 19, ~11:15–11:50 local. Please check server-side body size, retry count, and whether these are outliers:
Request ID: 9ce52a9a-50f7-44f0-9183-ce42f9b6e3d4
Request ID: 724a3512-83f0-413f-9818-9f0ffed1bfa4
Request ID: d76eb6b9-c85e-4dbb-86fd-c60fadd78974
Not Cloud / Background Agents (bc-…). These were local Agents.
───
Additional Information
Already ruled out:
• Not ChatGPT / other IDEs (those hosts are separate in the proxy log).
• Not a one-time codebase index (repo42 uploads of 0 files in the worktree logs).
• Not restoring a large Claude Code jsonl (those chats are ~1–2 MB locally).
• Privacy/Ghost mode does not make ~196 GiB/month fine.
Questions:
- For those Request IDs, how large was the uploaded body, and were there retries?
- In your telemetry, is ~80 GiB upload in one day from a single client an outlier?
- Is it expected that 92 skills + 92 rules are resent on every tool round-trip? If yes, that still needs to change.
- Should HTTP Compatibility Mode be HTTP/1.1 / disable HTTP/2 behind a local proxy? If retries duplicate bodies, that may explain a large fraction of the 170 GiB — I still need a client-side fix, not only a workaround.
Happy to attach Network Diagnostics or more traces.
───
Does this stop you from using Cursor?
• Yes - Cursor is unusable
For long / parallel Agent runs, until this cannot happen again. I will not treat ~171 GiB in four days as a normal bill for using the product.