AI编程工具每一次迭代升级，似乎都变得更加“臃肿”。而这一趋势，在Codex身上展现得淋漓尽致。

近日，社交平台上流传着一组令人震惊的数据：有用户反馈，安装OpenAI的Codex桌面端后，仅一个月时间，网络流量消耗就飙升至150GB。评论区瞬间沸腾，大量用户表示深有同感。150GB是什么概念？大致相当于你24小时不间断播放4K视频，连续看五六天。而这一切，竟然都来自一个号称“帮你写代码”的工具。

更夸张的还在后面。不止是网络流量，硬盘也未能幸免。

在V2EX上，有用户发帖抱怨，安装Codex桌面端刚满一个月，他那台Mac的SSD写入量硬生生增加了4.8TB。他平时开发工作一切正常，Codex不用时也没有刻意退出，只是让它安静地待在后台。一个月下来，硬盘的写入强度早已远超“轻度办公”的范畴。

这背后究竟发生了什么？Codex到底做了什么，需要消耗如此惊人的资源？

01 150GB流量都去哪儿了？

要理解这个数字，首先要搞清楚Codex到底是什么。

很多人可能还停留在“AI代码助手”的印象中，觉得它和GitHub Copilot差不多，无非是帮忙补全代码、修复bug。但实话告诉你，如今的Codex早已进化成一个完整的AI开发环境——它拥有独立的桌面客户端、云端的沙盒执行引擎，深度集成GitHub，支持手机远程操控，甚至可以一次性派出8个AI agent并行帮你提交PR。

这意味着，Codex在你的电脑上运行时，远不止是在“聊天”那么简单。

首先是连接方式。Codex桌面端默认采用WebSocket长连接，实现实时双向通信。这不是普通的“发一个请求，等一个回复”，而是一条始终保持连通的数据管道——模型推理的中间过程、工具调用的实时状态、代码diff的流式传输，全部通过这条管道源源不断地传输。一旦网络环境不稳定，WebSocket会反复重连，从“Reconnecting 1/5”一直尝试到“5/5”，然后退回到HTTP流式传输。这些重试行为本身就在消耗带宽。

然后是执行架构。Codex的核心设计是“云端沙盒执行”。你提交一个编码任务，它就在OpenAI的云端启动一个隔离环境，加载你的代码仓库，执行修改，跑测试，最后把结果传回来。每一轮交互，都涉及大量数据的双向传输——上传代码上下文、下载执行结果、同步中间状态。如果你同时开启了多个并行任务，这个数据量还要乘以并发数。

最后，是它“始终在线”的设计理念。

Codex桌面端不是一个“用完就关”的工具。它需要保持GitHub代码审查的实时同步、维护任务队列的状态、处理MCP服务器的连接、支持从手机端远程操控。这些后台服务都需要持续的网络连接。即便你没有主动使用Codex，它也在后台默默工作——索引你的项目文件、维护缓存、保持心跳。这也解释了为什么有用户发现，“放在后台不退出”一个月，就写掉了将近5TB的硬盘数据。

把这些因素加总在一起，一个重度用户每天使用Codex六到八小时，配合GPT-5.5的超高推理模式，日均网络流量达到3-5GB完全正常。一个月下来，100GB到150GB，绝不是个夸张的数字。

02 为什么Claude Code没事？

有趣的是，Anthropic的Claude Code，作为Codex最直接的竞争对手，几乎从未传出过类似的抱怨。没人讨论它消耗了多少流量，也没人说它写坏了硬盘。

原因很简单——两者的产品形态，从根儿上就不一样。

Claude Code是一个纯粹的终端CLI工具。你打开终端，输入命令，它帮你干活，干完了它就安静了。没有Electron桌面客户端、没有后台常驻进程、没有WebSocket长连接、没有云端沙盒。代码的读写、文件操作、命令执行，全部在本地机器上完成。网络传输的只有一样东西——你发给Anthropic API的prompt，和它流式返回的response文本。一个标准的HTTPS请求，拿完结果，连接就断了。

这个架构差异，带来了一个反直觉的现象。多项评测显示，Claude Code在token消耗上其实比Codex更“奢侈”——有开发者记录到，同一个复杂重构任务，Claude Code花了155美元的API费用，Codex只花了15美元。Codex的token效率，大约是Claude Code的四倍。

但token消耗大，不等于网络流量大。

Claude Code虽然单次任务吞噬的token更多，但它的交互模式是“一次吃饱”——大块上下文丢进去，大块结果拿回来，中间不需要反复通信。Codex则恰恰相反，它把任务拆解成很多小步骤、很多轮次，每一步都要在本地和云端之间来回传输数据。token效率是高了，但网络开销反而更大了。

更关键的是，Claude Code没有后台静默消耗。你不用它的时候，它压根就不存在。不会有进程在后台索引你的项目，不会有服务在维护缓存，不会有心跳包在保持连接。用完即走，干干净净。

03 AI工具越来越“重”

如果把视角拉远一点，你会发现Codex的150GB流量，不是一个孤立事件，而是AI编程工具这几年“重量级化”趋势的缩影。

回顾这条演进路径——

GitHub Copilot刚出来的时候，它做的事情很简单：在你写代码时补全下一行。它本质上是一个编辑器插件，轻得几乎感觉不到存在。

然后是Cursor、Windsurf这一代。它们开始接管整个文件的修改，能理解项目结构，能跨文件做重构。开发者的角色，从“写代码”变成了“审代码”。工具变重了一点，但还在编辑器框架之内。

Claude Code再进一步。它跳出了编辑器，直接在终端里操作——读文件、改文件、跑命令、装依赖，一整套开发工作流都能接管。开发者的角色进一步后退到“下指令、审结果”。但它仍然是一个CLI工具，用完即走。

Codex则代表了这条路的最新一站。它不再满足于做一个“工具”，而是想成为一个“环境”——一个始终运行的、多agent并行的、云端和本地融合的、从写代码到出PR全包的AI开发平台。Remote Control功能甚至让你在地铁上用手机就能指挥家里电脑上的Codex继续干活。

每升级一代，AI编程工具就沉重一分。而150GB流量和5TB磁盘写入，就是这个“重量”在物理世界最真实的投射。

问题在于——这条“越来越重”的路，是唯一的路吗？

Claude Code提供了一个有趣的反例。它在SWE-bench Verified上的分数和Codex的GPT-5.5几乎打平，代码质量在盲测中被评为更好的比例甚至更高。但它的产品形态却选择了完全相反的方向——保持终端原生，保持轻量，把算力留给模型推理，而不是客户端基础设施。

一个越来越“重”，一个刻意保持“轻”。

两条路都有各自的拥趸。一个500多名开发者参与的Reddit调查显示，65%的人日常更偏好Codex——因为它确实更省心，丢进去一个任务就不用管了。但盲测代码质量时，67%的人认为Claude Code的输出更干净。

很多顶级开发者已经用脚投票，选择了“混合路线”——用Claude Code做初始架构和功能生成，再用Codex做代码审查和debug。一位开发者的总结流传很广：“Claude Code管架构，Codex管打字。”

这大概就是当前AI编程工具最真实的图景。不存在一个绝对正确的“重量”。重有重的好处——Codex的后台并行执行和GitHub深度集成，确实让很多工作流变得更流畅。轻有轻的好处——Claude Code的纯终端设计，让开发者对自己的环境保有完全的控制权。

但如果你看到150GB流量这个数字会本能地觉得“这也太夸张了”，那或许值得认真想一想——当AI编程工具从“你偶尔调用的助手”演化成“始终运行的基础设施”，它在你的开发环境里占的“重量”，正在以一种你可能没注意到的速度增加。

而这个重量，你的硬盘知道，你的网络流量知道，你的电费账单，也会慢慢知道。