云 / 系统
编程代理工作时，终端里通常不会缺少动静：命令不断出现，文件发生变化，消息接连到来。但我想知道的问题往往很简单：这个会话正在使用哪个模型？上下文用了多少？眼前的会话，还是我心里想着的那个吗？这项工作当前花费了多少？
活动指示器回答的是另一个问题
之前的 ETA 文章讨论如何安排自己的时间：继续等、切换任务，还是稍后再回来？状态栏处理的是同一问题的另一部分。在决定下一步之前，我希望先看清眼前会话的基本情况。
转动的图标说明有活动，长长的对话记录说明发生过什么。但要获得一眼就能看懂的基本信息，我可能仍然需要到处查找。
状态栏让哪些信息更清楚
提供的终端画面让这个想法更具体：一行同时展示所选路由、实际模型、上下文占用和费用估算。项目路径与账户标识已替换为中性示例。
路由选择与最终使用的模型是不同的信息。这里通过 OpenRouter 路由到 OpenAI 模型。这是一种扩展配置，并非 Claude Code 的默认界面。
上下文显示为 186,551 / 1,000,000 个 token，对应画面中的 19.0%。数字更容易理解，但上下文占用 19% 不代表任务完成 19%，也不能据此推算还需要几分钟。
费用字段是估算或供应商相关计数，需要明确各自定义；状态栏中的数字并不等于核实后的账单。预测与自动模式是这一配置的其他信号，不是本文最小渲染器的功能。
费用控制也应该放在这一行里
费用可见性是添加状态栏的重要理由。代理可以持续产生活动，而我却可能忘记已经进行了多少次尝试、重试或并行会话。我希望在查看账单之前，就能留意这种情况。
截图显示“est. $6.61”和“OR today $9.31”。它们的标签不同，不能直接当作两个独立金额相加。依赖这些数据之前，必须理解其统计范围、参考价格和更新方式。估算帮助调整工作，实际扣费仍应查看供应商的用量记录。
- 开始前设置费用检查点。 先决定何时暂停并评估后续运行。
- 比较费用增长与有用结果。 如果计数持续上升，同一测试却一直失败，应先缩小任务或检查阻碍，再进行下一轮大范围尝试。
- 有意识地选择下一步。 更小的后续任务、适合的模型或人工检查可能已经足够。更换模型后仍需执行相同的质量检查。
可见的计数器不等于自动预算上限，也不会停止请求。API 费用、订阅和供应商余额也应分开理解。重点是把开支与时间、技术质量一起纳入明确的工作决策。
数字应该帮助人作决定
上下文比例上升时，我会考虑如何继续：下一步是否清楚？重要决定是否已经写在可以长期保留的地方？开始下一阶段前，是否需要准备一段简明交接？
并不存在一个通用百分比，超过它会话就会变差。边界清晰的小任务和长时间排查需要不同的上下文。数字提供方向，实际工作仍要检查。
上下文比例也不能告诉我代理是否在等待许可或决定。那需要明确的注意力信号，是本系列的另一个主题。
“不可用”也是有用的答案
最不可靠的显示，是把缺失的信息悄悄变成令人安心的零。数据不存在时，就应该明确说明。
截图展示的是已有数据。缺失时，我宁愿看到“不可用”，而不是绿色的零，这样就能知道自己究竟缺少什么信息。
小到可以看懂，也容易移除
Claude Code 支持自定义状态栏：本地命令接收 JSON 会话数据，并输出显示内容。官方文档列出了模型和上下文字段，因此不必另做一个大型仪表板。
最小版本会先展示模型与上下文，等费用估算的来源和范围清楚后再加入费用。渲染器只使用提供的字段：不扫描代码仓库，不访问网络，也不保存对话。这些是本示例的设计选择，并不代表所有扩展都具有相同特点。
启用渲染器之前，我会用已知输入进行测试，确认缺失的数据确实显示为缺失。对我来说，起点是容易理解的信号，而不是尽可能多的数字。
让脑海里少装几件事
一行状态不会改善代理的推理，也不能代替代码审查。但它可以提供一个稳定位置，展示那些原本需要我记住或查找的信息。
这正是我感兴趣的方向：减少为了确认基本状态而产生的中断，把注意力留给真正需要人来决定的事情。你会在会话下方的一行里放什么？
参考资料
Claude Code 状态栏官方文档，核对日期：2026年10月27日。