Resource Audit · Diagnostic Mode

Where did 150 GB go?

Developers auditing OpenAI's Codex desktop app found massive resource drain — one report: 150 GB of network traffic in a single month from one machine. This HUD models how an AI desktop app burns bandwidth, and how to audit yours. Drag the rig to orbit.

net-pipe monitor · NOMINAL
38.9
GB / month est.
drag to orbit · wheel/pinch zoom

Traffic model

Audit checklist

macOS: Activity Monitor → Network tab → sort by "Sent Bytes" / "Rcvd Bytes" per process.
Per-app totals: Settings → Network → check cumulative data per application (or Windows: Settings → Network → Data usage).
Firewall rules: use Little Snitch / LuLu (macOS) or built-in firewall to log and cap the app's outbound connections.
App settings: disable auto-indexing of large folders, lower telemetry, exclude node_modules / build dirs.
Audit progress: 0 / 4

Why AI desktop apps eat bandwidth

The math behind 150 GB

GB/mo ≈ (index_GB × resyncs/day × Δ-ratio × 30)
+ telemetry + streaming + updates

A 10 GB workspace re-syncing even 10% deltas every 10 minutes is ~1 GB × 144/day = far past 150 GB fast. The reported case is entirely plausible with aggressive sync on a big repo — which is why per-process measurement, not vibes, settles it.

How to measure it properly

macOS: Activity Monitor's Network tab shows per-process bytes since boot; nettop -P in Terminal gives live per-process rates. Little Snitch keeps historical per-app totals.

Windows: Task Manager → App history, or Settings → Network & internet → Data usage for 30-day per-app totals. Resource Monitor shows live TCP per process.

Measure a full week — sync spikes are bursty and a 10-minute sample lies.

How to limit the drain

Enjoy this tool? Build your own with Super