AI 开发者日报

• Anthropic 重新上线了 Claude Fable 5，但附带可见的安全回退机制：在经历了一天的需求积压后，@claudeai 宣布 Fable 5 回归，同时附带说明称，更新后的网络安全防护措施可能会将部分请求路由到 Opus 4.8，目前生物学/化学分类器仍然过于宽泛 @claudeai。此次重新上线迅速传导至各类工具：Cursor 表示 Fable 5 在其评测中领先，但也是 单次任务成本最高 的模型 @cursor_ai；Devin 在 Cloud/Desktop/CLI 全平台添加了该模型 @cognition；Perplexity 将其恢复为编排模型 @perplexity_ai。Anthropic 还在模型重新上线后为用户重置了速率限制 @ClaudeDevs。

• 更有趣的故事不在于“模型回来了”，而在于“人们如何适应前沿模型的约束”：多位开发者共同转向了 多模型编排 策略，而非依赖单一模型。@theo 描述了他仅将 Fable 用于高价值的推理/规划任务，而将实现、验证和计算机操作等工作委托给其他模型；他报告称端到端的 PR 产出有了显著提升 @theo。类似的观点来自 @omarsar0，他认为团队应该设计 模型组合策略，而不是围绕一个前沿模型来构建系统；以及 @MParakhin，他反驳了“简单任务预分类器”的思路，认为可靠的模型路由往往需要先解决任务本身。在基准测试方面，@kimmonismus 指出 Fable 5 在远程劳动指数（Remote Labor Index）上达到了 16.10%，而 @ArtificialAnlys 报告称 Sonnet 5 在 AA-Briefcase 上排名第二，但轮次数量明显更高，且在低投入设置下性价比表现较弱。

• Z.ai 正在围绕 GLM-5.2 构建产品生态，而不仅仅是发布一个模型检查点：最具体的发布是 ZCode，这是 GLM-5.2 的官方开发环境，支持 BYOK（自带密钥）、跨平台使用，并为编程计划订阅者提供配额提升 @Zai_org。@kimmonismus 的评论将其描述为一个为 GLM 工作流和长时间运行的自主任务而优化的 AI 原生编码 IDE。周边的生态系统也在快速跟进：LangChain 发布了在编码流程中使用 GLM-5.2 的指南 @LangChain，而 @hwchase17 则明确提到开发者正在将 GLM-5.2 作为日常主力模型使用。
• 基准测试表明，开源编码模型正在缩小特定差距，即使整体前沿性能尚未领先：@mercor_ai 报告称，GLM 5.2 是首个在 APEX-SWE 上引领某一类别的开源模型，在集成任务上取得了 55.3% 的 Pass@1，并且是整体测试中表现最佳的开源模型；Kimi K2.7 紧随其后。这补充了 @scaling01 的观点，他提醒不要过度宣称 GLM 已经超越了西方顶级前沿模型，但同时承认编码能力差距正在迅速缩小。
• 围绕开源模型的推理工作正成为故事的重要组成部分：@vllm_project 在 vLLM 中为 DeepSeek 模型实现了原生 DSpark 推测解码 支持，报告称在 8×B300 上达到约 250 tok/s，相比 MTP 有更高的接受率；而 @mgoin_ 发布了 GLM-5.2 DSpark 预览版，声称解码速度提升约 1.5 倍。另外，@jon_durbin 报告称，在 Qwen3-32B 上使用自研的 dflash 草稿模型，在相同硬件上实现了 约 50% 的吞吐量提升。

• "Wiki记忆"正成为Agent的一种实用设计模式：@sydneyrunkle 主张将Wiki结构化的记忆作为一种简单且可扩展的基础设施，这一想法迅速转化为产品发布。LangChain 推出了 OpenWiki，这是一个通过 openwiki --init 命令生成和维护Agent可消费代码库文档的工具 @BraceSproul，@LangChain。各篇文章的动机一致：Agent在多个线程之间反复丢失工作上下文，因此需要一种可维护、可检查的知识层，而非原始日志 @caspar_br。
• 记忆系统正从仅检索转向协调与维护：Weaviate 的 Engram 方案具有代表性：候选记忆被提取后，会与现有记忆进行转换比对，然后才提交，这样矛盾只需解决一次，而无需在每次查询时处理 @PrajjwalYd。@bpalit 将同样的论点延伸到企业场景，指出Agent记忆必须可治理、感知权限且可共享——而不仅仅是一个Markdown文件文件夹。
• 结构化组合正在取代"把所有工具都丢给模型"的朴素方法：@omarsar0 重点介绍了 SkillComposer，它将技能选择视为一个联合自回归组合问题，在SkillsBench上相比无技能基线取得了 +23.1pp / +18.2pp 的提升。在框架层面，Deep Agents 增加了对递归语言模型工作流的支持 @sydneyrunkle，而 @hwchase17 将动态子Agent与 Agentic MapReduce 等模式联系起来。这一总体方向——更明确的工作流结构、扇出/扇入模式以及代码强制编排——在多个产品和基准测试中反复出现。

• Cognition 的 Devin Security Swarm 是 Agent 架构围绕真实企业工作流进行专业化的典型案例：该系统采用 Agentic MapReduce 模式，将受限的 Agent 分散到整个代码库中，汇总发现结果，并在呈现已确认的漏洞之前验证其可利用性 @cognition。Cognition 声称，这种方法比替代方案更具成本效益且更准确，并透露一家财富 500 强企业在试点中，于生产仓库中发现并修复了超过一千个漏洞 @walden_yan。来自 @jakejluo 和 @levie 等开发者的普遍反应是，这种模式将推广到大规模文档、代码和知识工作流中。
• AI Agent 评估正在迅速成为一个独立的研究领域：@random_walker 指出，多篇新论文正在推动 Agent 评估的发展，并将其描述为一个独立的学科。实际案例包括：Agent Arena 在 Agent 模式下重新启用了 Fable 5 @arena；AA-AgentPerf 用于每兆瓦 Agent 的系统基准测试 @ArtificialAnlys；以及 WorldModelGym，它评估世界模型是否真正支持良好的决策，而不仅仅是生成看似合理的模拟结果 @RekaAILabs。
• AI 故障报告流程也在向标准化方向推进：FLARE-AI 由网络安全和 AI 安全研究人员组成的联盟发起，旨在标准化缺陷和事件报告流程，使问题能够被路由到正确的开发者和注册中心，而不是消失在各自为政的接收表单中 @ClementDelangue，@ShayneRedford。

• NVIDIA 的 TwoTower 在生成架构的速度与质量权衡上表现突出：@NVIDIAAI 推出了 Nemotron-Labs-TwoTower，将 30B 模型改造为扩散式语言模型，通过双副本设置并行生成 token。官方宣称：生成速度提升 2.42 倍，同时保留原模型 98.7% 的质量。@LiorOnAI 总结其核心技巧是复用冻结的上下文模型加上一个训练好的 writer 模型，从而避免从头进行完整训练。
• 端侧和浏览器推理持续受益于智能体优化和专用运行时：@googlegemma 强调了 WebGPU Gemma 4 在 M4 芯片上达到 255 tok/s，这归功于使用 Fable 5 编写的内核。@andimarafioti 演示了一个完全开源的实时语音栈，基于 Gemma 4 31B 和 Cerebras 推理，旨在成为 OpenAI 实时 API 的即插即用替代方案。在内核层面，Hugging Face 的内核库现已公开 MiniMax 的 MSA 内核 @RisingSayak，同时 Triton-on-Mac 也引起了广泛关注 @QuixiAI。
• 超越传统大模型扩展的架构研究也浮出水面：@gklambauer 提到了 AdaJEPA，这是 LeCun 主导的世界模型方法，通过潜在状态预测误差实现测试时自适应；@LiorOnAI 将 NEO 总结为学习可复用的因果“程序”，而非仅仅进行下一帧预测；@ziv_ravid 则强调“在想象中训练”已从理论推测转变为活跃的研究范式。

• Fable 5 可用性成为技术焦点：@claudeai: “Fable 5 回来了。”，@ClaudeDevs 关于速率限制重置，以及 @cursor_ai 关于 Fable 5 在 CursorBench 上领先。
• 系统/基础设施发布引发广泛关注：@NVIDIAAI 发布 TwoTower，生成速度提升 2.42 倍，质量保留率达 98.7%。
• 开放模型生态持续发力：@Zai_org 为 GLM-5.2 推出 ZCode，以及 @TogetherCompute 宣布完成 8 亿美元 C 轮融资，估值达 83 亿美元。
• 高信号工具与知识层发布：@LangChain/OpenWiki 和 @cognition/Devin Security Swarm。

• 我将 Gemma4-31B 扩展到了 44B（88 层）——既然 Google 不给我们比 31B 更大的模型（热度：747）：配图是一张技术架构信息图，展示了作者对 Gemma4 的扩展方案：将原本 60 层混合基座的 Gemma4-31B 通过插入注意力层扩展到 80 层，再通过复制块进一步扩展到 88 层 / 约 44–47B 参数量的变体，重点强调了恒等初始化、零初始化权重以及将 layer_scalar = 1.0 设置为稳定性保障。作者表示，这样做的目的是在不覆盖基座模型密集知识的前提下，为韩语法律/STEM 领域的微调增加"空余容量"，并在 Hugging Face 模型卡 上提供了实现细节和说明文档；图片链接：https://i.redd.it/qbkvzo4s3pah1.png。评论区的核心技术反馈是，该方法应该与更简单的 RYS（"重复你自己"） 基线进行对比，即直接复制顺序层作为一种快速粗糙的模型扩展策略。其他评论多为鼓励或非技术性建议，而非实质性评估。

一位评论者建议将 44B/88 层的 Gemma 扩展与 RYS（Repeat Yourself） 基线进行基准测试，即直接复制原始模型中的顺序层，作为一种快速增加参数量的方法。他们认为这是一个有用的对照实验，可以判断所提出的层扩展策略是否比简单的层重复方法在同等规模模型上表现更好。

• 社区对后续的量化工作表现出兴趣，前提是社区构建版本可用，这意味着 44B 模型的实用性将取决于是否能在非数据中心硬件上提供低精度版本。另一位评论者将这种方法类比为 Llama 2 / Llama 3 时代的早期"弗兰肯斯坦"大型模型实验——在官方更大规模检查点可用之前，社区曾探索过合并或扩展架构的方案。

• nvidia/Qwen3.6-27B-NVFP4 刚刚发布（热度：702）：NVIDIA 发布了 nvidia/Qwen3.6-27B-NVFP4，这是 Qwen3.6-27B 的一个 NVFP4/混合精度量化变体。评论者指出，该模型发布大小约为 22 GB，对于 32 GB VRAM 来说明显优于 unsloth/Qwen3.6-27B-NVFP4 的大约 26 GB，但仍比一些人预期的"4-bit"模型要大，因为 NVFP4 部署通常包含缩放/元数据和混合 FP8 组件，例如 F8_E4M3——即具有 4 位指数和 3 位尾数的 FP8。主要争论在于预期管理：用户原本希望 NVFP4 的大小能接近 Q8/FP8 的一半，而其他人则认为混合精度的开销解释了为什么压缩比预期要小。社区还希望看到与 Unsloth 版本直接的质量/性能对比，以及未来的 GGUF 转换。

• 评论者比较了 NVIDIA 和 Unsloth 发布的 Qwen3.6-27B NVFP4 版本：NVIDIA 的产物报告约为 22 GB，而 Unsloth 的约为 26 GB，使得 NVIDIA 版本对于 32 GB VRAM 显卡更实用。一位用户指出，由于两者似乎都是混合精度格式，与 FP8 相比，体积缩减幅度小于名义上"4-bit"模型的预期。

• 关于为什么 NVFP4 量化的 27B 模型仍然有 22 GB 存在困惑，用户原本期望其大小接近 Q8 的一半。该讨论还提出了关于 F8_E4M3 的精度格式问题，即具有 4 位指数和 3 位尾数的 FP8，在某些混合精度布局中用于主权重。

• 用户询问 NVIDIA 的版本与 unsloth/Qwen3.6-27B-NVFP4 相比如何，以及是否会发布 GGUF 转换版本用于 llama.cpp 风格的推理。另一个技术问题是该模型在推理过程中是否支持 MTP。

• [audio.cpp] VibeVoice 1.5B 发布——90 分钟播客仅需 22.95 分钟，4.08 倍实时速度，比 Python 快 2.86 倍，无需量化。原生 C++/ggml（热度：583）：audio.cpp 为 VibeVoice 1.5B 添加了原生 C++/ggml 支持，在 RTX 5090 上对 5615.73s / 93.60 min 的多说话人 TTS 生成进行了基准测试，耗时 1376.84s / 22.95 min，RTF=0.245，即 4.08× 实时速度和 2.86× 快于 Python 基线，无需量化，仅 10 个扩散步。作者将其定位为长文本 TTS 运行时的里程碑——专注于可复用会话、类似服务器的本地推理、稳定的内存行为和 CUDA 优化——在 audio.cpp 仓库 中已发布 16/28 个模型系列。评论大多表示支持并对实现工作量感到好奇，一位评论者表示这样的加速将使 TTS/语音转换变得实用；作者还征求了社区对更多模型支持以及跨 GPU/CPU 性能数据的请求。

• 一位评论者链接了之前关于 audio.cpp 性能的讨论，涵盖了其他 TTS 后端如 Qwen3-TTS 和 PocketTTS，这对于将报告的 VibeVoice 1.5B 原生 C++/ggml 吞吐量与之前的本地 TTS 基准测试进行比较很有用：之前的性能讨论。

• 社区明确表示希望将 audio.cpp 的支持扩展到 VibeVoice 1.5B 之外，包括对更大 VibeVoice 7B 模型的请求，这意味着社区希望在同一个 C++/ggml 运行时中，对不同模型规模的推理质量/速度权衡进行基准测试。

• 一位用户认为，报告的 4.08x 实时生成速度和 2.86x 相对于 Python 的加速，可能使本地 TTS 和语音转换 在他们的工作流程中变得实用，同时询问了实现工作量以及编码模型是否对底层 C++ 工作有实质性帮助。

• 华为开源 OpenPangu-2.0-Flash——总参数量 92B，激活参数 6B（热度：512）：华为开源了 OpenPangu-2.0-Flash，这是一个 512K 上下文长度的 MoE 模型，宣传为总参数量 92B，激活参数 6B，根据 X 平台 的公告，发布了权重、推理代码和训练算子。同一帖子称 OpenPangu-2.0-Pro 计划于 7 月发布，作为更大的 505B 总参数量 / 18B 激活参数、512K 上下文长度的旗舰模型，今年晚些时候还将发布更多开源组件；后续的基准测试/声明讨论链接在此处。评论者对华为发布更完整的开源堆栈持谨慎乐观态度，但对模型质量和基准测试的具体性提出了质疑。一个技术批评是，像"超越 Gemma 4"这样的说法过于模糊，没有指明具体是哪个 Gemma 变体，例如是否与 26B-A4B 进行比较。

• 评论者指出，OpenPangu-2.0-Flash 在技术上最重要的部分可能在于其发布姿态，而非原始基准测试质量：华为似乎正在通过发布权重、数据集和训练细节来走向"完全开源"，这对于一个正在构建完整模型+运行时生态系统的硬件厂商来说意义重大。

• 社区对"超越 Gemma 4"的说法持怀疑态度，一位评论者指出这种比较不够具体——例如，华为是否在与 Gemma 3/4 风格的密集或 MoE 变体（如 26B-A4B） 进行比较。担忧在于，对于一个 92B 总参数量 / 6B 激活参数 的 MoE 模型来说，击败一个小的激活参数基线并不能算是一个强有力的结果。

• 一个技术上重要的观点是，Pangu 可能完全在华为加速器而非 NVIDIA GPU 上训练，这使得它在出口管制限制下具有战略意义。一位评论者将其与 DeepSeek 据报道使用华为芯片进行训练的计划进行了对比——后者据称因集群调试问题主要退回到华为进行推理——而将 Pangu 视为一个证明：可以在非 NVIDIA 的国产硬件上训练出可用的 LLM。

• Introducing Claude Sonnet 5, our most agentic Sonnet yet. (热度: 3549): 基准测试表 支持 Anthropic 对 Claude Sonnet 5 的宣称——作为 Sonnet 4.6 更具自主性的继任者，在编码、推理、计算机使用和知识工作等任务上均有提升。报告分数包括 SWE-bench Pro 上的 63.2%、Terminal-Bench 2.1 上的 80.4% 以及 OSWorld-Verified 上的 81.2%，使 Sonnet 5 接近 Opus 4.8 的水平，同时帖子声称其定价更低，且在 Free/Pro 计划上默认可用范围更广。评论者关注的焦点并非原始基准数据，而是产品权衡：有人欢迎接近 Opus 性能但更简洁的 Sonnet 5，开玩笑说 "Opus 4.8 比吃了糖的小孩还能说。" 其他人则对 Haiku 等较小模型表示失望或调侃，并请求推出一个虚构的 "Fable" 模型。

评论者认为，如果 Claude Sonnet 5 能以更少的输出量接近 Opus 4.8 的质量，它将具有吸引力：一位用户表示，如果它的表现 "接近 Opus 4.8 的三分之一输出量"，他就会采用，这暗示了对更低冗长度、更少 token 成本和更快智能体循环的兴趣。

• 一种技术工作流描述为：使用 Opus 进行高层规划/编排，并将执行委托给更便宜的 Sonnet 智能体。评论者认为，Sonnet 的改进之所以重要，是因为更好的低成本模型使多智能体设置更加实用和可及，而无需为每个任务都使用 Opus/Fable 级别的模型。

Looks like Anthropic quietly updated the Sonnet 5 'Agentic search' benchmark graph overnight (热度: 1173): 该图片比较了 Anthropic "Agentic search performance by effort level" BrowseComp 图表的两个版本，新版本似乎重新缩放/扩展了两个坐标轴，并显著改变了 Sonnet 5、Opus 4.8 和 Sonnet 4.6 在 通过率与每任务成本 上的定位。技术意义不在于新的基准结果本身，而在于呈现/可复现性问题：更新后的图表使各模型看起来聚集在更高的通过率和成本附近，引发了关于原始图表是否存在缩放错误、数值绘制错误，或者是否在未作说明的情况下被悄然修改的疑问。图片 评论者对基准可视化高度怀疑，称其为 "信我没错" 图表和 "氛围绘图"。主要争论在于这是善意的修正，还是证明供应商发布的基准图表在没有原始数据和变更日志的情况下过于不透明而不可信。

• 评论者提出了方法论上的担忧：Anthropic 的 "Agentic search" 基准可视化似乎已变为 实质上不同的图表，而不仅仅是修正了坐标轴刻度或交换了模型数值。主要的技术结论是：对没有可复现数据、版本化方法论或变更日志的供应商发布基准图表持怀疑态度——实际上就是 "信我没错" 图表。

Sonnet 5 is worse than Opus at the same price at high and xhigh? (热度: 1173): 图片 是 BrowseComp 智能体搜索性能与每任务成本的基准图表，比较了 Sonnet 5、Opus 4.8 和 Sonnet 4.6 在不同努力级别下的表现。它表明 Opus 4.8 在 high 和 xhigh 努力级别下比 Sonnet 5 更具成本效益，Opus 在可比成本下达到约 70–72% 的通过率，而 Sonnet 5 最高约为 65–69%，这与帖子标题声称的 Sonnet 5 在相同价格层级下可能比 Opus 更差相符。评论者普遍感到失望，认为如果在类似成本下 Opus 更快或更好，那么在 high/xhigh 级别使用 Sonnet 5 就 "毫无意义"。一位用户报告称，Sonnet 5 完成一项任务耗时 17 分钟 并消耗了 9% 的会话使用量，而 Opus 4.6/4.8 完成相同任务仅需约 3 分钟 并使用 4–5%，这加剧了对延迟和会话成本效率的担忧。

• 用户报告了 Sonnet 5 在高设置下的延迟和配额效率不佳：一位评论者表示，一项基于标准的提纲评分任务耗时 17 分钟 并消耗了 5X 会话的 9%，而 Opus 4.6/4.8 完成相同任务仅需约 3 分钟 并使用 4–5% 的会话使用量。这表明尽管标价相似，Sonnet 5 在某些工作负载上的实际吞吐量/成本可能明显更差。
• 一个反驳观点认为，比较取决于所读取的图表层级：Sonnet 5 High 被描述为成本与 4.6 Low 大致相同，同时据称性能有所提升；而 Sonnet 5 Medium 则比 4.6 整体 便宜得多，同时提供大致相当的性能。技术分歧的核心在于，high/xhigh 层级是否是合适的比较点，还是应该关注中低层级的成本-性能定位。

• Claude Mythos 5/Fable 5 出口限制已解除（热度：1602）：图片是一份美国商务部于2026年6月30日发出的信函，声明此前在6月12日信函中对 Anthropic 的 Claude Mythos 5 和 Claude Fable 5 施加的出口许可要求已被撤销。从技术层面讲，这意味着这些模型权重/服务的出口、再出口及在境内转移不再需要特定的商务部许可，这似乎是针对 Anthropic 所陈述的安全风险缓解措施做出的回应；该帖子还附上了 Anthropic 在 X 平台上的公告链接。评论者主要关注产品可用性而非政策机制本身，纷纷询问 Anthropic 何时会"重新激活"访问权限，并开玩笑/请求"提前重置"，这表明用户期望在限制解除后服务恢复或配额发生变化。

一位评论者认为，解除出口限制后，应该与之前的 Claude Mythos 5/Fable 5 结果进行对比基准测试，指出训练阶段或训练后的干预措施虽然旨在降低某一领域的能力，但可能会无意中损害其他领域的性能。其核心关切在于检测能力退化，而非假设恢复访问就意味着模型行为没有变化。

Fable 5 回来了。（热度：2607）：Anthropic 表示在与美国政府讨论后已重新部署 Fable 5，并更新了网络安全防护措施，这可能会暂时增加安全回退的误报率；被标记的请求将路由到 Opus 4.8 处理。生物学/化学分类器与发布时保持一致，其范围仍然足够宽泛，以至于一些基本的生物相关查询也会触发回退，官方承诺将尽快修复；付费计划可在 7月7日 之前获得推广访问权限，上限为每周使用量的 50%，之后可通过使用积分继续访问（支持详情，博客文章）。评论大多表示庆祝，但一个值得注意的担忧是，一旦 Fable 5 恢复使用积分计费，许多用户可能会发现日常使用成本过高。

• 一位使用 $100 计划的用户报告称，让 Fable 5 审查最近的功能新增内容时，它生成了 18 个 Fable 子代理，迅速消耗了剩余约 50% 的 5 小时 使用块。即使在中断并要求其停止/设置 token 限制后，这些代理才开始收尾，账户在大约 120 秒 内达到了 101% 的限制，这凸显了自主子代理扇出可能导致的严重积分消耗问题。
• 多位评论者担忧，当 Fable 切换回使用积分计费后，许多用户可能因价格过高而无法使用。报告的子代理行为表明，除非系统提供更严格的并发、token 或代理生成控制，否则成本可预测性可能成为一个重大问题。

Fable 在 7月7日之前对套餐计划可用，之后将转为基于使用积分（热度：2039）：Anthropic 表示 Fable 5 正在 Claude 平台、Claude.ai、Claude Code 和 Claude Cowork 上全球重新部署，Pro/Max/Team/部分 Enterprise 计划可在 7月7日 之前获得最高不超过每周使用量 50% 的访问权限，之后访问权限将转为使用积分（公告）。通过 AWS、Google Cloud 和 Microsoft Foundry 的云服务正在恢复，而 Mythos 5 仍仅限于经批准的美国组织使用；Anthropic 还表示正在与主要云合作伙伴协调制定共享的越狱严重性评估框架，并推出 HackerOne 渠道用于报告 Fable 5 的网络安全越狱问题。热门评论对从最初预期的访问窗口缩减到 7 天且仅限一半使用量的做法表示强烈不满，多位评论者认为使用积分定价将令人望而却步，并引用了一个据称在 Opus 4.8 上单次会话花费 $124 的例子。其他人则嘲讽 Anthropic 关于越狱分类的表述，认为其过于简化或带有政治动机。

• 用户指出，Fable 的发布计划发生了实质性变化，从最初预期的 14 天套餐访问权限缩减到大约 7 天，之后在 7月7日转为使用积分计费。最具体的成本数据点是一个据称在 Opus 4.8 上单次会话消耗了 $124 使用量的例子，评论者认为这使得持续使用对许多用户来说在经济上不切实际。
• 多位评论者认为，从订阅/套餐访问转向基于使用积分的计费模式，不仅仅是可用性的变化，更是定价模式的重大倒退。讨论的焦点更多集中在按量推理成本的实际影响、访问窗口的缩短以及包含使用容量的减少上，而非功能质量本身。

Fable 将把编码任务重定向到 Opus 4.8（热度：1043）：图片是 Anthropic 在 X 平台上的帖子截图，声称 Claude Fable 5 将再次全球可用，但加强了安全分类器，会拦截更多与网络安全相关的任务，并暂时将常规编码/调试工作路由到 Opus 4.8，直至大约 7月7日。其技术意义在于，一个号称具备高端编码能力的模型正受到安全缓解措施和回退路由的限制，这引发了关于基准测试有效性与其实际可用性/实用性之间差距的质疑。图片 评论者对模型在网络安全、生物学/化学以及现在的编码领域都受到限制感到沮丧，认为它主要对基准测试有用，而非实际工作。还有人反复呼吁推出开源的"mythos 级别"模型，以对抗专有模型的安全门控。

• 一位评论者澄清说，该政策被误读了：根据所引用的文档，并非所有编码任务都会被重定向到 Opus 4.8；只有被分类为存在安全风险的提示词才会被路由/回退到 Opus。因此，关键的技术问题在于安全分类器的行为和准确性，即它们如何判断代码相关请求是否越过了风险边界。