官方至今没有模型页、没有 API ID、没有定价，能确认的只有路由变了。
说法在中文社区被转成了「Opus 5.2 发布」，但把可核实的部分拆出来看，能确定的只有路由行为变了，其余全部来自使用者的描述。
据发帖者描述，他们通过抓包和查看请求状态发现，前端显示的模型名没有变化，后台的模型标识却已经写着 5.2；同一账号在网页端发起的 Opus 请求依旧走旧模型。这是一次按入口分流的灰度，而不是版本更新——同一个订阅、同一个模型选项，落到哪一边取决于你从哪个客户端进来。
除此之外可核实的东西就不多了：官网没有 Opus 5.2 的模型页，没有 API ID，没有定价，也没有发布时间；中文媒体的报道同样以「网友称」开头。任何关于它「提升了百分之多少」的具体数字，现阶段都不必当真。
让这件事显得可信的一个细节，恰恰是版本号本身：最近冒出来的 slug 直接写 5.2，中间没有 5.1。观察者的推测是内部迭代的小版本没有单独对外，编号就顺势往前走了一格。这只是推测，官方从未解释过命名规则——但一个编造的传闻通常会选一个更规整的数字，5.2 这种不整齐的跳跃反而不太像凭空来的。
传闻里最具体的一条是：响应更快、输出更简洁，在代码生成和长任务中能持续自我迭代，减少要求用户点「继续」的次数。如果属实，这更像是对长任务中断的工程优化——任务续跑与上下文管理的策略调整，而不是纯粹的推理能力跃升。
区别在于体感来源不同。基准分数涨两个点，日常用起来往往察觉不到；而一个原本跑到一半停下来等你确认的重构任务，这次自己跑完了，这种变化第一天就能感觉到。这也解释了为什么关于 5.2 的讨论集中在 Claude Code 用户里，而不是在跑评测的人当中。
灰度本身是常规操作，但它留下一个实际麻烦：前端名字不变、后端已经换掉，用户没有办法确认刚才那次输出到底来自哪个模型。做横向对比的人会拿到被污染的样本，把提示词调到刚好能用的人会发现效果莫名其妙地漂移，写进项目文档里的「我们使用 Opus 5」也变成一句无法验证的话。
这不是某一家厂商特有的做法，也很难要求灰度期间就把一切公开。但在模型名与实际权重解耦已成常态之后，在响应里给出一个可查的模型标识，大概是成本最低的那种诚实。眼下能确定的只有一件事：官方还没开口，所有说法都停在使用者的观察层面。