GitHub 7 月 22 日专门回答了一个越来越常见的问题：既然开发者可以直接调用同一个模型的 API，为什么还要为 Copilot 付费？

这个问题以前很难算。模型能力、编辑器插件和企业套餐被包在一起，账单只给出一个总价。GitHub 现在把边界说得更直白：Copilot 的计量使用按所选模型的公开费率，根据输入、输出和缓存 Token 计算；代码补全和 Next Edit Suggestions 仍包含在付费方案中，消耗更多资源的聊天与 Agent 工作则使用 AI Credits。

模型费露出来以后，Copilot 剩下的收费理由也更清楚了。它卖的不是一次模型调用，而是让这次调用能够接住 Issue、读懂仓库、运行命令、修改代码，再走到拉取请求和组织策略里的执行层。

同一个模型，两张不同的账单

直接调用 API，团队需要自己决定提示词、检索、路由、重试、日志、安全边界和计费控制。这样做自由度高，适合产品功能、内部 Agent 平台和需要特殊审批链路的自动化系统。代价是这些工程工作都归自己。

Copilot 选择了另一层。一次维护任务通常从 Issue 开始，经过代码检索、终端测试和差异审查，最后才成为一个可合并的拉取请求。模型只是其中一步。仓库指令能否稳定注入，命令具有什么权限，失败后重试几次，组织策略在哪里拦截，都会决定任务有没有真正结束。

GitHub 甚至允许在 Copilot 中使用自带模型密钥。BYOK 目前仍是公开预览，支持多家模型提供商及兼容接口。Token 账单可以交给模型供应商，GitHub 继续维护工具链和运行时。这个安排很能说明问题：模型与执行层已经可以拆开卖。

Token 单价解释不了一次任务花了多少钱

把模型费单列出来，不等于成本已经容易比较。GitHub 自己也承认，上下文选择、工具调用、重试，以及从 Issue 走到已审查拉取请求的路径，都会改变 Token 消耗和完成率。便宜的调用如果反复失败，最后未必便宜。

Vercel 同期给 AI Gateway 增加服务等级，补上了另一块成本拼图。开发者可以为交互任务选择更少排队、更高吞吐的 priority，也可以让后台任务使用价格更低、延迟可能更高的 flex；不指定时走 default。服务等级按实际执行结果计费，priority 无法满足时可回退到默认容量，返回的元数据会告诉应用最终用了哪一档。

这不是简单的云服务菜单。它把 AI 工作负载分成了不同的时间价值：用户正盯着屏幕等待的代码修改，和凌晨批量处理的测试归类，没有必要购买同一种延迟。团队需要观察的也不再只有每百万 Token 价格，还包括完成率、尾延迟、重试次数和人工接管时间。

管理层想知道的已经不是“开通了多少席位”

GitHub 同一天发布了 Copilot 使用影响仪表盘。它按滚动 28 天的产品使用，把已参与用户分成代码优先、Agent 优先、多 Agent 或 Copilot App 等阶段，再展示每人每月合并的拉取请求、合并速度和每日代码行数等指标。

这些数字可以帮助管理员发现买了许可证却没有使用的人，也能看出团队是否从补全走向 Agent 工作流。但它们不能自动证明 Copilot 导致了产出变化。任务难度、团队流程和代码库状况都会影响合并速度。供应商提供的仪表盘适合找线索，不适合直接充当投资回报结论。

更值得注意的是采购问题变了。过去管理者问的是席位利用率，现在还得问：哪些任务值得调用更贵的模型，哪些需要低延迟，哪些可以排队；失败的 Agent 消耗了多少 Token；省下的时间是否被评审和返工吃掉。

先选自己愿意长期维护的那一层

原始 API 与 Copilot 并不是同一商品的两个价格。前者提供模型能力的入口，后者试图交付一条现成的软件开发路径。团队真正要做的是划清自建边界。

如果业务需要特殊数据边界、事件触发和审批规则，自己掌握执行层通常更合理。如果工作主要发生在 GitHub、编辑器和现有组织策略里，购买成熟执行层可能省掉大量集成维护。无论选哪一种，都该把模型费、执行层费用和治理成本分开记账。

模型会继续降价，也会频繁更换。真正黏住团队的往往是仓库上下文如何组织、工具权限怎样配置、运行记录存在哪里，以及出错后谁来接手。下一轮 AI 编程工具竞争，模型排行榜仍会吸引注意力，但采购决策会越来越像一场系统工程评审：不要只问一次调用多少钱，要问一次可审查、可合并的任务究竟花了多少钱。