摘要
- GitHub 于 8 月 1 日 18:03:05.539 UTC 创建事件 sj1tzyrx599x，并在 18:44:28.733 UTC 解决。
- 公开事件记录持续 41 分 23.194 秒。
- GitHub 最先报告特定上游 AI 模型提供商错误率升高，没有点名模型或公司。
- 18:20:20.807 UTC，公司明确 Fable 5 在 Copilot 产品和 IDE 界面中的可用性下降，并建议其他模型或 Auto。
- 18:20:48.941 UTC，模型特定更新发布 28.134 秒后，GitHub 标记缓解；Fable 5 在 18:23:40.021 UTC 恢复可用。
- 提供商、原因、请求分母、错误率、用户数和地域均未披露；GitHub 承诺发布详细根因分析。
最初 17 分钟只能看到故障类别
18:03:15.483 UTC 的更新使用“特定上游 AI 模型提供商”这一范围。它排除了“Copilot 所有功能普遍故障”的说法，却没有告诉用户应该避开哪个模型。Fable 5 在 17 分 5.324 秒后才被写入公开说明。
来源无法判断这段时间用于技术定位、与供应商确认、发布审核，还是几项工作同时进行。能够确认的只有公开信息逐步收窄：先是提供商类别，随后才是具体模型路由。
模型被点名后，状态几乎立即变化
Fable 特定说明发布 28.134 秒后，GitHub 称退化已经缓解并进入监控；再过 2 分 51.080 秒，公司明确 Fable 5 重新可用。时间差很短，但不能被解释成技术修复只用了 28 秒。
上游处理可能早已开始，只是模型名称尚未公开。状态页时间戳记录外部披露和状态转换，并不保存私下操作的完整起止时间。
绕行建议需要明确模型才能执行
面对“某些提供商出错”的笼统告警，用户知道风险存在，却未必知道该更改哪项选择。Fable 被点名后，“选择另一模型或 Auto”才成为针对性操作。
替代路由仍然不等于等价输出。页面没有 Auto 目标、切换成功率、响应延迟和行为比较。它证明了公司提出连续性选项，没有证明该选项对所有客户生效。
同一天发生不代表共同根因
当天更早时候，GitHub 还处理过 GPT-5.6 Luna 与上游模型提供商相关的独立事件。相近用词和时间接近，不足以证明两次事件来自同一家提供商、同一基础设施或同一技术故障。
两起记录共同展示了模型供应链依赖，却不能合并成一次共同宕机。若没有 GitHub 后续确认，共因只能是猜测。
恢复可用后仍监控约 21 分钟
缓解时间为 18:20:48.941，Fable 恢复可用时间为 18:23:40.021，正式关闭在 18:44:28.733。也就是说，明确恢复后又监控 20 分 48.712 秒。
GitHub 没有说明监控指标或关闭阈值。这段持续时间可以证明公司没有立即结束事件，却不能量化剩余错误。
企业应保存模型选择与回退记录
团队可以记录请求模型、错误类别、重试、可见情况下的 Auto 选择、响应延迟，以及输出是否进入下游流程。笼统上游告警出现时，临时调整允许模型列表应成为可审计的运营决策，而不是无痕界面操作。
现有证据不支持提示词泄露、代码暴露或输出损坏。GitHub 公开的症状是可用性与错误率，而不是安全或完整性问题。
根因报告还要解释“何时认出 Fable”
后续分析应说明 GitHub 何时确认 Fable 相关、如何把提供商健康状态映射到模型身份、什么信号触发缓解、Auto 如何响应，以及影响了多少请求与用户。它也应明确与当天 Luna 事件是否存在依赖关系。
目前结论应保持边界：Fable 5 在 41 分 23.194 秒的公开事件中发生退化，状态页在恢复前从笼统上游错误收窄到具体模型。提供商、原因、规模和与早先事件的关系仍未知。
