GitHub 在 2026 年 9 月 22 日的 changelog 中宣布，Anthropic 最新的 Opus 模型 Claude Opus 5.5 正式进入 GitHub Copilot。这不是一次简单的模型列表扩充：官方给出的定位明确指向三个场景——agentic coding、长时间运行的 agentic 任务，以及知识工作。对于已经在 Copilot 中运行 coding agent 的团队来说，模型选择器里多了一个面向长任务的选项。
官方披露的早期测试结论值得关注：Opus 5.5 解决任务的表现与 Claude Opus 5 大致相当，但使用的步骤数和 token 数显著更少；在多步任务中，它也能较快地从错误中恢复。这两点合起来指向同一个优化方向——不是单点能力更强，而是单位工作量更省。在 agent 场景里，步骤数与 token 数直接决定一次任务的时间上限和上下文预算消耗，因此这一变化对长链路任务的意义，通常大于对单次补全的意义。
可用范围与启用方式
Claude Opus 5.5 面向 Copilot Pro+、Max、Business 和 Enterprise 用户开放。可以在以下位置的模型选择器中选中它：Visual Studio Code、Visual Studio、Copilot CLI、GitHub Copilot coding agent、GitHub Copilot app、github.com、GitHub Mobile（iOS 与 Android）、JetBrains IDE、Xcode 以及 Eclipse。官方说明本次推出是逐步进行的，如果暂时看不到该模型，属于正常情况。
企业侧的控制项也一并给出：Copilot Enterprise 与 Copilot Business 的管理员可以通过 Copilot 设置中的 model policy 管理对该模型的访问。在默认模型启用策略下，新模型会自动启用——除非管理员关闭了全局默认开关，或者显式禁用了这个模型。这一点对受合规约束的组织比较关键：模型上线即默认可见，需要主动去关，而不是主动去开。
计费与水印
计费方面，该模型在 usage-based billing 下按 provider list pricing 结算，具体单价需查阅 GitHub Copilot 的模型与定价文档。也就是说，预算核算应当按用量计费的口径来做，而不能假设它被包含在固定的订阅额度内。
另一个容易忽略的细节是水印：Claude Opus 5.5 会对其文本输出添加水印。官方强调水印不改变输出的含义、质量或可读性，也不会额外增加 token 或成本。如果团队有对生成内容二次处理或对外分发的流程，需要把这一点纳入评估，但不必按性能损耗来对待。
选型建议（以下为工程分析，非官方结论）
在 Copilot 已有多个可选模型的前提下，决定何时切到 Opus 5.5，更适合按任务形态而不是按“哪个模型更强”来判断。
优先考虑 Opus 5.5 的场景：跨多文件的 agentic 任务、需要多轮工具调用与自纠错的 coding agent 流程，以及资料中提到的知识工作类任务。理由是官方描述的多步任务错误恢复能力与更少的步骤、token 消耗，恰好对应这类任务最容易出问题的环节——一次长任务中途失败重启的代价，远高于单次补全之间的差异。
可以继续使用更轻量模型的场景：单行补全、局部重构、解释代码、编写测试这类边界清晰、上下文短的小任务。这类任务对 agent 编排依赖低，切换到按量计费的模型未必带来收益。
工程上还有几点边界需要盯住。第一，官方只给出“与 Opus 5 表现相当、步骤与 token 显著更少”这一比较，没有公布具体基准数字，也没有与 Copilot 中其他模型做横向对比，因此“更省 token”不等于“总成本更低”，最终仍取决于 provider list pricing 的实际单价。第二，逐步推出意味着团队内部可能出现部分成员可见、部分不可见的阶段，此时不适合把关键流水线硬绑定到该模型。第三，相关结论来自 early testing，生产环境下的表现需要团队用自己的任务集验证。
给管理员的可执行动作：先确认 Enterprise/Business 的 model policy 中该模型是否符合组织的模型准入清单，若不希望默认开放，需显式禁用；再在用量计费的预算监控中单独观察 Opus 5.5 的消耗一段时间，再决定是否扩大使用范围。