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

最近在社交媒体里看到一个让人瞠目的数字——有用户说自从装了 OpenAI 的 Codex 桌面端，一个月的流量直接干到了 150GB。评论区里一片共鸣，不是一个人，很多人都在说类似的事情。

150GB 是什么概念？大概相当于每天 24 小时不间断看 4K 视频看五六天。而这些流量，全部被一个「帮你写代码」的工具吃掉了。

更离谱的是，不只是网络流量。

V2EX 上有用户发帖说，装了 Codex 桌面端一个月，Mac 的 SSD 写入量暴增了 4.8TB。他平时就是正常开发工作，Codex 不用的时候也没退出，就放在后台。一个月下来，硬盘的写入强度已经远超「轻度办公」的范畴。

这背后到底发生了什么？Codex 到底做了什么，需要这么多资源？

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

很多人以为 Codex 就是个「AI 代码助手」，跟 GitHub Copilot 差不多，帮你补补代码、改改 bug。但实际上，今天的 Codex 已经进化成了一个完整的 AI 开发环境——它有独立的桌面客户端（基于 Electron），有云端沙盒执行引擎，有 GitHub 深度集成，有手机远程操控，甚至可以同时派出 8 个 AI agent 并行帮你出 PR。

这意味着 Codex 在你电脑上运行时，远不只是在「聊天」。

首先是连接方式。Codex 桌面端默认使用 WebSocket 长连接做实时双向通信。这不是普通的「发一个请求、等一个回复」，而是一条始终保持的数据管道，模型推理的中间过程、工具调用的实时状态、代码 diff 的流式传输，全部通过这条管道持续灌输。当网络环境不稳定时（这在很多开发者的实际使用场景中极为常见），WebSocket 会反复重连——从「Reconnecting 1/5」一直试到「5/5」，然后回退到 HTTP 流式传输。这些重试本身就在消耗带宽。

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

最后是「始终在线」的设计哲学。

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

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

有趣的是，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 没有后台静默消耗。你不用它的时候，它不存在。不会有进程在后台索引你的项目，不会有服务在维护缓存，不会有心跳包在保持连接。用完即走，干干净净。

如果把视角拉远一点，会发现 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 做代码审查和 debug（因为它更快更省 token）。一位开发者的总结流传很广——「Claude Code 管架构，Codex 管打字」。

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

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

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