这两天我在群里反复看到的问题是：看起来差不多的任务，怎么这次积分扣得这么多？
我先把立场摆这儿：我是版主，更是用户。版主该维护讨论秩序，但轮到我自己开 Agent、看着积分往下掉，想问的问题和大家一样：这钱到底花在哪儿？
说实话，我能理解大家不爽。不是因为大家都默认 AI 应该免费，而是因为扣分那一刻，自己像在盲盒机前按了个按钮：积分少了多少，原因靠猜。
更难受的还不是已经扣掉的那一笔，而是开跑前完全没法判断投入产出。用户不需要你预报到小数点，只需要一个大概：这个任务值不值得现在跑，它大概率会吃掉多少预算。你以为够用一个月的额度，两三天就跑完，换谁都很难接受。
先把话说在前面：我不反对按 Token 算账。
TRAE 中国版在 7 月 31 日从“速通”调整为积分制。官方说按模型和实际 Token 用量换算积分，Agent、Chat、自动化任务都算在内。Agent 越跑越长、上下文越塞越多，继续按“跑一次收一次”来算，确实越来越难解释差异；按实际用量算账会更自洽。
官方说明里也列了影响消耗的因素：上下文、多轮对话、模型、工具调用返回内容……都可能把积分推高。官方还说可以在“设置 > 用量管理”里看余额、记录和明细。
至少对我和不少重度用户，问题不是“你为什么收费”，而是“这次为什么这么贵”：哪个模型、上下文、轮次或工具返回，把账推高了？
“变量很多”不是把 Token 消耗明细说不清楚的理由。积分是积分，Token 消耗明细是另一回事。
更让人火大的，是回应里那股“变量都告诉你了，这就是正常消耗”的味道。说白了，把上下文、模型、工具返回念一遍，再让用户自己接受，不算解释，最多算搪塞。
官方当然说有记录和明细。
但是这么简单的一行记录解释不了消耗的明细。既然是按模型和实际 Token 扣分，用户最想看的任务级 Token 拆分，如果还没摆出来，手里就没有核对消耗的依据。我不知道这背后是技术限制、成本，还是产品取舍；可从用户感受来说，等不到这份明细，和不愿把最核心的成本依据摊开，区别不大。
所以我去用了开源的 firerlAGI/TraeUseToken。
它是非官方、本地优先的扩展，不会在开跑前算命；它做的是在调用发生后，按自己的采集口径摊开输入、输出、缓存、模型和积分。“实际”与“实验估算”积分也不是一回事，后者不能当官方积分结算结果。但它至少把问题从“扣了多少”拉回了“为什么扣”。
我这次会话里，按这个插件的算法看，缓存命中率只有十来个点。
就这一次会话的体感来说，这个数低得有点离谱。不是“比预期少一点”，是看完会忍不住回头确认：TRAE 的agent到底是出了什么问题，上下文就这么被一遍遍重烧了？
最憋屈的是，这种问题你很难只靠用量页找答案。要不是装了这个插件，我甚至不知道该从哪儿开始吐槽。
一个会话样本不够，模型、上下文、任务和插件版本都会影响这个数，跨工具口径也别硬比。
可十来个点至少把问题钉住了：这次到底是哪段上下文、哪个模型或哪次工具调用，把账推高了？现有字段未必能逐项判因，但产品总该让用户有地方追。我平时其他 Agent 工作流里的缓存命中率往往更高，90% 都算是下限了——当然这个只是体感，不是行业基准。
我觉得 TRAE 真正该补的，不是再补一篇告诉大家“升级后更合理”的稿子，而是一份能让人自己核对的 Token 消耗明细。
不必把 prompt、代码或内部实现全摊出来。最好是在执行前给一个区间预估或风险提示；结束后讲清模型、输入输出 Token、缓存、工具调用、最终扣分，以及估算和最终结算的差异，就够有用了。
用户发现是自己塞了几万字上下文，下次会收敛；要是数据暴露出产品问题，产研也没法只靠一句“正常消耗”把事翻过去。
我常用 Codex、Claude Code（CC）、OpenCode 后养成了一个习惯：能看到用量，就自己分析，别只看余额。它们不必放在一张“谁最开放”的榜单里，但至少我这样的重度用户，预期已经被抬起来了——花钱可以，账得让我看。
真正强的产品，不怕用户拿数据来问问题。数据好，产品更有底气；数据不好，至少知道该往哪儿改。关键的消耗细节如果一直不摊开，只靠一轮轮解释稿去说升级有多合理，只会让每一次扣分都变成下一次吐槽的开场。
TRAE = The Real AI Engineer，名字即初心。希望产研的同学别被每天细碎的需求牵着走，也别沉醉在一篇篇公关稿堆出来的掌声里；更希望这个产品，真能撑得起这个名字背后的野心和期待。
所以这篇不是喊着让 TRAE 别收钱。恰恰相反：既然你要按 Token 认真算账，就请把账认真给用户看。
如果只能先补一个字段，你最想看的是 Token、缓存、工具调用，还是任务级 Token 消耗明细？
按次数来计量和按token来计量两者的优化思路差太多了，不要只是发出给用户的建议一二三条。你们要全面跟竞品对照一下同一任务的积分差多少……
率该优化一下
