OpenAI Codex's desktop version has sparked user discussion due to high resource consumption, with some users reporting monthly data usage of up to 150 GB and disk write volumes reaching 4.8 TB. The article analyzes the causes: Codex employs persistent WebSocket connections, cloud-based sandbox execution, and parallel multitasking, resulting in continuous network traffic and background operation. In contrast, its competitor Claude Code uses a pure terminal CLI design, running only when needed and consuming significantly fewer resources. The article suggests that AI programming tools are evolving toward a "heavyweight" model, transitioning from editor plugins into continuously running development environments, and users should pay attention to their hardware resource consumption.

Article author and source: 36Kr

AI programming tools improve with each generation.

Recently, I saw a startling number on social media—a user claimed that since installing OpenAI’s Codex desktop app, their monthly data usage spiked to 150 GB. The comments section was filled with agreement; it wasn’t just one person—many others shared similar experiences.

What does 150GB mean? It’s roughly equivalent to watching 4K video nonstop for five or six days. And all of this data was consumed by a tool that “writes code for you.”

Even more absurdly, it’s not just network traffic.

A user on V2EX posted that after installing the Codex desktop app for a month, their Mac’s SSD write volume surged to 4.8 TB. They were only doing normal development work and left Codex running in the background even when not actively using it. Over the course of the month, the disk write intensity far exceeded the level of “light office use.”

What exactly happened behind the scenes? What did Codex do that required so many resources?

Where did the 01 150GB go?

To understand this number, you first need to know what Codex actually is.

Many people think Codex is just an “AI code assistant,” similar to GitHub Copilot, helping you autocomplete code or fix bugs. But in reality, today’s Codex has evolved into a complete AI development environment—it features a standalone desktop client (built on Electron), a cloud-based sandbox execution engine, deep GitHub integration, remote control via mobile, and even the ability to deploy up to eight AI agents in parallel to help you submit pull requests.

This means that when Codex is running on your computer, it's doing much more than just "chatting."

First is the connection method. The Codex desktop application uses WebSocket persistent connections by default for real-time bidirectional communication. This is not the typical “send a request, wait for a reply” model, but rather a continuously open data pipeline through which intermediate model inference steps, real-time tool invocation status, and streamed code diffs are continuously transmitted. When network conditions are unstable—which is extremely common in many developers’ actual usage scenarios—the WebSocket connection repeatedly attempts to reconnect, progressing from “Reconnecting 1/5” all the way to “5/5,” before falling back to HTTP streaming. These retry attempts themselves consume bandwidth.

Next is the execution architecture. Codex’s core design is “cloud-based sandbox execution.” You submit a coding task, and Codex launches an isolated environment on OpenAI’s cloud, loads your code repository, performs modifications, runs tests, and returns the results. Each interaction involves substantial two-way data transfer—uploading code context, downloading execution results, and synchronizing intermediate states. If you run multiple parallel tasks simultaneously, this data volume scales by the number of concurrent tasks.

Finally, the "always online" design philosophy.

Codex for desktop is not a "use and close" tool. It must maintain real-time synchronization with GitHub code reviews, manage the state of the task queue, handle connections to the MCP server, and support remote control from the mobile app. These background services require a persistent internet connection. Even when you're not actively using Codex, it continues working silently in the background—indexing your project files, maintaining caches, and keeping heartbeats alive. This also explains why some users have discovered that leaving Codex running in the background for a month generated nearly 5 TB of disk data.

Adding it all up, a power user spending six to eight hours daily on Codex alongside GPT-5.5’s ultra-reasoning mode can easily generate 3–5 GB of network traffic per day. Over a month, 100–150 GB is not an exaggerated figure.

02 Why is Claude Code fine?

Interestingly, Anthropic’s Claude Code, as the most direct competitor to Codex, has almost never faced similar complaints. No one discusses how much bandwidth Claude Code consumes or claims it damages hard drives.

The reason is simple—their product formats are fundamentally different.

Claude Code is a pure terminal CLI tool. You open your terminal, enter a command, it does the work for you, and then it goes quiet. No Electron desktop client, no background processes, no WebSocket persistent connections, no cloud sandbox.

Code reading and writing, file operations, and command execution are all performed locally on your machine. The only thing transmitted over the network is the prompt you send to the Anthropic API and the streaming response text it returns—a standard HTTPS request, with the connection closed immediately after retrieving the result.

This architectural difference leads to a counterintuitive phenomenon. Multiple evaluations show that Claude Code is actually more "wasteful" in token consumption than Codex—some developers have recorded that for the same complex refactoring task, Claude Code cost $155 in API fees, while Codex cost only $15. Codex’s token efficiency is approximately four times that of Claude Code.

However, high token consumption does not equate to high network traffic.

Although Claude Code consumes more tokens per task, its interaction model is “feed it all at once”—you input a large context and receive a large result back, without needing repeated communication in between. Codex, on the other hand, breaks the task into many small steps and rounds, requiring data to be transmitted back and forth between local and cloud systems at each step. While it’s more token-efficient, it incurs greater network overhead.

More importantly, Claude Code doesn’t consume resources in the background. When you’re not using it, it doesn’t exist—no processes indexing your project, no services maintaining caches, no heartbeat signals keeping connections alive. Use it, then let it go—clean and tidy.

03 AI tools are becoming increasingly "heavy"

If you take a step back, you'll see that Codex's 150GB of traffic is not an isolated incident, but rather a reflection of the broader trend over the past few years toward heavier, more resource-intensive AI programming tools.

Review this evolution path—

When GitHub Copilot first launched, it did something simple: it completed the next line as you coded. It was essentially an editor plugin, so lightweight that you barely noticed it was there.

Then came Cursor, Windsurf, and their generation. They began taking over entire file modifications, understanding project structures, and performing cross-file refactoring. The developer’s role shifted from “writing code” to “reviewing code.” The tools became slightly heavier, but still remained within the editor framework.

Claude Code goes further—it steps out of the editor and operates directly in the terminal: reading files, modifying files, running commands, installing dependencies—all aspects of the development workflow are taken over. The developer’s role recedes further to simply “give instructions and review results.” Yet it remains a CLI tool, used and then dismissed.

Codex represents the latest stop on this journey. It no longer aims to be just a "tool," but rather an "environment"—an always-on, multi-agent, cloud-and-local-integrated AI development platform that handles everything from writing code to submitting pull requests. The Remote Control feature even lets you command Codex running on your home computer from your phone while on the subway.

Each generation upgrade makes the AI programming tool一圈 heavier, and 150GB of data traffic and 5TB of disk writes are the physical manifestations of this "weight."

The question is—Is this increasingly heavy path the only path?

Claude Code provides an interesting counterexample. Its score on SWE-bench Verified (Opus 4.8 achieved 88.6%) is nearly tied with Codex’s GPT-5.5 (88.7%), and in blind tests, its code was rated as superior in an even higher proportion. However, its product design took the exact opposite approach—remaining native to the terminal, lightweight, and reserving computational power for model inference rather than client-side infrastructure.

One is becoming increasingly "heavy," while the other deliberately stays "light."

Each path has its own supporters. A Reddit survey involving over 500 developers showed that 65% prefer Codex in daily use because it’s genuinely more hassle-free—just drop in a task and forget about it. However, in blind tests of code quality, 67% found Claude Code’s output cleaner.

Many top developers have already voted with their feet for a hybrid approach—using Claude Code for initial architecture and feature generation (because of its deeper context understanding), and Codex for code review and debugging (because it’s faster and more token-efficient). A developer’s summary has gone widely viral: “Claude Code handles architecture; Codex handles typing.”

This is probably the most realistic picture of current AI programming tools. There is no absolute correct “weight.” Heavier tools have their advantages—Codex’s backend parallel execution and deep GitHub integration indeed make many workflows smoother. Lighter tools have their benefits too—Claude Code’s pure terminal design gives developers complete control over their environment.

But if the number "150GB of traffic" instinctively makes you think, "That’s ridiculous," it might be worth seriously considering— as AI programming tools evolve from "occasional assistants you call upon" into "always-on infrastructure," their footprint in your development environment is growing at a pace you may not even notice.

And this weight, your hard drive knows, your network traffic knows, and your electricity bill will gradually know too.