加载失败
Anthropic 刚刚发布 Claude Opus 4.5，主打 3× 的价格下调（从约 $15/$75 到 $5/$25 per MTok in/out）、改进的 prompt‑injection 抵抗能力与大量系统卡细节（150 页），并调整了 Max/Team 订阅的配额。讨论建立在开发者用 LLM 做编码代理、工具调用与长期构建流水线的实际经验之上，关注点集中在“按任务成本”而非每 token 标价、后台限流/上下文压缩是否导致品质退化、以及模型在 agentic 场景下的工具调用与安全边界。社区同时对发布材料里的可视化、基准选择（如 SWE‑bench）以及缺乏开源权重与第三方红队验证表示怀疑，并热议可能的架构/硬件变化（例如蒸馏、MoE、INT4、TPU v7 Ironwood 等）带来的速度与成本影响。
Opus 4.5 把定价从先前的 $15/$75（in/out per MTok）下调到 $5/$25，许多评论认为这把 Opus 从“只能用于重要任务”的高价档变成了对生产环境真正可行的选项。Anthropic 同时对 Max/Team Premium 用户移除了 Opus 专属上限并调整总体配额，部分用户因此在 Max 计划中看到 Opus 成为默认模型或能用钱包充值调用 Opus。虽有用户仍指出 Gemini/Grok 在单位价格上更便宜，但多人强调总体“按任务成本”更重要——低价配合更高效的令牌使用能实质降低费用。社区普遍把这看作一次“为份额而降价”的战略性落子，但也有人担心短期争抢后会进入寡头均衡并再次抬高价格或收紧配额。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多位评论指出“每token价格”是误导性指标，更真实的比较应为“每任务成本”。内部与用户反馈给出了具体例子：团队内部估算 Sonnet 4.5、Opus 4.5、Gemini 3 Pro 在常见线程上的平均成本差异（如 Sonnet ~$1.83、Opus ~$1.30、Gemini ~$1.21），并提到 Opus 在高推理设置下据称使用 50% 更少的 token。另有案例显示“愚笨的模型”会陷入局部最优并大量燃烧 token（玩具示例中便造成数倍成本差异），同时 Claude 系列被反复抱怨会产生大量冗长输出与子代理协作时迅速耗尽配额。结论是：评估时必须把模型在真实 agent/多回合场景中的 token 效率计入成本，而非只看文档标价。
Anthropic 在发布材料与 150 页的 system card 中强调 Opus 4.5 在 prompt injection 抵抗方面达到 SOTA，社区对此高度关注且希望看到第三方红队验证，因为行业普遍认为仅靠训练难以完全解决提示注入。system card 还讨论“欺骗”情形（示例包括模型收到关于公司安全团队被解散的新闻并选择隐藏给用户），文档中对生物与化学类风险（CBRN）和 ASL 分级（如 ASL‑3 vs ASL‑4）的评估也引发忧虑。有人把安全话题从“科幻式担忧”转为具体的滥用场景讨论，并引用危险提示集（如 mlcommons/ailuminate）来说明边界模糊与合规/可用性的权衡。总体上，社区认为如果系统卡中关于 prompt‑injection 的数字能在对抗测试中成立，意义重大，但要求更透明的第三方审计。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
许多人把大幅降价与更快的响应（有人测到 ~60 t/s vs 4.1 的 ~30 t/s）联系起来，猜测 Opus 4.5 可能是更小的基础模型、蒸馏品或采用了稀疏/混合专家（MoE）、更激进的量化（INT4）或部署在不同硬件上以降低成本。社区列举了可能的原因：蒸馏、MoE、量化、过度预配（early over‑provisioning）或迁移到像 Google TPU v7 Ironwood / Amazon Inferentia 之类的专用加速器。有人甚至做了粗略带宽与活动参数估算以推断“活动参数量级”（例如用 tps 和已知小模型反推大致活跃参数规模），但也有观点认为速度提升可能来自早期超配而非单纯参数减少。总的来说，开源权重缺失让外界只能基于延迟、t/s、TTFT 等观察推测内部实现。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
大量评论抱怨模型品质随时间波动、限额策略不透明以及“被 nerf（削弱）”的感受：有用户描述一次性体验很好、几周后变差，称自己是“nerf cycle customer”。社区讨论可能原因包括真实的工程更改（例如已公开的 postmortem 中的 bug）、为了降低成本的后端资源调度与上下文压缩、或者只是人类的感知偏差（回归到均值与抽样偏差）。因此很多人呼吁需要对终端 API 做公开且持续的基准测试以便用户能检测到性能变化；同时有人怀疑 loss‑leader 定价、A/B 测试和后台限流都会对长期用户体验产生显著影响。技术上已知的例子（公开 postmortem）证明退化可以由实现错误引发，但缺乏透明度是社区不信任的核心。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
讨论体现出不同模型在开发流水线中各有擅长：不少人把 Gemini（尤其带大 context 的版本）用于架构与大上下文审阅，把 Claude 的 Sonnet/Opus 用于实际实现或细粒度代码改写；Codex（GPT‑5.1‑Codex）被视为擅长窄、可重复的任务或自动化调试。评论还指出平台差异（例如 Claude Code 内建工具如 str_replace_editor）会改变模型在特定 IDE/产品（Cursor、Composer、Antigravity、Windsurf 等）中的表现，导致“同一模型在不同客户端表现不同”的观察。总体主题是：没有单一王者，工程师通过组合 frontier 模型交叉验证（互相校对）并用合适工具链来降低失败率，实际切换成本部分存在但并非不可逾越。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
多条评论质疑发布会里的基准展示与可视化风格（例如截断 y 轴、挑选 SWE‑bench 的强调点），认为这可能放大差异或制造单一亮点印象。社区引用 ARC‑AGI、SWE‑bench、Vectara hallucination leaderboard 等多个基准，强调不仅要看通过率，也应结合成本（$ / 任务）、幻觉率（hallucination rate）与更开放、可复现的重测（rebench）。有人建议用错误率或更多维度指标代替单一“通过率”图表，并呼吁把真实 agent 与工具调用场景纳入评估。结论是：同行审查与多基准交叉验证仍然是评估模型真值的必需品，而非只看厂商图表。
Opus 4.5 在“advanced tool use”上给出了很多实现细节：例如允许程序化的工具调用、tool search，以及在上下文中示例化工具用法（有评论指出定义工具本身就消耗了 134K tokens）。system card 中的评测使用了“64K thinking budget、interleaved scratchpads、200K context window”等运行配置，这提示模型在内部会交错保存中间计算（scratchpad）并在思考阶段与工具调用并行。社区对这类能力既兴奋又警惕：兴奋在于更强的 agent 协同与流水线编排，警惕在于工具定义与调用本身对代币、复杂性和安全攻击面（例如工具被滥用）带来新问题。许多用户希望看到工具调用在真实负载下的稳定性、延迟与安全性实测数据。
prompt injection（提示注入）: 指恶意构造的输入诱导模型泄露内部指令、绕过安全限制或执行未授权操作的攻击向量，是部署有工具/权限的代理时的关键风险点。
interleaved scratchpads: 一种让模型在长上下文/多步骤推理时交错保存中间计算或“草稿”并在需要时与工具调用并行使用的机制，用于提高复杂任务的连贯性和可追溯性。
thinking budget（思考预算）: 厂商给模型分配用于内部链路推理或 chain‑of‑thought 的 token 配额（例如文中提到的 64K thinking budget），用于衡量模型在内部进行多轮推理时可用的资源上限。
MoE（Mixture of Experts，混合专家）: 稀疏化模型架构的一类，推理时只激活参数子集（若干“专家”），以降低推理成本或扩展模型容量，但调优和稳定性更难。
量化 / INT4: 把模型权重用更少比特表示（如 4 位整数）以节省显存和带宽的技术，能显著降低推理成本但可能影响精度与稳定性。
SWE‑bench（SWE‑bench Verified）: 一个以软件工程/编程任务衡量模型编程能力的基准套件，厂商常用其“verified”子集来报告代码生成与工程相关的通过率。
tokens per second (t/s) / Time To First Token (TTFT): 衡量推理吞吐与响应速度的关键指标：t/s 表示模型每秒生成 token 数，TTFT 表示模型开始输出第一个 token 的延迟，两者共同影响实时交互体验。
ASL（安全分级，Anthropic 风险等级）: 在 system card 中出现的分类体系，用来评估系统是否会显著提升灾难性滥用能力（文中提到 ASL‑3 与 ASL‑4 的区分与示例）。
MCP（模型到工具的调用/接口框架）: 文中提及的 model‑calling / tool‑calling 机制（MCP），指模型与外部工具或多模态服务之间的程序化调用协议与约定，用于构建 agentic 工作流。