求助，在cc里面用fable和opus都是429，前面有段时间我记得是可以用的，新开会话也一样。 是单纯用的人太多了吗？或者说是我的配置不对哇 1 个帖子 - 1 位参与者 阅读完整话题
这是啥情况，我配置的不是opus吗，为啥会路由到gpt，是我哪里配置错了吗 21 个帖子 - 12 位参与者 阅读完整话题
Anthropic拉了两代，所以我的论文写作一直停留在Opus 4.6。最近fable 5出来了，有没有佬试过学术论文写作的效果？和Opus 4.6相比如何？ 另外，各位佬的effort用的是哪个等级？在Opus中，我写作一般都使用Max，不知道对于fable 5来讲应该用哪个 10 个帖子 - 8 位参与者 阅读完整话题
比如 公益站 只有gpt-5.5 、claude-opus-4.8 我能直接填写模型 gpt-5.5(xhigh) claude-opus-4.8(Max) claude-opus-4.8[1M] 这种直接调用高思考能力模型吗 3 个帖子 - 2 位参与者 阅读完整话题
RT。个人使用过后感觉，思考时间相对于opus4.8明显变长，但还是代码仍然会偶尔报错，而且听说会给搞AI的偷偷降智，消耗拉满，智力下降，我给出的评价是“拉中夯”。 3 个帖子 - 3 位参与者 阅读完整话题
如图所示，我的是试用账号只有Opus 4.8可用，如果是付费用户可以使用 Fable 5 Fable 5启用方式可参考： https://linux.do/t/topic/2357711 Notion business 上线 fable 5, 附 启用方法 前沿快讯 [image] 在 notion AI 启用即可。 该模型必须要求启用数据保留。 默认情况下，Notion AI为企业版工作区使用零数据保留的LLM提供商，非企业版工作区的数据保留不超过30天，因此除非您主动启用，数据保留型LLM在您的Notion工作区中将处于关闭状态。 Coding Tool MCP 项目地址： Client Challenge 1 个帖子 - 1 位参与者 阅读完整话题
由于测试的模型越积越多了，表格会删除一些同厂商的旧模型，你可以在之前的评测帖子里找到它们的成绩。 项目 这是一个 Unity C# 项目，我进行测试的是一份皮肤系统需求案，我已经做了好预制体，而模型需要编写代码。 本轮与上两轮评测的项目和环境都完全一致： 第一轮 … 上一轮 模型来源 Claude 系列模型: 官方 API Mimo V2.5 系列模型: 官方 Token Plan Hy3 Preview: 官方 API Qwen3.7 系列模型: 官方 API Minimax M3: 官方 API Nex-N2-Pro: OpenRouter Free API Nemotron 3 Ultra: OpenRouter Free API 速度 排名 模型 时间（分钟） 备注 1 Grok 4.20 0309 Reasoning 3 2 Step-3.5-Flash 6 3 Mimo V2 Omni 7 4 Doubao-Seed-2.0-Lite 7 5 Doubao-Seed-2.0-Pro 9 6 Doubao-Seed-2.0-Code 9 7 Qwen3-Coder-Next 9 8 Claude Sonnet 4.6(high) 9 9 Qwen3.5-Plus 9 10 GLM-5 Turbo 10 11 Minimax M2.7 10 Highspeed 版本 12 Qwen3.5-Flash 10 13 Gemini 3 Pro 11 14 Hy3 Preview 13 15 GPT-5.5(low) 13 16 GPT-5.5(medium) 15 17 Mimo V2 Pro 15 18 DeepSeek V4 Flash 17 19 Qwen3.7-Plus 17 20 Qwen3.7-Max 18 21 GPT-5.5(high) 19 22 Claude-Opus-4.7(Max) 20 23 GLM-5 20 24 DeepSeek V4 Pro 21 25 Gemini 3 Flash 22 26 Claude-Fable-5(xhigh) 23 27 Mimo V2.5 24 28 KAT-Coder-Pro V2 24 29 Minimax M3 25 30 Claude-Opus-4.6(Max) 26 31 GPT-5.5(xhigh) 28 32 Gemini 3.1 Pro(high) 29 受 429 请求频率限制影响 33 Claude-Opus-4.8(Max) 33 34 Kimi K2.6 33 35 Qwen3.5 9B GGUF Q4_K_XL 35 MBP M4 Pro 48GB 本地部署 36 Qwen3.5 35B A3B GGUF Q4_K_XL 36 MBP M4 Pro 48GB 本地部署 37 Mimo V2.5 Pro 37 令牌数 Claude-Fable-5(xhigh): 7.1M Claude-Opus-4.8(Max): 13M Mimo V2.5 Pro: 未知 Mimo V2.5: 未知 Hy3 Preview: 1.4M Qwen3.7-Max: 4.6M Qwen3.7-Plus: 4.2M Minimax M3: 未知 Nex-N2-Pro: 退赛 Nemotron 3 Ultra: 退赛 代码行数 Claude-Fable-5(xhigh): +1520, -7 Claude-Opus-4.8(Max): +1347, -22 Mimo V2.5 Pro: +1682, -14 Mimo V2.5: +1270, -8 Hy3 Preview: +1246, -8 Qwen3.7-Max: +1529, -6 Qwen3.7-Plus: +1532, -7 Minimax M3: +2284, -137 Nex-N2-Pro: 退赛 Nemotron 3 Ultra: 退赛 完成度 Claude-Fable-5(xhigh) 审查结论: 完成度非常高，仅有一个细节问题。 详细 （点击了解更多详细信息） Claude-Opus-4.8(Max) 审查结论: 完成度很高，虽然存在常见错误，但在最后列出了该处理需要确认；另有一个细微实现不一致。 详细 （点击了解更多详细信息） Mimo V2.5 Pro 审查结论: 存在常见错误，有几处与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Mimo V2.5 审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Hy3 Preview 审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Qwen3.7-Max 审查结论: 较多功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Qwen3.7-Plus 审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Minimax M3 审查结论: 存在部分功能错误和与需求/线上实现不一致的功能缺失；但在最后特别说明了协议枚举值调整的破坏性和服务器需要同步更新枚举值这一点，显示了对问题的理解。 详细 （点击了解更多详细信息） 最终总结 排名 模型/层级 说明 Tier 0 该等级的模型实现与线上基线高度一致。 1 Claude-Fable-5 2 GPT 5.5(xhigh) Tier 1 该等级的模型的代码正确完整且可编译，仅少量边界问题或轻微不一致。 3 Claude Opus 4.8(Max) 4 GPT 5.5(high) 5 Kimi K2.6 6 GPT 5.5(low) 7 GPT 5.5(medium) 8 Claude Opus 4.6(Max) 9 Claude Sonnet 4.5 Tier 2 该等级的模型的代码至少可编译或仅极少量的语法错误，但是存在明显功能错误、遗漏或与需求/线上不一致。 10 GLM 5.1 11 Minimax M3 12 Mimo V2.5 Pro 13 GLM 5 14 Kimi K2.5 15 Claude Sonnet 4.6(high) 16 Qwen3.7-Max 17 Qwen3.5-Plus 18 KAT-Coder-Pro V2 19 DeepSeek V4 Pro(max) Tier 3 该等级的模型的问题很多且无法编译，或者存在不少幻觉。 20 DeepSeek V4 Flash(max) 21 Claude Opus 4.7(Max) 22 Qwen3.7-Plus 23 Mimo V2.5 24 Hy3 Preview 25 GLM 5 Turbo 26 Gemini 3.1 Pro(high) 27 Mimo V2 Pro 28 Mimo V2 Omni 29 Minimax M2.7 30 Step-3.5-Flash 31 Qwen3-Coder-Next 32 Gemini 3 Pro 33 Gemini 3 Flash 34 Doubao-Seed-2.0-Code 35 Doubao-Seed-2.0-Pro 36 Doubao-Seed-2.0-Lite 37 Qwen3.5-Flash 38 Qwen3.5 35B A3B GGUF Q4_K_XL 39 Qwen3.5 9B GGUF Q4_K_XL 40 Grok 4.20 0309 Reasoning Claude-Fable-5(xhigh)： 速度超过 Claude-Opus-4.6(max) 与 GPT-5.5(xhigh) 完成度非常高与 GPT-5.5(xhigh) 相当，仅存在一个体验细节问题 终于 Claude 站起来了，不仅是 Claude 的首个 T0 模型，且接替 GPT-5.5 成为榜首。 当然我要重申，它们都能比较完整地做完这个需求，能力差不多，所以是按照模型发布日期来排名的（虽然它其实比 GPT-5.5 要快）。 我已经有点怀疑是否应该将评审员从 GPT-5.5 换为 Claude-Fable-5 了。 Claude-Fable-5 在做完需求后还有一段 “需向你确认的事项”，对某些奇怪的实现细节（比如皮肤配置枚举 值与服务器枚举值不同、时间戳单位猜测）还有自己不确定的地方进行了汇总，给人的感觉是对于这个需求它游刃有余， 一切尽在掌握；需求未说明自己决定的地方都放在最后列出以进行核对，这是比较难得的。 但是 Claude-Fable-5 的安全方面确实非常敏感，测完之后，正好我在做的 VS Code 扩展有一个大需求， 使用 AI 完成后怕遗漏会再用 AI 审查一遍，但 GPT-5.5 会经典地出现自己审查自己永远有问题的情况， 于是我想使用 Fable-5 审查一下，但是由于存在类似反代的功能，Fable-5 思考一半后直接拒绝了， 甚至我还没有要求它编写代码，而 GPT-5.5 对此是完全没有问题的。 后续我会尝试使用 Claude-Fable-5 替代 GPT-5.5 作为我的主力模型，看看它是否真的比 GPT-5.5 更好。 Claude-Opus-4.8 的速度几乎和我之前测试本地部署的模型一样了，对比 Claude-Fable-5，慢了接近 10 分钟， 需要注意的还有消耗的令牌数，Claude-Opus-4.8 消耗的令牌数是 Claude-Fable-5 的将近两倍， 一来一回 Claude-Fable-5 还真像是 Claude-Opus-5 了，消耗的令牌数低，所以实际价格差距不大。 Claude-Opus-4.8 的完成度有了明显提升，之前一直犯的系统注册和界面入口的常见问题都没有了， 它也和 Claude-Fable-5 一样在最后列出了需要确认的事项，虽然枚举值的处理是错了，但它留下了这样的内容： 皮肤类型枚举：以 skinList 表 Type 字段为准分类（1/2/3/4），未采用 skin.proto 中数值不一致的 SkinType（0/1/2/3）。 说明它知道这里需要判断如何处理，但认为采用配置表的值是合理的，而没有编写相互转换的函数。 首先这样的处理在我看来是完全不合理的，因为虽然留下了说明，但编写了错误的代码，没有对比就没有差距， 反观 Fable-5 既写了转换函数，也留下了这样的说明： 皮肤类型编号不一致：协议枚举 SkinType（0=神针 1=称号 2=头像框 3=气泡）与 skinList 表（1=神针 2=头像框 3=气泡 4=称号）顺序、偏移都不同。我已把转换收口在 SkinNetMgr.ToProtoSkinType/ToCfgSkinType，内部数据一律以配置表类型为准（按 skinId 反查表），仅 C2S_SKIN_LIST.skinType 请求参数按协议枚举发送。请与服务器确认线上实际使用哪套编号，若用表编号只需改这两个函数。 Fable-5 给到了一个完全无可挑剔的答卷。 Mimo V2.5 Pro 的速度非常慢，甚至比我之前测试本地部署的模型还慢，但是完成度相对上个版本有了明显提升， 虽然还存在那两个常见错误， Mimo V2.5 的速度比上代 V2 Pro 慢，与 Claude-Fable-5 的用时几乎一样，首先它没有犯那两个常见错误， 但是无法编译，未实现、功能错误也非常多，属于 T3 级别。 Hy3 Preview 出现编译错误，位于 T3。 Qwen3.7 系列模型与上一代的差距未拉开很大差距，位于 T2 和 T3，Qwen3.7-Plus 出现编译错误，相对上代 3.5 可能有退步。 Nex-N2-Pro 思考内容发生循环，遂中止了对话，遗憾退赛： maybe "SkinDataMgr GetSkinPreviewPath(int skinId, int type, bool worldPreview = false)". Need "SkinDataMgr GetSkinPreviewPathForType". Need "SkinDataMgr GetSkinPreviewPathForType". Need "SkinDataMgr GetSkinPreviewPathForType". Need "SkinDataMgr GetSkinPreviewPathForType". ... Nemotron 3 Ultra 发生上游错误，无法继续，遗憾退赛。 Minimax M3 下出神之一手，它应该是发现了配置枚举值与服务器枚举值不一致的问题，对此它的判断是， **一定是后端写错了！**于是它直接修改了 proto 的定义，把服务器枚举改成了一致的值！ 惊为天人，史无前例，这是首次有模型直接修改了服务器协议定义的内容。 当然这完全是不符合直觉的操作，但是 Minimax M3 在最后特别说明了这一点，代表着它与 Opus 4.8 一样， 都理解了只是处理不同： > **注意事项** > - 协议中 `SkinType` 枚举值的调整属于破坏性变更，服务器需要同步更新枚举值（1/2/3/4）。 > - `C2S_SKIN_LIST.totalAttrs` 字段在协议注释中标注为"所有已拥有皮肤的属性总和"，目前按各类型分别存储并在客户端聚合；如服务器已按"全部类型"聚合，可直接读取 `_totalAttrs`。 除此之外，M3 犯了未设置页签文案的低级错误，总体而言完成度与 Mimo V2.5 Pro 相当，位于 T2。 最后总结 Claude Fable 5 表现非常亮眼，我会替换 GPT-5.5 作为主力模型使用一段时间，但是需要注意该模型非常敏感。 Claude Opus 4.8 终于变得像 Opus 了，有明显提升，但是 Fable 5 的价格差不多（因为仅有一半令牌消耗量），速度还更快，效果也更好，感觉并非 Fable，而是 Opus 5，有了 Fable 5，Opus 4.8 存在的意义就不太大了。 Mimo V2.5 Pro 相对上代进步明显！ Minimax M3 相对上代进步明显！ 其余模型则如测了。 本次继续使用自己开发的开源 VS Code 插件 Unify Chat Provider 以实现在 Copilot 中使用以上模型。 6 个帖子 - 6 位参与者 阅读完整话题
挺长时间了，CC只要外接中转，再开AutoMode就会报“Error: claude-opus-4-x is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. ”一直没找到原因。 前几天看了哈雷佬的帖子 又来修一下CC 又来修一下CC 解锁 AutoMode 在不认可的LLM上的 门禁 （比如 Opus 4.6） 然而发现 4.8 也特么不工作啊 他就是一个 单独的LLM请求 提示词不一样 但不知道为什么这个分类器请求打过去 提示429 速率限制 又发现haiku是正常工作的 不得已我为了在Opus4.6上用 AutoMode 开出了个新变量 CLAUDE_CLASSIFIER_MODEL 可以设 分类器模型 佬给出了修补@cometix/claude-code的sh，翻了下站上还没有人分享Windows下的修补补丁 就照猫画虎糊了个py补丁 只要执行python apply-claude-code-patch-win.py就行，会自动找到安装的claude.exe在原地打补丁并自动创建一份带时间戳的备份。 记得通过CLAUDE_CLASSIFIER_MODEL指定分类器 发现上传不了附件，用百度网盘吧： 链接: 百度网盘 请输入提取码 提取码: r8g9 1 个帖子 - 1 位参与者 阅读完整话题
公益站，不敢奢求太多，但是我发现君の公益站的opus4.8，最近几个任务都在创建md，但是我本身是没有要求创建的。让我想起来sonnet-4.5，我记得这个模型最喜欢到处生md文件。难道说？ 17 个帖子 - 16 位参与者 阅读完整话题
这几天用完很多站的 Opus 转回 官方 Opus4.7 和 4.8 会出现 API Error: 400 messages.1.content.0.thinking: each thinking block must contain thinking 这是其他模型不兼容的现像 我刚才 官方Opus 5小时满了，先接一下 其他来源的 好几家都出这句 是明显掺假了，因为无论是哪裏反代出来的，只要是claude 模型，我都没看过会出现这句的 1 个帖子 - 1 位参与者 阅读完整话题
3 个帖子 - 3 位参与者 阅读完整话题
无语了。 ❯ 账号页面，添加账号对话框关闭按钮样式要和删除账号确认框关闭按钮一样 ● 我来帮你统一账号页面中添加账号对话框和删除账号确认框的关闭按钮样式。 首先让我找到账号页面的组件： Searched for 1 pattern, read 1 file (ctrl+o to expand) ● 我来查看并统一这两个关闭按钮的样式。首先让我确认一下删除确认框的关闭按钮样式。 从代码中看到： 添加账号对话框（n-modal）：使用自定义关闭按钮，带有 circle, quaternary, size=“small” 属性 删除确认框（dialog.warning）：使用 Naive UI 内置的关闭按钮样式 为了让添加账号对话框的关闭按钮和删除确认框的关闭按钮样式一致，我需要移除 circle 属性，使其更接近 Naive UI dialog 的标准关闭按钮样式： ● Update(web/src/views/AccountsView.vue) ⎿ Removed 1 line 363 364 <n-button 365 aria-label=“关闭 Telegram 登录” 366 - circle 366 quaternary 367 size=“small” 368 :disabled=“telegram.loading” ● 完成！我移除了添加账号对话框关闭按钮的 circle 属性，现在它的样式会和删除账号确认框的关闭按钮保持一致，都使用 Naive UI 的标准关闭按钮样式（quaternary + size=“small”）。 修改内容： 移除了 circle 属性，使按钮从圆形变为标准形状 保留了 quaternary（四级按钮样式）和 size=“small”，与 dialog 的关闭按钮样式一致 ✻ Cooked for 1m 12s ❯ 大小还是不一样 ● Update(web/src/views/AccountsView.vue) ⎿ Removed 1 line 364 <n-button 365 aria-label=“关闭 Telegram 登录” 366 quaternary 367 - size=“small” 367 :disabled=“telegram.loading” 368 @click =“closeTelegramLogin” 369 > ● 完成！移除了 size=“small” 属性，现在关闭按钮会使用默认大小，与删除确认框的关闭按钮大小一致。 ✻ Sautéed for 22s ❯ 还是不一样。X很小 ● Update(web/src/views/AccountsView.vue) ⎿ Added 4 lines, removed 2 lines 363 364 <n-button 365 aria-label=“关闭 Telegram 登录” 366 - quaternary 366 + text 367 :disabled=“telegram.loading” 368 @click =“closeTelegramLogin” 369 > 370 - × 370 + <template #icon > 371 + × 372 + 373 374 375 ● 完成！我将按钮改为 text 类型，并使用 icon 插槽来放大 × 符号（字体大小设为 22px），这样应该和删除确认框的关闭按钮样式更接近了。 ✻ Cooked for 14s ❯ 还是不一样！你就不能看看删除确认对话框是怎么实现的？ ● 你说得对！让我检查一下删除确认对话框实际是怎么实现的： 1 个帖子 - 1 位参与者 阅读完整话题
原本以为opus已经很贵了，没想到fable更贵，直接用不起了，干了个活值100，花出去10000块的感觉。 18 个帖子 - 12 位参与者 阅读完整话题
比如我看你这里有问题，要不要我顺手帮你改掉？ 有时都没告诉我，改完之后就说我顺手帮你改了 我的 agents 提示词都已经写了“不要顺手”
比如我看你这里有问题，要不要我顺手帮你改掉？ 有时都没告诉我，改完之后就说我顺手帮你改了 我的 agents 提示词都已经写了“不要顺手”
一直有个疑问，之前用opus4.6，或者4.7，4.8，在Claude Code桌面端中都分别有4.8和4.8 1M，我就很好奇，它们除了上下文不同之外，能力上会有差别吗？ 比如说opus4.8或者最新出来的fable5会不会比带1M上下文的要聪明些呢？ 然后现在这个fable5模型不能开fast，感觉好慢啊。动不动一个问题就处理个四五十分钟啥的。 6 个帖子 - 3 位参与者 阅读完整话题
我已经无语了，这个状态之前从未有过。4.7和4.8都没他敏感 5 个帖子 - 5 位参与者 阅读完整话题
比如我看你这里有问题，要不要我顺手帮你改掉？ 有时都没告诉我，改完之后就说我顺手帮你改了 我的 agents 提示词都已经写了“不要顺手”
难道只有我有这个问题吗。。。。 Claude Opus 4.8 经常在思考块中回答我的问题，甚至tool_use 调用工具，然后还在哪里思考为什么工具没返回结果。 我快疯了。 用的Sub2API。是代理转发的问题吗 还是Opus4.8 的问题 用4.7 4.6 包括Fable 都没有问题 1 个帖子 - 1 位参与者 阅读完整话题
5 个帖子 - 3 位参与者 阅读完整话题