copilot token 计费

很多人以为订阅了 Copilot 就与 token 无关，结果一接自带 API Key 或换到按量通道，账单口径全变了。这篇不背单价，只讲判断口径：哪种调用方式走 token、一轮编码任务的钱花在哪、怎么从用量记录倒推预算，以及发现超支时按什么顺序排查。

很多人以为订阅了 Copilot 就跟 token 没关系，结果一接自带 API Key，或者把请求挪到按量通道，账单口径立刻变了样。同一段补全代码，在订阅内只体现为额度占用，在按量通道里却是实打实的输入输出计量，两者根本不是一本账。

这篇不背单价，只讲判断口径：哪种调用方式走 token、一轮编码任务的钱花在哪、怎么从用量记录倒推预算，以及发现超支时按什么顺序排查。所有具体数字都以你当期的平台页面为准，别人截图里的数字套不到你头上。

先分清你用的是哪一种计费方式

计费方式决定了你要不要看 token。订阅档位内的额度、自带 API Key 的按量调用、走第三方中转，是三条完全不同的账。先确认自己在哪一条上，再决定要不要做用量监控，否则很容易把额度占用误当成账单金额去优化。

• 判断口径以当期页面为准，别拿别人截图里的数字套自己：到 /coding-plans 和 /official-api 核对当期规则
• 订阅内的消耗通常体现为额度占用，不等同于账单金额，混着看会得出错误结论
• 自带 API Key 的按量调用才逐条看 token，每个 Key 建议单独记账
• 走第三方中转时，先确认它是按请求数还是按 token 折算，再决定监控方式
• 不适用的情况：团队统一走企业合同或预付费包，账期与个人按量完全不是一回事

一轮编码任务里 token 到底花在哪

很多人只盯输出，实际输入侧往往更贵。常驻上下文（仓库结构、规则文件、历史对话）每轮都要重发一次，任务越复杂、会话越长，这部分越像滚雪球。想看清钱花在哪，先把一项任务拆成首次生成和后续修正两段分别记用量。

常驻上下文

仓库结构、规则文件、历史对话等每轮重复发送的内容

多轮改错

反复让模型自查、贴报错日志，输入随轮次线性增长

工具调用与文件读取

会把额外内容塞回上下文，算模型输入而不是工具本身

长会话不清空

历史记录持续累积，是隐形大头

1. 拆任务记用量把一项任务分成首次生成和后续修正两段，分别记录用量，看哪一段更重
2. 定位重发项检查哪些内容每轮都被重发，优先砍掉可复用的部分
3. 对比前后改完再跑一次同类任务，比较用量变化，确认动作确实有效

这套拆分法的价值在于把总额拆成可归因的两块。如果后续修正占了大头，说明问题不在模型选择，而在任务拆解和提示写法。不适用的情况是探索型任务，本来就没法提前拆清，这时用总量趋势看更合适。

把预算做出来并坚持核对

先定一个可接受的人均月度上限，再按任务类型分配，而不是月底看惊喜。阈值不是拍脑袋，参考上一周期的实际用量，再往上留一点缓冲。超过阈值就按既定顺序处理，别每次临时决定。

• 先定一个可接受的人均月度上限，再按任务类型分配，而不是月底看惊喜
• 记录字段至少含时间、任务名、调用方式、输入与输出用量、所属账号
• 每期对一次账：用量记录、平台账单、充值扣减三者能对上说明口径一致
• 对不上先查是不是混用了不同调用通道，再查有没有后台任务在跑
• 触发阈值就处理：先砍常驻上下文，再换小模型跑简单任务，最后才考虑降订阅档

预算的用处不是省钱，而是让超支可解释。如果每笔用量都能归到某个任务和某个人，超支就变成可讨论的问题，而不是一个需要猜的谜。至于具体的单价和额度数字，到 /price-watch 核对当时的数字即可。

发现超支时按这个顺序排查

超支时最容易犯的错是先换模型或换通道，顺序反了通常只是把问题挪个地方。正确的做法是从账目口径查起，再到运行行为，最后才动模型和通道。

1. 查口径混淆确认是不是把订阅额度和按量调用混在一个账号里跑，这是最常见的假超支
2. 查后台行为看有没有循环重试、自动补全、定时任务在后台长期跑
3. 查上下文膨胀看单次请求的上下文是否被历史记录撑大，长会话不清空是隐形大头
4. 最后才换模型或通道前面三步都排除后再考虑，否则问题会换个地方重现

这套排查顺序不适用于突发流量场景，比如临时上线一大批自动化任务。那种情况下先限流保稳定，再回头做归因，顺序反过来更合理。

先分清自己在哪条账上，再谈省 token；顺序错了，优化只是把问题挪个地方。