Copilot与原始API访问：你实际在为什么付费？

我不断看到这个问题：“既然我能通过API调用同样的模型，为什么还要为GitHub Copilot付费？”

这是个合理的问题。答案取决于你需要拥有哪部分工作。

你是在用自己的提示、检索、路由、日志、安全模型和计费控制构建产品功能？还是想从GitHub Issue出发，经过编辑器、仓库、终端和组织策略，最终得到已审查的拉取请求？

成本是其中的一部分。Copilot计划包含每月的GitHub AI积分分配。计量使用量根据所选模型的输入、输出和缓存令牌按标定费率计算。

原始API访问和Copilot解决的是系统的不同层次。正确的选择取决于你需要拥有的工作。

Copilot是围绕模型开发的工具

现在以一个常见的维护任务为例：开发者从GitHub Issue开始，检查仓库，修改受影响文件，在终端运行测试套件，然后打开一个用于审查的拉取请求。模型调用是该工作流中的一个步骤。周围系统需要Issue、差异、仓库指令、允许的命令以及组织的策略。

GitHub Copilot将这些表面连接起来：编辑器、仓库、拉取请求、Issue、终端和组织控制。这就是计划覆盖的内容，除了模型访问之外。计费变更使这种分离更容易看到：代码补全和下一步编辑建议仍包含在付费计划中，而AI积分适用于更耗费资源的聊天和代理工作。

因此，每个任务的成本取决于更多因素，而不仅仅是列出的令牌费率。上下文选择、工具使用、重试以及从Issue到已审查拉取请求的路径都会影响消耗的令牌数量以及工作是否能完成。

相同的计费模型为买家提供了可见性。组织计划将AI积分“池化”到整个组织，管理员可以设定预算并在计费仪表盘中跟踪使用情况。采用变得可衡量，而不是分散在个人API密钥和未追踪的脚本中。

原始API访问适用于你拥有的系统

当你构建产品功能、内部代理平台、评估框架或自动化管道时，直接API访问是正确的起点。你控制提示、检索、路由、重试、日志、安全模型和计费。

考虑一个内部代理：它读取带标签的Issue，检索公司文档，在独立系统中创建变更请求，并编写完整的审计记录。该工作流需要自己的数据边界、事件触发器和审批点。API为团队提供了将这些需求构建到产品中的原语。

工程工作确实存在。生产系统需要决定检索哪些仓库文件、如何保留指令、何时重试失败的工具调用、在何处存储追踪信息以及代理可以使用哪些凭据。这些都是由开发者做出的系统设计决策。模型端点不会为你做这些。

Agent SDK位于这些层之间。处理编排、工具使用、会话和流式传输，但有一些权衡：有些绑定到单一提供商的API，而有些可以在多个提供商之间工作。GitHub发布了这一层。Copilot SDK暴露了与Copilot CLI相同的代理运行时，因此你可以嵌入经过基准测试和生产验证的框架，而不是自己构建一个。使用你的Copilot订阅或你自己的提供商密钥来运行它。

BYOK保持工作流，改变账单

Copilot的BYOK（自带密钥）目前处于公开预览阶段，允许开发者在Copilot Chat、Copilot CLI和VS Code中提供支持的提供商模型。支持的提供商包括Anthropic、AWS Bedrock、Google AI Studio、Microsoft Foundry、OpenAI、兼容OpenAI的提供商以及xAI。

BYOK模型通过GitHub构建和维护的相同框架和集成运行。你的提供商接管令牌账单。GitHub仍开发工具。

无论哪种方式，模型访问都是政策决策。Copilot支持超过20个模型，企业和组织管理员选择团队可以启用哪些模型，无论是GitHub托管的还是通过BYOK连接的。

拥有现有提供商合同或承诺云支出的团队可以保持该商业关系，同时开发者在其正常工作流中使用Copilot。Copilot CLI还支持本地和外部BYOK模型，包括兼容OpenAI的端点、Azure OpenAI、Anthropic和本地Ollama模型。

在做出购买或架构决策之前，请查看关于使用你自己的API密钥与GitHub Copilot（企业版）以及在Copilot CLI中使用你自己的LLM模型的最新文档，因为BYOK仍处于公开预览阶段。

选择你需要的层次

当你需要构建需要自定义行为、集成和控制的系统时，选择原始API访问。当工作是软件开发，并且团队已经在编写、审查、保护和交付代码的工具和仓库中工作时，选择GitHub Copilot。

交付软件是围绕代码的工作：Issue、拉取请求、审查、检查、操作和安全。GitHub是团队完成这些工作的地方。Copilot帮助他们更快地完成。

查看每个Copilot计划包含的内容以及AI积分的工作原理。