github copilot token 计费

很多人用 Copilot 时有个误区：以为订阅之后就是「无限补全」，直到某个月发现账单一跳，才回头找计费规则。问题通常不在模型贵，而在于你没分清哪些操作走订阅额度、哪些走 API 按量计费，以及一轮任务里 token 到底被谁吃掉了。这篇把口径、排查顺序和可控动作列一遍，具体数字去站内对应页面核对。

很多人用 Copilot 时有个误区：以为订阅之后就是「无限补全」，直到某个月发现账单一跳，才回头找计费规则。问题通常不在模型贵，而在于你没分清哪些操作走订阅额度、哪些走 API 按量计费，以及一轮任务里 token 到底被谁吃掉了。

这篇不讲虚的，只给判断口径、排查顺序和能马上做的动作。具体数字（单价、额度、档位）一律去站内对应页面核对当时的说明，别记死数、别拿别人截图当依据。

先分清你走的是哪条计费口径

Copilot 的收费口子至少有两类：一类是订阅制的额度消耗，另一类是拿 key 直连接口、按 token 实际结算。这两类混在一起谈「贵不贵」，一定吵不清，因为同一段代码在两种口径下的结论可能完全相反。

订阅制口径

在插件里用补全、对话、智能体等功能，消耗的是套餐额度，超额后按该套餐规则处理

按量 API 口径

自己拿 key 直连接口，按输入与输出 token 逐次结算，进的是 API 账单

判断入口

看你的调用是从编辑器插件发出，还是从脚本/客户端直接打接口，前者归订阅，后者归 API

• 先定位口径再比价，否则你比的是两件不同的事；
• 同一个模型在两种口径下单价口径可能不同，别直接乘系数估算；
• 如果账单里同时有两类费用，先拆开看各自占比，再决定优化哪一边；
• 不确定走哪条时，到 官方 API 价格 页面看清「接口调用」和「订阅套餐」是不是分开列的。

一轮任务里 token 到底花在哪

token 消耗分输入和输出两侧，输入侧通常才是大头。输入侧一般来自三块：你当前打开的上下文文件、被自动带上的周边文件、以及历史对话轮次。输出侧则是生成的代码和解释文字。

要注意的是，补全类请求虽然次数多，但单次体量小；真正把账单顶起来的往往是智能体或长对话那几次。所以别一上来就去砍补全，先看占比。

怎么查当期数字、怎么建立基线

想优化，先有基线。没有基线就优化，等于闭眼调参：你既不知道从哪降的，也不知道降了多少。建立基线的方法是拿一段时间的真实调用记录，按上面那三类分开统计。

1. 查额度口径到 编程套餐目录 看当前档位的额度说明，再到 GitHub Pro 里的额度能干什么 确认哪些操作算在额度内，别靠记忆。
2. 查单价口径走 API 的到 官方 API 价格 对照输入/输出 token 的计价方式，注意缓存命中与未命中的差别。
3. 换算成单任务成本用 Token 单价换算 把「每百万 token 单价」换成「一次任务大概多少钱」，这样才好比较不同做法。
4. 跑一周基线记录一周内三类调用的次数和大致 token 量，算出各自占比，作为后续对比的参照。

基线跑出来后，你会得到一个很实用的判断：如果某一类占了绝大多数，就只优化那一类；如果三类都不高，那大概率是档位选得不合适，而不是用法有问题。

把用量压下来的可执行动作

• 收窄上下文：只保留当前任务真正需要的文件，改完就关，大仓库用忽略规则把无关目录挡在外面；
• 拆任务：把「一次改十个文件」拆成几步，单次输入短、返工少，总 token 往往反而更低；
• 重开长会话：上下文已经跑偏或话题换了，直接新建会话比继续追加更省；
• 换档位而不是换工具：用量长期贴着上限，先对比上一档套餐的人均额度是否更划算，再考虑其他方案；
• 用量低就别升档：日均调用很少的阶段，升档只是多花钱，先把基线跑清楚更重要。

表格里的「不建议做的事」值得单独记一下：很多人遇到账单高，第一反应是换模型或加缓存，但如果问题出在口径选错或档位不对，这些动作基本无效。

这些做法什么时候不适用

上面这套思路主要针对个人或小团队的自用场景，下面几种情况要换个判断方式，别硬套。

• 团队共用场景：个人侧的省 token 技巧作用有限，成本大头在成员数和档位选择，要走团队方案页面看人均口径；
• 公司统一采购、走企业协议价：个人页面上看到的单价和实际结算价不是一回事，别拿个人页面数字去对账；
• 刚起步、日均调用很少：花时间做精细优化不划算，先把基线跑出来、把口径理清更重要；
• 只是偶尔用补全写几行代码：这类用量本身很小，优化空间有限，重点应该放在别误开按量 API。

省 token 的前提是知道 token 花在哪；不知道花在哪的时候，任何优化都只是碰运气。