GitHub Copilot Fusion 智能路由模型 · 11-02

今天值得看的

GitHub Copilot Fusion 正式可用：让 Copilot 自己选模型，不再手动切。在 AI Coding Agent 评测里跑到 60 分，跟 Claude Code Opus 5.5 Max 只差 2 分，但 API 开销减半、token 用量减半、耗时少四成

GitHub 星标历史接口重构：以前拉一条曲线要打 2500 次请求，现在 24 次拿到 30 周数据，还顺手把身份信息藏了，不再给爬虫喂邮箱

GitHub webhook 新增三段 IP 范围：如果你维护的是静态白名单而不是跑 Meta API，不加上就会丢 webhook

GitHub Copilot Fusion：不再手动选模型，让 Copilot 自己路由

Copilot 里多了一个叫 Copilot Fusion 的选项。选了它，你不再指定用哪个模型，Copilot 根据任务自己调度------把 Project HydraFusion 的多模型编排和 Copilot auto model selection 的精调模型选择合在一起。

选了 Fusion 后直接在模型选择器里切到 Copilot Fusion，没有额外配置。

Artificial Analysis 的 Coding Agent Index 里，Copilot Fusion Max 跑出 60 分。作为参照，Claude Code 搭配 Opus 5.5 Max 是 62 分。

同一轮评测里，Fusion Max 平均每次任务的 API 成本大约只有 Claude Code 的一半，token 用量也大约只有一半，耗时少了大约四成。

我的判断：如果你的团队已经在付费使用多个模型、而且频繁手动切换，Fusion 值得开起来试。它省的不是模型能力，是切换的心智开销和 API 账单。但要注意------素材写的是「Max」档位才有 60 分，普通档跑成什么样原文没说，先别默认免费版也能到这个水平。

→ 原文

GitHub 星标历史接口从 2500 次请求压到 24 次

GitHub 把获取仓库星标历史曲线的接口重做了。旧做法是翻页拉取 stargazer 列表、拿时间戳、丢掉身份信息。一个高星仓库要打 2500 次请求，而且每一次请求数据库都要扫大量条目才能翻到下一页。

同时还暴露出一个安全问题：公开的 stargazer 列表可以被批量采集，用来做垃圾邮件和钓鱼。

新接口直接返回星标数量曲线，最多给 30 周的数据，只需 24 次请求。身份信息不再出现在返回体里。

GitHub 说旧的 stargazer 列表接口没砍掉，但让你能用新端点拿到同样的曲线而不用再翻页。

我的判断：如果你在维护 star-history 这类工具、或者内部看板在拉星标数据，最好换到新端点。24 次和 2500 次的差距意味着速率限制不再是瓶颈，也省得你每次都要手动丢掉用户信息来合规。

→ 原文

GitHub webhook 新增三个 CIDR 前缀，静态白名单必须加

GitHub 为 github.com 的 webhook 推送新增了三段 IP 范围，已经写进 Meta API 的 hooks 字段。

新增的三个 CIDR 前缀：

复制代码

9.234.98.160/28
9.234.98.176/28
9.234.106.48/28

如果你是用 Meta API 动态拉白名单的，不需要做任何事。如果你维护的是静态白名单，不加上这三段就会开始丢 webhook。

这些范围适用于所有计划的 github.com webhook，包括 GitHub Enterprise Cloud。

我的判断：这件事没有讨论空间。如果你团队用的 webhook 接收端有静态 IP 白名单------不管是在防火墙、安全组还是反向代理上------今天就把三段 CIDR 加上。丢 webhook 的后果不是报错，是静默不发，你可能很久都发现不了。

→ 原文