1. 1.73 亿 token 这个数字先拆开看它到底意味着什么先把结论摆在前面1.73 亿 token 听起来像个天文数字但真正决定账单的从来不是这个总量而是输入、输出、缓存命中三者的比例。我见过太多人拿着一个总 token 数去乘单价算出来的数字能差出十倍问题就出在没拆结构。WorkBuddy 这类工具在 9 月烧掉 1.73 亿 token这个量级放在个人开发者身上算是重度使用放在小团队里属于正常偏上。要算清楚它按官方价到底多少钱得先搞清楚三件事这些 token 是输入还是输出、有多少走了缓存、用的哪个模型档位。1.1 输入和输出的价差是账单里最大的变量大模型 API 的计费逻辑里输入input和输出output是两个完全不同的价格。以主流厂商的定价习惯来看输出单价通常是输入的 3 到 4 倍部分推理型模型甚至能到 8 倍以上。这意味着同样 1 亿 token全是输入和全是输出账单能差出好几倍。WorkBuddy 作为一个偏 Agent 形态的助手工具它的 token 消耗结构和普通聊天完全不一样。普通对话是一问一答输入输出比大概 1:1 到 2:1。但 Agent 类工具会反复把上下文、工具定义、历史记录、文件内容塞进 prompt输入侧会被严重放大。我实测过类似的 Agent 工作流输入输出比经常能到 8:1 甚至 15:1。所以 1.73 亿 token 里如果按 10:1 的输入输出比来估大概是 1.57 亿输入 0.16 亿输出。这个结构直接决定了后面所有计算。1.2 缓存命中率是能把账单砍半的隐藏开关这是最容易被忽略、但省钱效果最猛的一项。主流 API 都支持prompt caching提示缓存命中缓存的输入 token 单价通常只有正常输入价的 10% 到 25%。WorkBuddy 这种工具因为系统提示词、工具定义、项目上下文高度重复缓存命中率天然就高。我拿一个真实场景举例一个固定的系统提示词加工具定义大概 8000 token如果每轮对话都重新计费跑 1000 轮就是 800 万 token 全价。但如果缓存命中这 800 万里有 700 多万按缓存价算成本直接掉到原来的两成左右。所以算账的时候必须把输入 token 拆成缓存命中和缓存未命中两部分否则算出来的数字会严重偏高。1.3 模型档位决定了单价的天花板WorkBuddy 支持切换模型不同模型的单价差距非常大。旗舰模型和轻量模型的输入价差能有 10 倍以上。1.73 亿 token 如果全跑旗舰模型和全跑轻量模型账单完全不是一个量级。现实情况通常是混合的复杂任务走旗舰简单任务走轻量。所以下面我会给出几档不同模型组合下的估算你可以对照自己的实际使用情况去套。2. 按官方价把 1.73 亿 token 拆成一张账单这一节直接上计算。为了让结果有参考价值我用当前主流 API 的典型定价区间来建模单位统一按每百万 token 美元来算最后再折算。注意具体单价会随厂商调整这里用的是常见档位重点是计算方法和结构你把自己的实际单价代进去就行。2.1 先设定三档模型和对应单价我按常见的三档来设档位输入价每百万 token输出价每百万 token缓存命中输入价旗舰模型3 美元15 美元0.3 美元中端模型1 美元4 美元0.1 美元轻量模型0.15 美元0.6 美元0.015 美元这三档基本覆盖了市面上主流的选择。旗舰对应最强推理能力中端是性价比主力轻量用于高频简单任务。2.2 假设一个合理的 token 结构基于 Agent 类工具的典型特征我设定这样一组比例总 token173,000,000输入占比90%即 155,700,000输出占比10%即 17,300,000输入中缓存命中率60%即 93,420,000 走缓存价输入中缓存未命中62,280,000 走全价这个 60% 的缓存命中率对 WorkBuddy 这种工具有点保守实际可能到 70% 以上。但保守估计更稳妥。2.3 三档模型下的账单对比全走旗舰模型缓存命中输入93.42 × 0.3 28.03 美元未命中输入62.28 × 3 186.84 美元输出17.3 × 15 259.5 美元合计约 474.37 美元全走中端模型缓存命中输入93.42 × 0.1 9.34 美元未命中输入62.28 × 1 62.28 美元输出17.3 × 4 69.2 美元合计约 140.82 美元全走轻量模型缓存命中输入93.42 × 0.015 1.40 美元未命中输入62.28 × 0.15 9.34 美元输出17.3 × 0.6 10.38 美元合计约 21.12 美元看到差距了吗同样的 1.73 亿 token全旗舰接近 475 美元全轻量只要 21 美元差了 22 倍。这就是为什么1.73 亿 token 要花多少钱这个问题脱离模型档位根本没法回答。2.4 混合使用的真实账单估算现实中 WorkBuddy 用户大概率是混合的。我按一个常见的 2:5:3 比例来分旗舰 20%、中端 50%、轻量 30%旗舰部分474.37 × 0.2 94.87 美元中端部分140.82 × 0.5 70.41 美元轻量部分21.12 × 0.3 6.34 美元合计约 171.62 美元按这个结构1.73 亿 token 的月账单大概在170 美元上下折合人民币一千出头。这个数字对重度个人用户来说不算离谱对团队来说更是可控。注意如果你的缓存命中率只有 30%同样结构下账单会涨到 250 美元以上。缓存命中率每降 10 个百分点账单大概涨 15% 到 20%。这是最值得优化的一个指标。3. 缓存命中率为什么能决定一半账单以及怎么把它拉上去上一节算完账你会发现缓存命中率是那个看不见的手。这一节专门讲清楚它的原理和实操优化方法因为这是 WorkBuddy 用户最该掌握的一项省钱技能。3.1 缓存到底缓存了什么大模型的 prompt caching 机制本质是把前缀相同的部分缓存起来。当你连续多次请求时如果开头一大段内容完全一致服务端就不需要重新计算这部分的注意力直接复用之前的计算结果因此给你打折。关键点在于前缀相同。缓存是从 prompt 的最开头往后匹配的一旦中间有一处不同后面的全部失效。这就像你寄快递地址前几行一样可以走同一个分拣通道但只要有一个字不同就得重新分拣。WorkBuddy 这类工具天然适合缓存因为它的 prompt 结构通常是系统提示词固定工具定义固定项目上下文半固定对话历史变化当前用户输入变化前 1、2 项完全固定第 3 项在同一个项目里也基本不变。这三块加起来往往能占到单次请求输入 token 的 50% 到 70%。只要它们稳定不变缓存命中率就能维持在高位。3.2 哪些操作会悄悄打掉你的缓存我踩过的坑里最常见的缓存杀手有这么几个系统提示词里带了时间戳或随机 ID。有些工具会在系统提示里插入当前时间导致每次请求前缀都不同缓存全废。这是最隐蔽也最致命的。工具定义顺序不稳定。如果工具列表每次序列化的顺序不一样前缀就变了缓存失效。项目上下文频繁重排。比如每次把文件按修改时间重新排序塞进去前缀就乱了。中途切换模型。不同模型的缓存不互通切一次模型之前的缓存全部作废。提示如果你发现账单比预期高很多第一件事就是去查系统提示词里有没有动态内容。把时间戳、随机数、会话 ID 这类东西挪到 prompt 的末尾缓存命中率能立刻回升。3.3 把缓存命中率从 40% 拉到 75% 的具体做法我实测有效的一套组合拳固定前缀动态后置。把所有不变的内容系统提示、工具定义、项目说明放在最前面把变化的用户输入、时间、临时数据放到最后。这是缓存生效的前提。工具定义做稳定排序。按字母序或固定 ID 序排列别用哈希序或随机序。项目上下文做增量更新。不要每次全量重塞只把变化的部分追加到末尾前面的保持不动。控制模型切换频率。同一个会话尽量用同一个模型需要切换时新开会话。合理设置缓存 TTL。主流缓存有存活时间太短会频繁失效太长会占用配额。一般 5 到 10 分钟对连续工作流够用。按这套做法缓存命中率从 40% 提到 75% 是现实的。回到上一节的账单同样 1.73 亿 token命中率从 60% 提到 75%中端模型下能再省 20 美元左右旗舰模型下能省 60 美元以上。4. 除了缓存还有哪些地方在偷偷吃你的 token算完账、优化完缓存还有几个 token 黑洞值得单独拎出来说。这些是我在实际使用 WorkBuddy 过程中观察到的、常规文档里不会写的消耗点。4.1 上下文膨胀Agent 工具最大的隐形开销普通聊天是一问一答上下文线性增长。但 Agent 工具会把每一轮的工具调用结果都塞回上下文。一次文件读取可能返回几千 token一次搜索可能返回上万 token这些都会累积到后续每一轮请求里。我做过一个测试一个 20 轮的任务如果每轮都带上完整历史到第 20 轮时单次请求的输入可能已经膨胀到 5 万 token 以上。而如果做了上下文压缩或滑动窗口能控制在 1 万以内。这中间的差距乘以轮数就是几百万 token 的差别。应对方法有几个开启上下文压缩。让工具自动总结早期历史只保留关键信息。用滑动窗口。只保留最近 N 轮完整对话更早的做摘要。及时清理工具返回的大块内容。文件读完了内容用完后可以从上下文里移除。4.2 重试和失败请求也在计费这一点很多人不知道失败的请求如果已经产生了 token 计算有些情况也是要计费的。尤其是输出被截断、超时、格式错误导致重试的场景token 是实打实消耗掉的。WorkBuddy 在跑复杂任务时工具调用失败、模型输出格式不对、需要重新生成的情况并不少见。如果重试率有 10%那 1.73 亿里就有 1700 万是白烧的。降低重试率的做法给工具调用加严格的参数校验别让模型瞎猜格式。输出用结构化格式JSON schema约束减少解析失败。设置合理的超时别让请求卡死重试。4.3 不同任务的 token 效率差异巨大同样是让 WorkBuddy 干活不同任务的 token 效率能差好几倍。我总结了几类任务类型典型 token 消耗效率评价简单问答低高几乎不浪费代码生成中中输出占比较高多轮 Agent 任务高低上下文膨胀严重长文档处理极高低输入巨大批量重复任务中高中缓存能救批量重复任务如果缓存做得好效率其实不差。真正烧钱的是长文档处理和多轮 Agent这两类任务要特别关注上下文管理。5. 把账单压下来的完整实操清单前面讲了原理和结构这一节给一份可以直接照着做的清单。我按投入产出比从高到低排你先做前面的效果最明显。5.1 第一优先级缓存优化省 30% 到 50%检查系统提示词移除所有动态内容时间戳、随机 ID、会话标识。工具定义固定排序序列化结果保持稳定。项目上下文增量更新不重排、不全量重塞。同一会话不频繁切模型。监控缓存命中率目标 70% 以上。这一项做完账单基本能砍掉三分之一。而且它不需要改业务逻辑纯配置层面的事。5.2 第二优先级上下文管理省 15% 到 30%开启自动上下文压缩。设置滑动窗口保留最近 10 到 15 轮。工具返回的大块内容用完即清。长文档先切分再处理别整篇塞。上下文管理是 Agent 工具省钱的核心。我见过一个案例光是把上下文从全量保留改成滑动窗口 摘要月账单从 400 多美元降到 200 出头。5.3 第三优先级模型分级省 20% 到 40%简单任务走轻量模型复杂任务才上旗舰。用路由规则自动分流别全靠手动切。定期 review 哪些任务其实不需要旗舰模型。模型分级的关键是别用大炮打蚊子。很多日常任务轻量模型完全够用效果差异用户根本感知不到但成本差 10 倍以上。5.4 第四优先级减少无效消耗省 5% 到 15%加严工具调用的参数校验降低重试率。输出用结构化约束减少解析失败。设置合理超时避免卡死重试。定期看日志找出高频失败的任务类型。这一项省得相对少但它是止损能防止账单因为异常情况突然飙升。6. 回到那个问题1.73 亿 token 到底该花多少钱把前面所有分析收拢一下。1.73 亿 token 按官方价的合理区间是全旗舰、低缓存500 美元以上混合模型、中等缓存150 到 200 美元优化到位、高缓存、模型分级80 到 120 美元全轻量、高缓存20 到 30 美元所以到底要花多少钱这个问题答案不是一个数字而是一个区间取决于你的使用结构。WorkBuddy 这种工具如果配置得当1.73 亿 token 的月成本控制在 100 到 150 美元是完全现实的。如果放任不管冲到 400 美元以上也不奇怪。我个人在实际操作中的体会是先别急着换便宜模型先把缓存和上下文这两件事做好。这两项是纯工程优化不影响输出质量但省钱效果最直接。等这两项做到位了再考虑模型分级那才是锦上添花。很多人一上来就想着换轻量模型省钱结果任务质量下降、重试率上升最后算下来反而没省多少还把体验搞差了。最后分享一个小技巧每周花十分钟看一下 token 消耗的分布按任务类型和模型档位拉个表。你会发现往往 20% 的任务类型吃掉了 80% 的 token。把这 20% 优化好比全面铺开改要高效得多。
1.73亿token账单拆解：缓存命中率与模型分级如何决定大模型API成本
1. 1.73 亿 token 这个数字先拆开看它到底意味着什么先把结论摆在前面1.73 亿 token 听起来像个天文数字但真正决定账单的从来不是这个总量而是输入、输出、缓存命中三者的比例。我见过太多人拿着一个总 token 数去乘单价算出来的数字能差出十倍问题就出在没拆结构。WorkBuddy 这类工具在 9 月烧掉 1.73 亿 token这个量级放在个人开发者身上算是重度使用放在小团队里属于正常偏上。要算清楚它按官方价到底多少钱得先搞清楚三件事这些 token 是输入还是输出、有多少走了缓存、用的哪个模型档位。1.1 输入和输出的价差是账单里最大的变量大模型 API 的计费逻辑里输入input和输出output是两个完全不同的价格。以主流厂商的定价习惯来看输出单价通常是输入的 3 到 4 倍部分推理型模型甚至能到 8 倍以上。这意味着同样 1 亿 token全是输入和全是输出账单能差出好几倍。WorkBuddy 作为一个偏 Agent 形态的助手工具它的 token 消耗结构和普通聊天完全不一样。普通对话是一问一答输入输出比大概 1:1 到 2:1。但 Agent 类工具会反复把上下文、工具定义、历史记录、文件内容塞进 prompt输入侧会被严重放大。我实测过类似的 Agent 工作流输入输出比经常能到 8:1 甚至 15:1。所以 1.73 亿 token 里如果按 10:1 的输入输出比来估大概是 1.57 亿输入 0.16 亿输出。这个结构直接决定了后面所有计算。1.2 缓存命中率是能把账单砍半的隐藏开关这是最容易被忽略、但省钱效果最猛的一项。主流 API 都支持prompt caching提示缓存命中缓存的输入 token 单价通常只有正常输入价的 10% 到 25%。WorkBuddy 这种工具因为系统提示词、工具定义、项目上下文高度重复缓存命中率天然就高。我拿一个真实场景举例一个固定的系统提示词加工具定义大概 8000 token如果每轮对话都重新计费跑 1000 轮就是 800 万 token 全价。但如果缓存命中这 800 万里有 700 多万按缓存价算成本直接掉到原来的两成左右。所以算账的时候必须把输入 token 拆成缓存命中和缓存未命中两部分否则算出来的数字会严重偏高。1.3 模型档位决定了单价的天花板WorkBuddy 支持切换模型不同模型的单价差距非常大。旗舰模型和轻量模型的输入价差能有 10 倍以上。1.73 亿 token 如果全跑旗舰模型和全跑轻量模型账单完全不是一个量级。现实情况通常是混合的复杂任务走旗舰简单任务走轻量。所以下面我会给出几档不同模型组合下的估算你可以对照自己的实际使用情况去套。2. 按官方价把 1.73 亿 token 拆成一张账单这一节直接上计算。为了让结果有参考价值我用当前主流 API 的典型定价区间来建模单位统一按每百万 token 美元来算最后再折算。注意具体单价会随厂商调整这里用的是常见档位重点是计算方法和结构你把自己的实际单价代进去就行。2.1 先设定三档模型和对应单价我按常见的三档来设档位输入价每百万 token输出价每百万 token缓存命中输入价旗舰模型3 美元15 美元0.3 美元中端模型1 美元4 美元0.1 美元轻量模型0.15 美元0.6 美元0.015 美元这三档基本覆盖了市面上主流的选择。旗舰对应最强推理能力中端是性价比主力轻量用于高频简单任务。2.2 假设一个合理的 token 结构基于 Agent 类工具的典型特征我设定这样一组比例总 token173,000,000输入占比90%即 155,700,000输出占比10%即 17,300,000输入中缓存命中率60%即 93,420,000 走缓存价输入中缓存未命中62,280,000 走全价这个 60% 的缓存命中率对 WorkBuddy 这种工具有点保守实际可能到 70% 以上。但保守估计更稳妥。2.3 三档模型下的账单对比全走旗舰模型缓存命中输入93.42 × 0.3 28.03 美元未命中输入62.28 × 3 186.84 美元输出17.3 × 15 259.5 美元合计约 474.37 美元全走中端模型缓存命中输入93.42 × 0.1 9.34 美元未命中输入62.28 × 1 62.28 美元输出17.3 × 4 69.2 美元合计约 140.82 美元全走轻量模型缓存命中输入93.42 × 0.015 1.40 美元未命中输入62.28 × 0.15 9.34 美元输出17.3 × 0.6 10.38 美元合计约 21.12 美元看到差距了吗同样的 1.73 亿 token全旗舰接近 475 美元全轻量只要 21 美元差了 22 倍。这就是为什么1.73 亿 token 要花多少钱这个问题脱离模型档位根本没法回答。2.4 混合使用的真实账单估算现实中 WorkBuddy 用户大概率是混合的。我按一个常见的 2:5:3 比例来分旗舰 20%、中端 50%、轻量 30%旗舰部分474.37 × 0.2 94.87 美元中端部分140.82 × 0.5 70.41 美元轻量部分21.12 × 0.3 6.34 美元合计约 171.62 美元按这个结构1.73 亿 token 的月账单大概在170 美元上下折合人民币一千出头。这个数字对重度个人用户来说不算离谱对团队来说更是可控。注意如果你的缓存命中率只有 30%同样结构下账单会涨到 250 美元以上。缓存命中率每降 10 个百分点账单大概涨 15% 到 20%。这是最值得优化的一个指标。3. 缓存命中率为什么能决定一半账单以及怎么把它拉上去上一节算完账你会发现缓存命中率是那个看不见的手。这一节专门讲清楚它的原理和实操优化方法因为这是 WorkBuddy 用户最该掌握的一项省钱技能。3.1 缓存到底缓存了什么大模型的 prompt caching 机制本质是把前缀相同的部分缓存起来。当你连续多次请求时如果开头一大段内容完全一致服务端就不需要重新计算这部分的注意力直接复用之前的计算结果因此给你打折。关键点在于前缀相同。缓存是从 prompt 的最开头往后匹配的一旦中间有一处不同后面的全部失效。这就像你寄快递地址前几行一样可以走同一个分拣通道但只要有一个字不同就得重新分拣。WorkBuddy 这类工具天然适合缓存因为它的 prompt 结构通常是系统提示词固定工具定义固定项目上下文半固定对话历史变化当前用户输入变化前 1、2 项完全固定第 3 项在同一个项目里也基本不变。这三块加起来往往能占到单次请求输入 token 的 50% 到 70%。只要它们稳定不变缓存命中率就能维持在高位。3.2 哪些操作会悄悄打掉你的缓存我踩过的坑里最常见的缓存杀手有这么几个系统提示词里带了时间戳或随机 ID。有些工具会在系统提示里插入当前时间导致每次请求前缀都不同缓存全废。这是最隐蔽也最致命的。工具定义顺序不稳定。如果工具列表每次序列化的顺序不一样前缀就变了缓存失效。项目上下文频繁重排。比如每次把文件按修改时间重新排序塞进去前缀就乱了。中途切换模型。不同模型的缓存不互通切一次模型之前的缓存全部作废。提示如果你发现账单比预期高很多第一件事就是去查系统提示词里有没有动态内容。把时间戳、随机数、会话 ID 这类东西挪到 prompt 的末尾缓存命中率能立刻回升。3.3 把缓存命中率从 40% 拉到 75% 的具体做法我实测有效的一套组合拳固定前缀动态后置。把所有不变的内容系统提示、工具定义、项目说明放在最前面把变化的用户输入、时间、临时数据放到最后。这是缓存生效的前提。工具定义做稳定排序。按字母序或固定 ID 序排列别用哈希序或随机序。项目上下文做增量更新。不要每次全量重塞只把变化的部分追加到末尾前面的保持不动。控制模型切换频率。同一个会话尽量用同一个模型需要切换时新开会话。合理设置缓存 TTL。主流缓存有存活时间太短会频繁失效太长会占用配额。一般 5 到 10 分钟对连续工作流够用。按这套做法缓存命中率从 40% 提到 75% 是现实的。回到上一节的账单同样 1.73 亿 token命中率从 60% 提到 75%中端模型下能再省 20 美元左右旗舰模型下能省 60 美元以上。4. 除了缓存还有哪些地方在偷偷吃你的 token算完账、优化完缓存还有几个 token 黑洞值得单独拎出来说。这些是我在实际使用 WorkBuddy 过程中观察到的、常规文档里不会写的消耗点。4.1 上下文膨胀Agent 工具最大的隐形开销普通聊天是一问一答上下文线性增长。但 Agent 工具会把每一轮的工具调用结果都塞回上下文。一次文件读取可能返回几千 token一次搜索可能返回上万 token这些都会累积到后续每一轮请求里。我做过一个测试一个 20 轮的任务如果每轮都带上完整历史到第 20 轮时单次请求的输入可能已经膨胀到 5 万 token 以上。而如果做了上下文压缩或滑动窗口能控制在 1 万以内。这中间的差距乘以轮数就是几百万 token 的差别。应对方法有几个开启上下文压缩。让工具自动总结早期历史只保留关键信息。用滑动窗口。只保留最近 N 轮完整对话更早的做摘要。及时清理工具返回的大块内容。文件读完了内容用完后可以从上下文里移除。4.2 重试和失败请求也在计费这一点很多人不知道失败的请求如果已经产生了 token 计算有些情况也是要计费的。尤其是输出被截断、超时、格式错误导致重试的场景token 是实打实消耗掉的。WorkBuddy 在跑复杂任务时工具调用失败、模型输出格式不对、需要重新生成的情况并不少见。如果重试率有 10%那 1.73 亿里就有 1700 万是白烧的。降低重试率的做法给工具调用加严格的参数校验别让模型瞎猜格式。输出用结构化格式JSON schema约束减少解析失败。设置合理的超时别让请求卡死重试。4.3 不同任务的 token 效率差异巨大同样是让 WorkBuddy 干活不同任务的 token 效率能差好几倍。我总结了几类任务类型典型 token 消耗效率评价简单问答低高几乎不浪费代码生成中中输出占比较高多轮 Agent 任务高低上下文膨胀严重长文档处理极高低输入巨大批量重复任务中高中缓存能救批量重复任务如果缓存做得好效率其实不差。真正烧钱的是长文档处理和多轮 Agent这两类任务要特别关注上下文管理。5. 把账单压下来的完整实操清单前面讲了原理和结构这一节给一份可以直接照着做的清单。我按投入产出比从高到低排你先做前面的效果最明显。5.1 第一优先级缓存优化省 30% 到 50%检查系统提示词移除所有动态内容时间戳、随机 ID、会话标识。工具定义固定排序序列化结果保持稳定。项目上下文增量更新不重排、不全量重塞。同一会话不频繁切模型。监控缓存命中率目标 70% 以上。这一项做完账单基本能砍掉三分之一。而且它不需要改业务逻辑纯配置层面的事。5.2 第二优先级上下文管理省 15% 到 30%开启自动上下文压缩。设置滑动窗口保留最近 10 到 15 轮。工具返回的大块内容用完即清。长文档先切分再处理别整篇塞。上下文管理是 Agent 工具省钱的核心。我见过一个案例光是把上下文从全量保留改成滑动窗口 摘要月账单从 400 多美元降到 200 出头。5.3 第三优先级模型分级省 20% 到 40%简单任务走轻量模型复杂任务才上旗舰。用路由规则自动分流别全靠手动切。定期 review 哪些任务其实不需要旗舰模型。模型分级的关键是别用大炮打蚊子。很多日常任务轻量模型完全够用效果差异用户根本感知不到但成本差 10 倍以上。5.4 第四优先级减少无效消耗省 5% 到 15%加严工具调用的参数校验降低重试率。输出用结构化约束减少解析失败。设置合理超时避免卡死重试。定期看日志找出高频失败的任务类型。这一项省得相对少但它是止损能防止账单因为异常情况突然飙升。6. 回到那个问题1.73 亿 token 到底该花多少钱把前面所有分析收拢一下。1.73 亿 token 按官方价的合理区间是全旗舰、低缓存500 美元以上混合模型、中等缓存150 到 200 美元优化到位、高缓存、模型分级80 到 120 美元全轻量、高缓存20 到 30 美元所以到底要花多少钱这个问题答案不是一个数字而是一个区间取决于你的使用结构。WorkBuddy 这种工具如果配置得当1.73 亿 token 的月成本控制在 100 到 150 美元是完全现实的。如果放任不管冲到 400 美元以上也不奇怪。我个人在实际操作中的体会是先别急着换便宜模型先把缓存和上下文这两件事做好。这两项是纯工程优化不影响输出质量但省钱效果最直接。等这两项做到位了再考虑模型分级那才是锦上添花。很多人一上来就想着换轻量模型省钱结果任务质量下降、重试率上升最后算下来反而没省多少还把体验搞差了。最后分享一个小技巧每周花十分钟看一下 token 消耗的分布按任务类型和模型档位拉个表。你会发现往往 20% 的任务类型吃掉了 80% 的 token。把这 20% 优化好比全面铺开改要高效得多。