☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
最近在社交平台上刷到一组令人咋舌的数据——有用户反馈，自打装上 OpenAI 推出的 Codex 桌面版后，单月网络用量飙升至 150GB。评论区迅速被同类经历刷屏，不止一位开发者表示：自己也遭遇了几乎一模一样的“流量黑洞”。
150GB 是什么量级？粗略换算，相当于连续五天、每天 24 小时不间断播放 4K 视频所消耗的带宽。而这些数据，全被一个标榜“帮你写代码”的工具悄无声息吞掉了。
更令人咋舌的还不止于此。
V2EX 上一位用户发帖称：启用 Codex 桌面客户端仅一个月，Mac 的 SSD 累计写入量竟高达 4.8TB。他日常仅做常规开发，Codex 并未主动调用，也未手动退出，始终处于后台挂起状态。结果一个月下来，硬盘写入强度已远超普通办公负载，逼近重度虚拟机或视频渲染场景。
这背后究竟发生了什么？Codex 到底在本地默默运行着怎样的机制，才需要如此庞大的资源支撑？
01 150GB 流量流向何处？
要解构这个数字，得先厘清 Codex 的真实身份。
不少人误以为它只是 GitHub Copilot 的升级版——一个更聪明的代码补全插件。但现实是，如今的 Codex 已不再是一个插件，而是一整套 AI 原生开发环境：自带 Electron 构建的桌面客户端、云端沙盒执行引擎、深度绑定 GitHub 的实时协作能力、支持手机远程调度，甚至能同时调度多达 8 个 AI agent 协同完成 Pull Request。
这意味着，当你启动 Codex 桌面端，它做的远不止“聊天式编程”。
首先是通信协议的选择。
Codex 默认启用 WebSocket 长连接，实现毫秒级双向响应。这不是传统意义上的“请求-响应”模式，而是一条持续打开的数据通道——模型推理中间态、工具调用实时反馈、代码 diff 的增量流式推送，全部经由这条管道实时涌向本地。一旦网络波动（这在居家办公、咖啡馆、通勤途中极为常见），WebSocket 就会触发重连机制：从 “Reconnecting 1/5” 一路尝试到 “5/5”，失败后降级为 HTTP 流式传输。每一次重试，都在悄悄吃掉你的带宽。
其次是执行范式的转变。
Codex 的核心逻辑是「云端沙盒执行」。你提交一个编码需求，系统便在 OpenAI 后端动态拉起隔离容器，加载你的完整代码库，执行修改、运行测试、生成变更摘要，再将结果回传。每一轮交互都涉及大量上下文上传（文件内容、依赖树、构建日志）、执行产物下载（新代码、测试报告、diff 补丁）以及中间状态同步。若同时开启多个任务，数据吞吐量呈线性叠加。
最后是“永不休眠”的设计理念。
Codex 桌面端不是“即用即关”的轻量工具。它需维持 GitHub PR 审阅的实时同步、缓存任务队列状态、保持与 MCP（Model Control Protocol）服务器的常连、响应移动端远程指令……这些后台服务无一例外依赖持续网络心跳。哪怕你并未主动操作，它仍在后台静默运转——扫描项目结构、预加载文件索引、刷新本地缓存、发送保活信号。这也正是为何有人发现，“后台挂着不关”一个月，硬盘写入量就逼近 5TB。
将上述因素叠加：一名高频使用者每日使用 6–8 小时，叠加 GPT-5.5 的高分辨率推理模式，日均流量达 3–5GB 实属常态。一个月累计 100–150GB，并非异常，而是该架构下的合理输出。
02 为何 Claude Code 毫无动静？
耐人寻味的是，Anthropic 推出的竞品 Claude Code，却从未引发类似争议。没人吐槽它耗尽流量，也没人抱怨它拖垮硬盘寿命。
根本原因在于——二者的产品基因截然不同。
Claude Code 是一款纯粹的终端命令行工具。你在 Terminal 输入指令，它执行任务，完成后立即释放资源。没有 Electron 客户端，没有常驻后台进程，没有 WebSocket 连接，更无云端沙盒。
所有代码读取、文件修改、命令执行、依赖安装，均发生在本机。网络层面仅需一次标准 HTTPS 请求：把 prompt 发往 Anthropic API，接收流式返回的文本结果，任务结束，连接关闭。
这种架构差异催生了一个反常识现象：多项实测表明，Claude Code 在 token 消耗上反而比 Codex 更“豪横”——有开发者记录显示，同一复杂重构任务，Claude Code 花费约 155 美元 API 费用，Codex 仅需 15 美元左右。Codex 的 token 利用效率约为前者的四倍。
但 token 节省 ≠ 流量节省。
Claude Code 单次任务虽消耗更多 token，但其交互是“集中式”的：大块上下文一次性上传，完整结果一次性返回，中间无需反复握手。Codex 则把任务切分为数十个小步，每一步都要在本地与云端之间往返传输状态、日志与中间产物。token 效率提升了，网络开销却显著放大。
更关键的是，Claude Code 具备天然的“零后台”特性。不用它时，进程彻底消失；不存在后台索引行为，不维护持久化缓存，也不发送心跳包。用完即走，不留痕迹。
03 AI 编程工具正悄然变“重”
若跳出单一产品，将视野拉长，便会发现 Codex 的 150GB 流量并非孤例，而是 AI 编程工具近年“重型化”演进路径上的一个典型切片。
回溯这条技术脉络——
GitHub Copilot 初期仅聚焦于“下一行补全”，本质是 IDE 插件，轻如无物，几乎无法感知其存在。
随后登场的 Cursor、Windsurf 开始接管整文件修改，理解跨文件依赖，支持模块级重构。开发者角色从“写代码”转向“审代码”。工具重量略有提升，但仍依附于编辑器生态。
Claude Code 再进一步：脱离编辑器束缚，直连终端，读写文件、执行 shell 命令、安装依赖、运行测试，整套开发闭环均可覆盖。开发者退至“下达指令—验收结果”环节。但它仍坚守 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 编程工具从“你偶尔唤起的助手”，进化为“永不关机的基础设施”，它在你的开发工作流中所占据的“物理权重”，正以一种你未必察觉的方式，加速累积。
而这份重量，你的 SSD 记录着，你的宽带账单标注着，连你家的电表，也在默默见证。
本文来自微信公众号 “极客公园”（ID：geekpark），作者：宇航猿，36氪经授权发布。
