7 月 16 日，月之暗面发了 Kimi K3。
那两天朋友圈和群里都在转。说跑分全球第四，说前端代码 Arena 第一，说 SWE Marathon 比 Fable 5 还高，说有人提前测过，体感是「Fable 级」的。
我没有第一时间试。我对这种发布周的氛围一贯保持一点警惕，觉得至少等尘埃落定，等几篇靠谱的独立评测出来，再做判断也不迟。
但有一件事按不住——我一直在做自己的 Web Claude Code Pilot，支持把不同家的模型接进同一套工作流里。这种时候，有一个评测数据这么好、又开放 API 的新模型不接进来试试，感觉说不过去。
于是还是接了。
接进来以后，我开始真的用它干活——生成 PPT，在项目里改文件，日常的工作流。用了一段时间，发现额度消耗明显比预期快。
去数据库里查，全是零
首先想到的是缓存出问题了。
我的工具支持多家 provider，Claude 的表现我很熟——它的 prompt cache 在连续对话里省得非常明显，只要会话不断，后续每轮的成本会低很多。如果 K3 的缓存没工作，每一轮都在付全价，这个消耗速度是说得通的。
去数据库里查了一下。Claude 的记录都在，cache_read 几百万，清清楚楚。K3 的那几条记录：input 零，output 零，cache 零，cost 空。
不是缓存不够好，是数据库里根本没有这个模型的用量记录。
原因后来查清楚了：K3 走的是 OpenAI 兼容的端点，返回 OpenAI 格式的 usage 结构，但我的 Web Claude Code Pilot 是围着 Claude 的 API 格式写的，解析逻辑对不上，全部存成零。不是 K3 没在计费，是我这边读不出来。用了多少，花了多少，完全看不见。
仪表板是瞎的。只能换个方式，重新建一个干净的会话，发一句最简单的消息，直接盯着原始数据看。
一句 hi，38,546 个 token
我发了「hi」，两个字母。
然后盯着数据库看这一条消息记录了什么。
input tokens：38,546。
我以为自己读错了，又看了一遍。38,546。
我打了两个字母，模型回了八十几个 token，但这条消息实际发出去的是 38,546 个 token。
这 38,000 多个 token 是哪里来的？是 Claude Code harness 每一轮必带的固定前缀——所有内置工具的 schema，系统提示，CLAUDE.md，164 个技能的目录，MCP 工具定义，memory，git 状态，等等，全部打包进每一条消息里。
把这包东西拆开看：
| 组成 | token | 占比 |
|---|---|---|
| 技能目录（164 个技能） | ~14.5k | 38% |
| 内置工具 schema + 系统提示 | ~10k | 26% |
| MCP 工具 schema | ~7k | 18% |
| memory + 附加片段 + git 信息 | ~5.6k | 14% |
| CLAUDE.md | ~1.4k | 4% |
用 Claude 的时候，这包东西我从来没有意识到它的存在——缓存把它吃掉了，第二轮开始前缀就全部命中 cache_read，只计很低的缓存命中价。成本安静地藏在背后，从不露面。
但和 K3 一起使用的方式暴露了问题。我做完一件事就关掉会话，下次再打开是一个全新的会话——每次都是冷启动，38k 的前缀要全价重新付一遍。第二条消息确认了缓存本身是好的：input 只有 252 个 token，成本降了将近 9 倍。但新建会话意味着每次都放弃已建立的缓存，从头付起。
额度就是这么消耗的。
还有一件事在背后烧钱
38k 前缀解释了冷启动的成本，但我在排查过程中还发现了另一个问题。
我的工具对不认识的第三方模型，默认不发 effort 参数——代码里对 K3 没有配置，就什么都不传。而 K3 的端点在没有 effort 参数时，默认跑 max reasoning。Simon Willison 测 K3 时记录到一次对话里有 13,241 个推理 token，就是这个原因，他也没指定 effort，端点替他选了 max。
我用 K3 做真实工作的每一轮对话，都在用最贵的那档推理。自己不知道。
把这些东西修掉
问题清楚了，挨个修。
用量看不见：加了本地估算兜底，K3 回来的 usage 全是零时，按字符数估（CJK 约 1 token 每字，其他约 4 字符每 token），界面显示 ≈N tokens 并打 est. 标签，提示真实额度以 provider 后台为准。从完全瞎变成近视。
前缀太重：给第三方 provider 加了 context_profile，可以逐个排除不需要的插件和 MCP 服务器。给 Kimi 配置里砍掉了 huggingface-skills、vercel、playwright——这几块在技能目录里占了不少位置，但用 K3 的时候根本用不上。
静默 max effort：给 provider 加了 effort_config，K3 预设 {low, high, max}，默认 high，不再由端点偷偷决定。模型按钮上现在显示 k3·Hi，可以手动切换。
所有改动只在第三方 provider 的路径里，Claude 和 Codex 那边一行没动。
回头看 K3 这个模型
折腾完这一圈，我对 K3 本身的判断是什么。
发布那两天，网上出了不少第三方评测数据——全球排名第四、Arena 前端代码第一、SWE Marathon 42 分之类。我没有系统测过，不做背书，只能说早期方向上看起来不差。月之暗面自己也放出了一堆 benchmark，拿芯片设计当 demo，声势做得很大。等 7 月 27 日完整权重真的出来、独立机构跑完完整测试，再说话会更准。
但不管跑分最后落在哪里，「接进真实 harness」和「跑 benchmark」是两件差得很远的事。
Benchmark 环境是干净的。prompt 是精心控制的，前缀是可控的，用量是精确回报的。而你把它接进一个实际运行的 agent harness，第一轮对话的前缀可能就是 38k token，缓存策略决定成本能差 9 倍，端点的一个默认值决定每轮多烧多少推理 token——这些维度，跑分报告里一个都不会写。
K3 目前的状态是：模型能力到位，工程细节还差一层。不回报 usage，reasoning 只有一档，缓存透明度低。这不是说它不能用，而是说你接进来的时候，需要自己给它配仪表盘、配护栏、配上下文过滤，这些活 benchmark 不会替你做。
月之暗面这次把定价拉到了国际一线的档位，$15 每百万输出，和 Sonnet 档同级，姿态很明确。一线的定价也意味着开发者会用一线的标准衡量它，包括 API 的工程成熟度，不只是模型的推理能力。
写在最后
这件事里我最意外的发现，不是 K3 本身，而是那张前缀拆解表。
38,546 个 token 里有 164 个技能的目录，有七八个 MCP 工具的完整 schema，有内置工具的全部定义。这些东西是我自己装上去的，用 Claude 的时候它们消无声息地藏在缓存里，我从来没有认真想过它有多大。直到换了一个新模型，才第一次把这包东西抖开来看清楚。
你以为你在跟一个模型说话，你其实在每一次对话里都随身携带着一套非常重的家当。它不是坏事，只是你之前没意识到它在那里。
现在知道了，就好管一些。
Sources: Simon Willison on Kimi K3, Artificial Analysis, Tom's Hardware, WinBuzzer, TECHSY K3 Review.