Copilot vs. 原始API访问:你实际在为什么付费?
Copilot vs. raw API access: What are you actually paying for?
GitHub 博客文章比较了 Copilot 与原始 API 访问的适用场景。Copilot 是围绕模型构建的开发工具,将 issue、仓库、pull request、终端和组织策略连接起来,而原始 API 适用于需要自定义 prompt、检索、路由、日志和安全模型的产品功能构建。计费方面,Copilot 套餐包含 AI Credits,按量计费基于 token 费率,组织套餐可池化 Credits 并设置预算。GitHub 评估显示,在 SWE-bench Verified、TerminalBench 等 benchmark 上,Copilot 在多数配置中使用更少 token 且任务解决率持平。Copilot 支持超过 20 个模型,BYOK(公开预览)允许开发者使用 Anthropic、AWS Bedrock、Google AI Studio、Microsoft Foundry、OpenAI、xAI 等供应商模型,供应商负责 token 账单。
我经常看到这个问题:“既然我可以通过 API 调用同样的模型,为什么还要为 GitHub Copilot 付费?”这是个合理的问题。答案取决于你需要掌控哪些工作。你是在用自己设计的 prompt、检索、路由、日志、安全模型和计费控制来构建产品功能?还是想从 GitHub Issue 出发,在编辑器、仓库、终端和组织策略已经连接好的情况下,完成一个经过审查的 pull request?成本是其中的一部分。Copilot 套餐包含每月分配的 GitHub AI Credits。按量计费根据所选模型的公布费率,对输入、输出和缓存 token 进行计算。原始 API 访问和 Copilot 分别对应这个系统的不同层面。正确的选择取决于你需要掌控的工作。Copilot 是围绕模型构建的开发工具。
现在来看一个常见的维护任务:开发者从一个 GitHub Issue 开始,检查仓库,修改受影响的文件,在终端中运行测试套件,然后打开一个 pull request 供审查。模型调用只是这个工作流中的一个步骤。周围系统需要 issue、diff、仓库说明、允许的命令以及组织的策略。GitHub Copilot 将这些界面连接起来,涵盖编辑器、仓库、pull request、issue、终端和组织控制。这就是套餐在模型访问之外所包含的内容。
计费变更让这种区分更清晰:代码补全和 Next Edit Suggestions 仍包含在付费套餐中,而 AI Credits 则适用于资源密集型的聊天和 agent 工作。因此,每个任务的成本不仅取决于列出的 token 费率。上下文选择、工具使用、重试以及从 issue 到经过审查的 pull request 的路径,都会影响消耗的 token 数量以及工作能否完成。同样的计费模式让买家有了可见性。组织套餐会在整个组织内“池化”AI Credits,管理员可以在计费仪表盘中设置预算并跟踪使用情况。采用情况变得可衡量,而不会分散到各个 API key 和未跟踪的脚本中。
这个框架具有可衡量的影响。GitHub 的评估在保持模型、benchmark 任务、上下文窗口、推理努力、工具选择和 MCP 服务器不变的情况下,比较了 Copilot CLI 与模型供应商的框架。在 SWE-bench Verified、SWE-bench Pro、SkillsBench、TerminalBench 和 Win-Hill 上,Copilot 在大多数配置中使用了更少的 token,同时达到了任务解决率的同等水平。对于 TerminalBench 2.0,每个 agent-模型配置至少运行了五次,以衡量成本和完成度的差异。阅读完整的跨模型和跨任务的 agentic 框架评估。
原始 API 访问适用于你拥有的系统。当你构建产品功能、内部 agent 平台、评估框架或自动化流水线时,直接 API 访问是正确的起点。你控制着 prompt、检索、路由、重试、日志、安全模型和计费。考虑一个内部 agent:它读取一个带标签的 issue,检索公司文档,在另一个系统中创建变更请求,并写入完整的审计记录。这个工作流需要自己的数据边界、事件触发器和审批节点。API 为团队提供了将这些需求构建到产品中的原语。工程工作是实实在在的。生产系统需要决定检索哪些仓库文件、如何保留指令、何时重试失败的工具调用、在哪里存储追踪信息,以及 agent 可以使用哪些凭证。这些都是由开发者做出的系统设计决策。模型端点不会替你做出这些决策。
Agent SDK 位于这些层之间。它们处理编排、工具使用、会话和流式传输,但有一些权衡:有些 SDK 绑定在单一供应商的 API 上,而另一些则跨供应商工作。GitHub 提供了这一层。Copilot SDK 暴露了驱动 Copilot CLI 的同一个 agent 运行时,因此你可以嵌入一个经过基准测试和生产验证的框架,而不是自己构建一个。你可以使用你的 Copilot 订阅或你自己的供应商 key 来运行它。BYOK 保留了工作流,但改变了账单。
GitHub Copilot 的 Bring Your Own Key(BYOK)目前处于公开预览阶段,它允许开发者将支持的供应商模型用于 Copilot Chat、Copilot CLI 和 VS Code。支持的供应商包括 Anthropic、AWS Bedrock、Google AI Studio、Microsoft Foundry、OpenAI、兼容 OpenAI 的供应商以及 xAI。BYOK 模型通过 GitHub 构建和维护的同一个框架和集成来运行。你的供应商负责 token 账单。GitHub 仍然负责开发工具。无论哪种方式,模型访问都是一个策略决策。Copilot 支持超过 20 个模型,企业和组织管理员可以选择为团队启用哪些模型,无论是 GitHub 托管的还是通过 BYOK 连接的。拥有现有供应商合同或承诺云支出的团队可以保持这种商业关系,同时让开发者在他们的正常工作流中使用 Copilot。Copilot CLI 还支持本地和外部 BYOK 模型,包括兼容 OpenAI 的端点、Azure OpenAI、Anthropic 和本地 Ollama 模型。在做出购买或架构决策之前,请查看当前关于将你自己的 API key 与 GitHub Copilot(企业版)以及在 Copilot CLI 中使用你自己的 LLM 模型的文档,因为 BYOK 仍处于公开预览阶段。
选择你需要的层。当你构建一个需要自定义行为、集成和控制的系统时,选择原始 API 访问。当工作是在团队已经编写、审查、保护和交付代码的工具和仓库中进行软件开发时,选择 GitHub Copilot。交付软件是围绕代码的工作:issue、pull request、审查、检查、actions 和安全。GitHub 是团队完成这些工作的地方。Copilot 帮助他们更快地推进。查看每个 Copilot 套餐包含的内容以及 AI Credits 的工作原理。
文章《Copilot 与原始 API 访问:你实际上在为什么付费?》最初出现在 GitHub 博客上。