Codex: 1 个月吃掉 150GB 流量: 写满 4T 硬盘: 疯了吗？

社交媒体上近日出现令人震惊的数据：安装OpenAI Codex桌面端后，一个月流量耗尽150GB，众多用户反馈了类似经历。

150GB流量约等于连续五六天全天候播放4K视频的消耗量，而这一切竟被一个编程辅助工具所吞噬。

更为惊人之处在于，损耗远不止网络流量这一项。

V2EX平台有用户表示，使用Codex桌面端仅一个月，其Mac的SSD写入量激增4.8TB。该用户日常仅为正常开发工作，且在不使用Codex时也未退出该应用，任由其在后台运行。一个月后，硬盘写入强度已显著超越常规轻办公水平。

这种现象背后隐藏着什么？Codex究竟进行了哪些操作，竟需要如此庞大的资源消耗？

01 150GB 去哪了？

要解析这一数据，需先明确Codex的实质功能。

许多人误以为Codex仅是“AI代码助手”，与GitHub Copilot类似，用于补全代码或修复漏洞。但实际上，当前的Codex已演变为一个完整的AI开发环境——它具备基于Electron的独立桌面客户端、云端沙盒执行引擎、GitHub深度整合、手机远程操控功能，甚至能同时派遣8个AI agent并行生成PR。

这意味着Codex在本地运行时，其活动范围远不止于“对话”。

首先是连接方式。Codex桌面端默认采用WebSocket长连接实现实时双向通信。这并非普通的“发送请求、等待回复”，而是一条持续运作的数据管道，模型推理的中间步骤、工具调用的实时状态、代码差异的流式传输均通过此管道不断输送。当网络环境不稳定时（这在开发者实际场景中极为常见），WebSocket会反复重连——从“Reconnecting 1/5”尝试至“5/5”，随后回退至HTTP流式传输。这些重试行为本身即消耗带宽。

然后是执行架构。Codex的核心设计是“云端沙盒执行”。当你提交编码任务时，Codex在OpenAI云端启动隔离环境，加载你的代码仓库，执行修改，运行测试，最终将结果回传。每次交互均涉及大规模数据的双向传输——上传代码上下文、下载执行结果、同步中间状态。若同时开启多个并行任务，数据量还需乘以并发数。

最后是“始终在线”的设计哲学。

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

将这些因素汇总，重度用户每日使用Codex六至八小时，配合GPT-5.5超高推理模式，日均网络流量达到3-5GB完全正常。一个月下来，100GB-150GB并非夸张数字。

02 为什么 Claude Code 没事？

有趣的是，Anthropic的Claude Code作为Codex最直接的竞争对手，几乎未出现类似抱怨。无人讨论Claude Code消耗多少流量，也无人提及它损坏硬盘。

原因十分简单——两者的产品形态从根源上截然不同。

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上的得分（Opus 4.8达到88.6%）与Codex的GPT-5.5（88.7%）几乎持平，盲测中代码质量被评为更优的比例甚至更高。但其产品形态选择了完全相反的方向——保持终端原生，保持轻量，将算力留给模型推理而非客户端基础设施。

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

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

许多顶级开发者已用行动选择了“混合路线”——用Claude Code进行初始架构与功能生成（因其上下文理解更深），再用Codex执行代码审查与调试（因其更快且更省token）。一位开发者的总结流传甚广——「Claude Code管架构，Codex管打字」。

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

若你看到150GB流量数字时感到夸张，不妨思考：AI编程工具正从偶尔调用的助手演变为始终运行的基础设施，这种‘重量’正悄然以你未曾察觉的速度渗透你的开发环境——你的硬盘、网络流量乃至电费账单都将逐步感知到这一变化。