编码 Agent 的成本，往往不花在你以为的地方。

发生了什么

Hacker News 上出现一条讨论，标题直指一个具体现象：Claude Code 中一行仅三个词的状态栏，会消耗用户约 15–20% 的 Token。帖子本身热度不高，讨论量有限，但它指向的机制值得拆开看。

按标题描述，问题出在状态栏这一常驻元素上——它并非一次性输出，而是在会话过程中被反复携带或刷新，因而在长会话里累积成可观的 Token 开销。需要说明的是，这一比例来自发帖者的观察，并非官方披露的基准数据，具体触发条件（会话长度、状态栏更新频率、上下文组织方式）在现有信息中并未展开。

为什么重要

编码 Agent 的计费与上下文管理，一直是这类工具最不透明的部分。用户通常只关注「我发了多少代码、模型回了多少内容」，却很少意识到：系统提示、工具定义、状态展示、历史回放这些「脚手架」同样占用上下文窗口，也照样计费。

三个词的状态栏听起来微不足道，但如果它被设计成每轮都进入上下文，那么在几十轮的工具调用循环里，它的成本就会被放大。这解释了为什么不少开发者感觉实际消耗高于预期——开销藏在结构性设计里，而不是某一次具体请求里。

对 Agent 产品而言，这是一个典型的工程权衡：状态栏提升可观测性和交互体验，代价是持续的上下文占用。多数产品不会主动披露这类开销，用户也很难自行归因。

影响与看点

对开发者，实用启示是关注长会话中的隐性成本，尤其是高频刷新的 UI 元素和常驻提示；在成本敏感场景下，精简这类元素可能比换模型更直接。

对 Agent 工具厂商，Token 效率正在成为竞争维度。当模型能力差距收窄，谁能把脚手架开销压得更低，谁就在单位成本上占优。可观测性也该跟上——让用户看得见钱花在哪，而不只是看到账单。

值得关注的点：官方是否会就此给出说明或优化；社区是否会形成对各类 Agent 工具「脚手架开销」的横向对比。这类对比一旦出现，会比单点吐槽更有参考价值。

一个独立判断：Agent 产品的下一轮优化，很可能不在模型侧，而在上下文工程的「减法」上。