最近在社交媒体上刷到一组数据，令人颇为震惊——有用户安装了 OpenAI 的 Codex 桌面客户端后，一个月内的流量消耗直接飙升到 150GB。评论区里一片共鸣，这并非个别现象，而是许多人共同遭遇的普遍问题。
150GB 究竟意味着什么？大致相当于连续不间断观看 4K 视频，持续五六天。而所有这些流量，全部被一个号称“帮助编写代码”的工具吞噬殆尽。
更惊人的还在后面，不只是网络流量层面。
V2EX 上有用户反映，安装 Codex 桌面端仅一个月，其 Mac 电脑的 SSD 写入量竟暴增了 4.8TB。平时只是正常进行开发工作，即便没有主动使用 Codex，也未曾关闭，任由它在后台默默运行。短短一个月，硬盘的写入强度已远超“轻度办公”的正常范畴。
这背后究竟发生了什么？Codex 到底在执行何种操作，需要消耗如此之多的资源？
01 150GB 究竟去了哪里？
要理解这个数字，首先必须弄清楚 Codex 到底是什么。
很多人以为 Codex 只是一个“AI 代码助手”，与 GitHub Copilot 类似，帮忙补全代码、修复 bug。但如今的 Codex 已进化为一个完整的 AI 开发环境——拥有基于 Electron 的独立桌面客户端、云端沙盒执行引擎、深度集成的 GitHub 服务、手机远程操控功能，甚至能同时派遣 8 个 AI agent 并行生成 Pull Request。
这意味着，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 没有类似问题？
有趣的是，作为 Codex 最直接的竞争对手，Anthropic 的 Claude Code 几乎从未出现过类似的抱怨。没有人讨论 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 编程工具从“你偶尔调用的助手”演变为“始终运行的基础设施”时，它在你开发环境中所占的“重量”，正在以一种你可能未曾察觉的速度持续增加。
而这个重量，你的硬盘知道，你的网络流量知道，你的电费账单也会慢慢知道。
