--- title: "Copilot Fusion：GitHub 接管了选模型，却没接管账单" title_en: "Copilot Fusion: GitHub now owns the model choice, but not the bill" url: https://www.liamding.com/posts/2026-10-30-copilot-fusion-owns-the-choice-not-the-bill/ markdown_url: https://www.liamding.com/posts/2026-10-30-copilot-fusion-owns-the-choice-not-the-bill/index.md html_url: https://www.liamding.com/posts/2026-10-30-copilot-fusion-owns-the-choice-not-the-bill/ language: zh-CN date: 2026-10-30 lastmod: 2026-10-30 description: "Copilot Fusion 默认走路由是对的，按模型原价计费却把成本波动留给用户：GitHub 该公布各档位成本区间。" categories: ["Product Decisions"] tags: ["developer tools", "product strategy", "pricing", "ai agents", "GitHub Copilot", "model routing"] professional: true sources: - title: "Route and orchestrate models with GitHub Copilot Fusion (GitHub Changelog)" url: "https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/" - title: "About GitHub Copilot Fusion (GitHub Docs)" url: "https://docs.github.com/en/copilot/concepts/models/copilot-fusion" - title: "Optimizing your AI usage to maximize efficiency and reduce cost (GitHub Docs)" url: "https://docs.github.com/en/copilot/tutorials/optimize-ai-usage" - title: "GitHub Universe 2026: Evolving every layer of the stack (GitHub Blog, Jay Parikh)" url: "https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/" - title: "GitHub Enterprise now includes access to GitHub Copilot (GitHub Changelog)" url: "https://github.blog/changelog/2026-10-28-github-enterprise-now-includes-access-to-github-copilot/" - title: "Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents (GitHub Blog)" url: "https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/" - title: "GitHub Copilot Fusion orchestrates Anthropic and OpenAI models to balance performance and cost (Artificial Analysis)" url: "https://artificialanalysis.ai/articles/github-copilot-fusion-orchestrates-anthropic-and-openai-models-to-balance-performance-and-cost" - title: "GitHub Copilot Fusion mixes models to achieve near-Opus 5.5 coding performance at half the per-task cost (VentureBeat)" url: "https://venturebeat.com/orchestration/github-copilot-fusion-mixes-models-to-achieve-near-opus-5-5-coding-performance-at-half-the-per-task-cost" - title: "GitHub launches Copilot Fusion as agents start 40% of pull requests (The Next Web)" url: "https://thenextweb.com/news/github-universe-copilot-fusion-octoverse-agents" - title: "@ibuildthecloud on X: 'Copilot Fusion makes no sense'" url: "https://x.com/ibuildthecloud/status/2115479632149618868" - title: "@awakecoding on X, reply on Copilot Fusion" url: "https://x.com/awakecoding/status/2115481637601583120" author: "Liam Ding（丁洪）" canonical: https://www.liamding.com/posts/2026-10-30-copilot-fusion-owns-the-choice-not-the-bill/ --- ## 问题 2026 年 10 月 28 日，GitHub 在 Universe 大会上宣布 Copilot Fusion 正式上线（GA），所有 Copilot 套餐都能用，覆盖 VS Code、GitHub Copilot app、Copilot CLI 和 JetBrains IDE。Fusion 不是一个模型。GitHub 首席产品官 Mario Rodriguez 说得很直白：“它不是模型，是一个运行时的编排引擎。”用户在模型选择器里选 Fusion，再选一个努力档位：Standard、High 或 Max。之后由 Fusion 逐条 prompt 决定调哪些模型、怎么组合。它可以只用一个模型（single）；可以让便宜的模型先起草，再由一个评判环节决定要不要升级到更强的模型（cascade）；也可以让其他模型评审草稿，再退回修改（critique）。管理员决定哪些模型进入候选池，也可以把 Fusion（任一档位）设为组织成员的默认选项。GitHub 自己的省钱指南里，现在有一节的标题就叫“把 Copilot Fusion 设为默认”。 最显眼的证据来自独立评测。Artificial Analysis 在 Copilot CLI 里用 Coding Agent Index v2.0 测了 Fusion Max：得分 60，每个任务 5.59 美元；Claude Code 搭配 Opus 5.5（max）得分 62，每个任务 11.42 美元。Fusion 每个任务用了 720 万 token，约为 Claude Code 的一半。 真正值得争论的是计费。“使用 Copilot Fusion 时，它用到的每个模型都按该模型的标准费率计费，Fusion 本身不另外收费。”High 和 Max 档可能在一个任务里用到不止一个模型，所以一个任务“可能比 Standard 档消耗更多 AI credits”。GitHub 文档写明，付费套餐用户使用 Fusion 时模型费用打七折，截止到 2026 年 11 月 30 日（changelog 原文只说“限时”）。 所以这次发布其实是两个决定：GitHub 把“选哪个模型”从开发者手里接了过来，却把这个选择的成本留在了开发者那里。 ## 我的结论 第一个决定是对的，第二个只做了一半。 默认走路由是对的，因为手动选模型已经从功能变成了负担。GitHub 自己的 Octoverse 数据显示，2026 年 9 月，自己选模型的 Copilot 用户里有 61% 用了不止一个模型，四个月前是 50%。付费用户 5 月用到 29 个不同模型，9 月增加到 47 个，没有哪个模型的请求占比超过 25%。同一个月，63% 的付费 Copilot 开发者至少用过一次自动选模型。一个 47 项的下拉菜单，等于把定价问题交给了最不擅长定价的人。GitHub changelog 里引用的那位 AT&T 工程师把出错的方式说得很准：开发者“常常为一个复杂任务选了更强的模型，之后做日常工作时忘了切回来”。 按底层模型原价转嫁计费，作为上线时的姿态说得过去：它诚实，价格里没有藏路由的利润，路由省下的每一分钱都归用户。但这意味着现在由 GitHub 做决定成本的那个选择，波动却全部由用户承担。对带 credit 额度的按席位套餐，这还能接受；对 GitHub 同一天宣布的企业版新买法——不必另买订阅就能用全部 Copilot 功能，按实际消耗的 AI credits 付费——就难以接受了。GitHub 关于这种买法的 changelog 写明：不含按席位的月度 AI credits，从第一次请求起就按企业预算计量。路由器的每个选择从第一次请求起就打在一个计量预算上，它就该附带一个关于这些选择会花多少钱的承诺。现在 Fusion 附带的，是一份 benchmark 和一个一个月后到期的折扣。 谁做决定，谁就该对一个数字负责。对 Fusion 来说，这个数字包括三样东西：每个档位的预期成本区间、每次路由请求的回执，以及“如果不走路由，这个组织本该花多少钱”的对比报告。没有这三样，“把 Copilot Fusion 设为默认”就是一条管理员无法验证的建议。 ## 约束条件 **模型泛滥与缓存经济。** GitHub 的省钱指南写明：会话中途切换模型会让缓存失效，而缓存 token 通常只按正常输入价格的 10% 计费。为了省钱手动换模型，结果可能反而花得更多。Fusion 说它会“沿着自然的缓存边界”路由，并尽量让主对话停留在同一个模型上。这是人工选择比不了的结构性优势，也是把路由设为默认最有力的理由。 **只测了一个档位、一个综合分。** Artificial Analysis 只测了 Max，而且只在 CLI 里测。它的指数把三个 benchmark 等权平均，综合分掩盖了各项成绩的参差。Fusion 在 Terminal-Bench 4.0 上以 71 分领先；但在 FrontierCode 上只有 51 分，落后于 Claude Code 搭配 Opus 5.5（max）的 56 分和 Devin Fusion 的 54 分；在 SWE-Atlas-QnA-AA 上是 57 分。VentureBeat 把 FrontierCode 描述为侧重仓库改动的评测，而这恰恰是大多数团队买编码 Agent 的用途。“耗时少 40%”是 GitHub 自己的说法，Artificial Analysis 没有公布计时数据。Satya Nadella 说的“成本最多低 77%”来自 GitHub 自报的另一项 DeepSWE 评测，而且是最大值，不是平均值。 **计量方式。** Fusion 本身不收费，用户按每个底层模型的标准费率付钱。Artificial Analysis 的 5.59 美元是其 benchmark 上每个任务的 API 成本，和 Copilot 的 AI credits 不是同一种计量。七折优惠和 benchmark 上的成本差距不应该相乘。 **治理。** Fusion 只调用企业和组织策略允许的模型，并排除被数据驻留、FedRAMP 或评估模型策略排除的模型。管理员可以看到候选池，也可以只对 Fusion 禁用某个模型，而不必对所有人禁用。这是对的设计；但这也意味着，管控很严的企业可能只给路由器留下寥寥几个模型可选。 **失败语义。** GitHub 限制说明里有两句话，分量比它们所在的位置重得多。第一句：“如果 Copilot Fusion 丢弃了一份草稿，这份草稿已经在你工作区里做出的改动（比如文件编辑）不会被自动撤销。”第二，Fusion 没有自己的上下文窗口，界面上显示的是“基于它所用模型中最小上限的保守值”。路由器悄悄丢掉一份草稿却留下它的改动，等于把一份开发者从没打算接手的验证工作推回给了开发者。 ## 取舍选项 | 选项 | 换来什么 | 代价 | 为什么选/不选 | |---|---|---|---| | 保留手动选择作为默认 | 完全可控，每次请求成本可预测，不用信任任何新东西 | 47 个模型要选，每次切换都要重建缓存，开发者还会忘了切回来 | 不选。Octoverse 显示开发者已经在多个模型间来回切换，下拉菜单是用注意力支付的成本 | | 默认走路由，按底层模型原价计费（GitHub 实际上线的方案） | 没有路由利润，省下的钱全归用户，好解释 | 波动全由买方承担，没有公布各档位成本，折扣有截止日期而不是一个承诺 | 部分选。作为上线姿态是对的，作为计量制企业预算的终局是错的 | | 路由 + 每档位固定价格 | 账单可预测，GitHub 也有了把路由做便宜的动力 | 利润风险落到 GitHub 身上，可能诱使它为省钱悄悄降低质量，定价还需要大量使用数据 | 暂不选。在各档位质量公开之前，固定价格反而会制造它本想消除的不透明 | | 路由 + 公布成本区间、每次请求的回执、节省报告 | 买方能核查自己交出去的决定，管理员能凭证据设默认 | 要在计费和审计界面上投入工程量，GitHub 得公开昂贵模式实际触发的频率 | 选。它把“相信路由器”变成买方可以验证的主张 | | 默认用单一前沿配置 | 综合分最高（62） | 在 Artificial Analysis 的 benchmark 上，每任务成本约为两倍 | 不作为默认。保留为显式选项，用在难的仓库改动上——FrontierCode 显示它在这里仍然领先 | ## 证据 **GitHub Changelog（2026 年 10 月 28 日）：** 所有套餐 GA；三个努力档位，三种执行模式；管理员控制候选池和默认值；按底层模型的标准费率计费，付费套餐限时七折。GitHub 称 Fusion Max 在 Artificial Analysis Coding Agent Index 上得 60 分，与 Claude Code 搭配 Opus 5.5 Max 相差不到两分，每任务平均 API 成本约为一半，token 用量约为一半，耗时约少 40%。 **GitHub 文档：** 选择执行模式被描述为“轻量的一步，只增加极少的延迟”。响应完成后，把鼠标悬停在上面可以看到用了哪些模型。候选池“会随着新模型推出、以及 GitHub 评估哪些模型表现最好而变化”。公开预览阶段，Standard 档还可以调用本地模型（MAI Code 1.1 Flash 与 Qwen3.8 Flash Next）。省钱指南建议把 Fusion 设为默认，解释了会话中途换模型为什么会让缓存失效，还说明了 Copilot CLI 和 SDK 支持按会话设置 AI credit 上限。 **Artificial Analysis（2026 年 10 月 28 日）：** Fusion Max 得 60 分，对手 62 分；每任务 5.59 美元，对手 11.42 美元。Devin Fusion 得 62 分，每任务 8.00 美元。Fusion 在 Terminal-Bench 4.0 上得 71 分，FrontierCode 51 分（对比 56 和 54），SWE-Atlas-QnA-AA 57 分，每任务用 720 万 token。我的算术：5.59 ÷ 11.42 ≈ 0.49，即每任务成本低约 51%，换来约 97% 的综合分（60 ÷ 62）。 **Octoverse 2026：** 多模型使用比例（61%，此前为 50%），不同模型数量（从 29 到 47），没有哪个模型的请求占比超过 25%，63% 的付费开发者用过自动选模型。预览项目 Project HydraFusion 在 CLI 和 Copilot app 里路由了将近 6 万个会话。GitHub 也注明，这些模型选择数据“描述的是观察到的使用情况，不代表模型质量”。 **VentureBeat（2026 年 10 月 28 日）：** 包括对 Rodriguez 的采访。报道说明，77% 来自另一项 DeepSWE 评测，相关配置未公开；耗时说法也不以 Artificial Analysis 的数据为依据。关于企业版新买法，报道称没有按席位的额度，从第一次请求就开始计量；预算用完后代码补全仍可用，但 Chat、代码评审和云端 Copilot 需要有预算。Rodriguez 把省钱归因于路由而不是补贴；VentureBeat 也指出，这并不能说明 GitHub 的利润率。这与 GitHub changelog 一致。 **值得认真对待的反方意见：** @ibuildthecloud 认为 Fusion 是“幼稚的短期打法”：“只便宜一点，就只重要一点”，开源权重模型反正会把成本打下来；帖子接着写道：“一两个月后 Copilot Fusion 就无关紧要了。”我的回应是：正是路由器，让更便宜的模型不必经过每个开发者逐一评估就能进来——Fusion Standard 在预览中已经可以选用本地模型。如果开源权重真把成本打下来，最先体现的地方就是路由器。@awakecoding 回复说，Fusion“提高的是成本效率，不一定是降低总成本”。我同意，这句话正好点出了账单问题：单个任务更便宜，并不能给每月花多少设上限。 ## 这个结论的边界 这个论证对个人开发者最弱：如果套餐每月的 credit 额度很宽裕，波动就被额度吸收了，Fusion Standard 只是一项便利。对以仓库改动为主的团队，我的意见针对的是质量而不是价格：在唯一一份公开的分项数据里，Fusion 综合分上的接近在 FrontierCode 上并不成立，默认走路由可能恰好在最要紧的地方损失最多质量。对管控很严、候选池很小的企业，路由器会退化成一个选择器。而如果 GitHub 给管理员提供逐请求的路由日志和节省报告，这篇文章的大部分论点就不成立了。VentureBeat 说，被问到组织能否看到用了哪些模型时，Rodriguez 给了肯定答复，但逐请求审计能细到什么程度，采访里没有说清。 我没有主张的是：Fusion 不如手动选模型、GitHub 藏了利润，或者这份 benchmark 有错。 ## 我会怎么改 1. 按几类常见任务公布每个档位的预期 credit 区间；High 和 Max 档默认带一个会话 credit 上限——Copilot CLI 和 SDK 已经支持会话上限。 2. 给管理员提供每次请求的路由回执：用了哪些模型、哪种执行模式、消耗多少 credits，并导出到审计日志所在的地方，而不只是一个鼠标悬停提示。 3. 让 cascade 和 critique 的草稿在隔离的 worktree 里运行，被丢弃的草稿就不会留下改动。 4. 用按月的对比报告取代有截止日期的七折：这个组织用 Fusion 花了多少，对比开发者以前自己选的模型要花多少。如果路由真像 benchmark 说的那么高效，这份报告自己就能说服买家。 5. 像 Artificial Analysis 那样公布 Standard 和 High 档的分项成绩，不只公布 Max，并把仓库改动类任务单独列出来。 6. 给现在的管理员的建议：默认设 Fusion Standard，而不是 Max；保留一个具名的前沿模型作为显式选项，直到你们自己的回执显示 Max 在哪里真正划算。 模型选择器的作用，是让开发者为成本负责。Fusion 把这份责任从开发者身上拿走了，这是对的；但这份责任总得落到某个地方，最该接住它的就是 GitHub——以一个它愿意公开的数字的形式。