Summary

  • 在 GitHub 的公开预览机制中，组织安装的 App 若获组织级 Copilot Requests 的 Read-only 权限，可凭安装访问令牌发起 Copilot 请求，无须用户登录；组织支付 AI credits。组织的模型与支出控制仍适用，但不能为这一个 App 或安装实例单设预算。
  • App 用量的归因不在网页 AI 用量视图中，而在导出的 CSV 里通过 app_client_id 查找。暂停或卸载某一安装可阻止其请求，同时也会切断该安装访问其他组织资源的能力。

“只读”读的是权限，不是费用

批准一个 GitHub App 时，管理员看见的是权限表。Copilot Requests: Read-only 很容易让人想到查看状态、读取资料。GitHub 的官方操作页却写明，这项组织权限允许 App 用自身的安装令牌请求 Copilot；无需某个员工登录替它签字。请求消耗组织的 AI credits。这里的 Read-only 描述 API 权限级别，账单则照常向组织记账。

这条路径有明确边界：它适用于组织级安装，不适用于个人账户或企业级安装。App 只能使用组织 Copilot 政策准许的模型，组织计费与支出控制也约束它。GitHub 还把这种安装令牌请求与用户授权、组织付费的 Copilot CLI 政策以及 Actions 工作流的 GITHUB_TOKEN 区分开。把这些身份都写成“自动化用量”，会让费用归因从第一步就失真。

最硬的缺口是预算粒度。GitHub 说明，不能给单个 App 或安装实例创建预算。它的用量计入组织 Copilot 预算；若预算只发提醒，达到阈值后请求仍会继续。要拦住后续使用，管理员必须启用 Stop usage when budget limit is reached。这是一道覆盖组织支出的闸，不是给某个 App 单独装的电表开关。

要找花钱的 App，先离开仪表盘

GitHub 网页上的 AI 用量视图不显示 App 归因。管理员要下载 AI 用量 CSV，筛出 organization 列对应本组织、app_client_id 有值的行，再调用组织安装列表 API，把报表中的 app_client_id 与安装记录的 client_id 对上，由 app_slug 找到应用。审计链条存在，但藏在导出文件和另一次 API 查询之间。看总额方便，追到是谁花的则要多走几步。

空白的 app_client_id 也有具体含义边界。GitHub 列出的可能来源包括记在用户名下的用量、Actions、GitHub 自有 App，以及启用 App 归因之前的历史记录。空格不能当成“没有自动化”，有值也不能当成“应用滥用”。它只是把一次消费定位到安装令牌这条路径。真要判断花了多少，必须拿到该组织的报表。

GitHub 将一个 AI credit 定为 0.01 美元。Copilot Chat、CLI、云端代理、Spaces、Spark 与第三方编码代理消耗这种计量单位；行内补全和下一步编辑建议不在这项 AI-credit 计费中。Business 与 Enterprise 的许可贡献共享月度额度；Copilot access 则从首次计量使用开始计费。不同计划让现金支出出现的时点不同，却不会改变“组织是安装 App 的付款人”这条规则。公开文档没有任何特定 App 的真实用量或账单。

单独停用，连别的功能一起断

组织所有者可以暂停或卸载某个 App 的安装，从而停止它的 Copilot 请求。GitHub 同时提醒：该安装访问其他组织资源的能力也会被切断。模型政策能缩小可调用的范围，组织硬预算能封住更大的支出池；暂停安装则是一把影响其他功能的总闸。当前公开预览机制没有“只停这一个 App 的 AI-credit 消费”的专用预算。

审批应从收费问题开始：谁提出安装，App 会请求什么模型，CSV 里如何认出它，预算增长时谁有权动总闸。Read-only 是权限标签；付款决定藏在安装批准里。

资料来源