AI 编程工具的额度机制横评：时间窗口、credits、按量计费怎么分
数据截至 2026-07，价格与限额以各官网为准。
“额度用完了”这五个字，在不同 AI 编程工具里是三件完全不同的事：有的只是让你等窗口重置，有的是把你预付的钱扣完了，有的则是账单还在继续涨、只是你自己没盯着。搞不清自己用的工具属于哪一类，就谈不上任何有效的成本控制。
一个很常见的误解是：把所有工具的额度都理解成”手机流量套餐”——用完就停，下个月自动恢复。这个心智模型只在一部分工具上成立。有的工具压根不”停”，而是继续跑、继续记账，等你月底看到账单才知道花了多少；有的工具是”停”，但停得比你想象的更硬——不降级、不排队，直接把这个人拦在门外，一直拦到下个计费周期。这篇不比较哪家更便宜（价格随时在变，比了也没意义），只把计量机制本身讲清楚，因为机制不变的时间比价格长得多。
三类机制的本质区别在哪
抛开各家的营销包装，AI 编程工具收你钱的方式其实只有三种底层逻辑。
第一类：按时间窗口重置的配额。 你付一笔固定月费，得到的不是一个总量，而是”每个滚动时间窗口内可以用多少”。窗口一到就重新满血，不结转、也不透支。这类机制的特征是你没法用钱换更多——即便你愿意多付，在窗口内也只能等。好处是账单绝对可预测，坏处是遇到冲刺期会被硬卡住。具体窗口长度、重置口径各家不同，且调整频繁，以你所用工具官方文档的当前说明为准。
第二类：按预付信用点（credits）扣减。 你的订阅费里含一份信用点，每次调用按实际消耗折算成点数扣。它比时间窗口更”线性”——重活扣得多，轻活扣得少，不会出现”问了个简单问题也占一格配额”的浪费。但它引入了新的不确定性：同样的工作量，换个模型、换个上下文长度，扣的点数可能差出几倍。
第三类：纯按量计费。 没有包含额度这个概念，用多少算多少，按 token 单价实时结算。API 直连基本都属于这一类。它的特点是上不封顶，成本控制完全靠你自己设预算和监控。
判断自己手上的工具属于哪一类，最快的办法是问一个问题：“如果我今天疯狂用一整天，明天会发生什么？” 答案是”要等”，那是第一类；答案是”扣完就被拦住”，那是第二类；答案是”账单变长”，那是第三类。
credits 制到底怎么扣：以 Copilot 的 2026 变更为例
credits 制这几年被讲得最含糊，正好 GitHub Copilot 在 2026 年做了一次体制性变更，可以拿来当标准样本拆。
2026-06-01 起，全部 Copilot 计划转为按用量计费（usage-based billing），用 GitHub AI Credits 取代了原先的 premium requests 计数。这里有个换算关系值得记死：1 credit = 1 美分（$0.01）。用量按 token 消耗计算（输入、输出、缓存 token 都算），再按各模型的 API 费率折算成 credits。来源是 GitHub 官方博客与文档说明。
这个变更的意义比”改了个单位”大得多。原先的 premium request 是按次计数——一次请求扣一格，不管这次请求吞了多少上下文。改成 credits 之后变成按量计费：你塞进去的上下文越长、选的模型越贵，同一次交互扣的钱就越多。也就是说，从这一刻起，“我今天问了几次”不再是有效的用量指标，“我今天喂了多少上下文”才是。
各档订阅包含的额度，按第三方公开资料的汇总口径大致是这样（精确数字以 GitHub 官方计费页为准）：Pro 月费 $10、含 $15 credits；Pro+ 月费 $39、含 $70；Max 月费 $100、含 $200；Business $19/用户/月，约 1,900 credits/用户；Enterprise $39/用户/月，约 3,900 credits/用户。付费档的基础额度大致等于其价格，GitHub 另外还叠了一份浮动的 flex 额度，所以实际可用总量可能比表里更高。Business 和 Enterprise 走的是组织池化余额，不是按人锁死的。
一个短期但很要命的时效点：既有 Business / Enterprise 客户在按量计费开始的头三个月（2026-06-01 至 2026-09-01）享受更高的促销额度——Business 3,000 credits/用户、Enterprise 7,000。促销一结束就回落到标准的 1,900 / 3,900。这意味着团队现在看到的”用量很宽裕”是被促销垫高的假象。可操作的做法很直接：在 9 月之前去 Copilot 计费面板看”预测用量”那个数，它基本就是你 9 月起的真实账单量级，而不是现在这个舒服的数字。
额度用完那一刻，各家的处理方式不一样
这是最容易被忽略、却最影响实际体验的一环。
还是以 Copilot 的 credits 制为例，规则相当硬：管理员用美元预算控制超额部分，按 $0.01/credit 扣减（换算一下，$10 预算 = 1,000 credits）。预算可以设在四个层级——user、cost center、enterprise spending limit、organization。有两条细则必须提前知道：
- 把某个用户的预算设为 $0，会立即阻断这个用户。 这不是”提醒”，是硬拦截，配置错了就是有人第二天上不了班。
- 额度耗尽时没有自动降级到便宜模型的机制。 不允许超额就直接阻断到下个周期。很多人默认”用完了应该会自动切个小模型继续凑合用”，这个预期在这里不成立。
另外，未用完的额度不结转，每个自然月 1 号重置。所以月底剩一堆 credits 不是”省下来了”，是浪费了——反过来说，如果你的团队月底总有大量余量，那说明档位买高了。
对比之下，时间窗口制的处理方式温和得多：用完就等窗口重置，不产生任何额外账单，也不需要管理员干预。而纯按量计费的 API 则根本没有”用完”这个状态，只有”你设的预算上限被触发”或者”没设上限、账单继续涨”两种结局。三类机制里，只有第三类会让你在毫无感知的情况下花超，这也是为什么 API 直连必须自己搭一层用量监控。
还没迁移的那部分人：年付用户仍在老制度上
有个容易漏掉的分叉：月付的 Pro / Pro+ 用户在 2026-06-01 自动迁移到了新制度，但年付的 Pro / Pro+ 用户在计划到期前仍然走 premium request 制。
这就导致同一个团队里两个人看到的计费界面可能完全不同，讨论用量时容易鸡同鸭讲。仅针对还在老制度上的年付用户，还有两条 2026-06-01 起生效的调整：一是模型倍率上调，例如 Copilot code review 的模型倍率为 13——每做一次 PR 或 IDE 内的代码评审，扣 13 个 premium request；二是一个非常容易漏算的计量口径，code review 自 2026-06-01 起同时消耗 GitHub Actions 分钟数。
第二条尤其值得团队注意：它意味着代码评审这件事从”只花一种额度”变成了”同时花两种额度”，而 Actions 分钟数往往挂在另一个预算池、由另一拨人管。做预算测算时如果只盯着 credits 那一栏，很可能低估。
落到实操：怎么把机制差异变成可执行的动作
讲了这么多机制，给几条能立刻做的：
- 先给每个工具贴标签。 把团队在用的工具逐个归到三类里去，写在一张表上。归不进去的（比如混合制——含一份配额、超出后转按量）单独标注，这类最容易出账单意外。
- credits 制要盯的是”每次交互的成本”，不是”次数”。 既然按 token 折算，那么控制上下文长度、避免无脑把整个仓库塞进去、简单任务别用最贵的模型，这些动作是直接省钱的。相关思路可以看 token 成本优化怎么做。
- 预算上限要设，但别设成 $0。 尤其在多人团队里，$0 等于停人。留一个小额缓冲，配合告警，比硬拦截体验好得多。
- 月底看余量，反推档位是否买对。 长期用不完就降档，长期月中就见底就升档或者拆预算池。
- 促销期不要拿来做预算基准。 前面提到的三个月促销额度是典型例子——用促销期的用量做全年预算，9 月一到就会翻车。
诚实说说这篇的局限
第一，这篇只对 Copilot 的 credits 机制给了具体数字，因为那部分有明确的官方与公开资料依据。其他工具的窗口长度、包含额度、倍率表，这里刻意不写具体数字——这类参数半年内改过好几轮，写死了反而误导，请以各自官方计费页当前的说明为准。
第二，机制会变。Copilot 这次从 premium requests 换到 credits 就是最好的例子，一个体制性变更就让网上大量旧教程集体失效。看任何一篇讲额度的文章（包括这篇），先看它的时间标注。
第三，涉及海外厂商时有个前提必须说清：这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外，具体以各自官网的地区政策页为准。本文不提供也不背书任何第三方中转渠道，那类服务的合规性与稳定性风险由使用者自负。
小结
AI 编程工具的额度机制归根到底就三类：按时间窗口重置的配额、按预付信用点扣减的 credits、按 token 实时结算的用量计费。搞清楚自己在哪一类，才知道”用完了”意味着等待、被拦、还是账单在涨。Copilot 在 2026-06-01 转为按用量计费、1 credit = 1 美分，是 credits 制最典型的样本，它的两条硬规则——预算设 $0 会立即阻断、额度耗尽不会自动降级——值得所有用 credits 制工具的团队记住。团队预算的动作也很明确：别拿促销期用量当基准，月底看余量反推档位，年付和月付用户的计费口径可能不同要分开算。所有具体数字都以各官网当前页面为准，机制比数字活得久，先把机制吃透再去比价格。