Claude Fable 5 为何在 Max 方案中错误提示需要 usage credits？

作者：袖梨 2026-09-12

Max 方案仍有 Claude Fable 5 周额度，却被 Claude Code 提示需要 usage credits，可能是客户端没有正确识别模型资格，而不是账户真的耗尽。已公开的复现案例集中在保存模型为 claude-fable-5[1m]、客户端处于计划规则切换期或认证信息无法读取资格时。先以网页 Usage 页面为准，再分别排查模型别名、登录方式、客户端版本和服务端资格。

Max 方案的正常计费规则

Max、Team 高级席位和旧版按席位 Enterprise 高级席位将 Fable 模型作为计划标准部分。Fable 最多可使用每周总额度的 50%，这部分不是额外增加的额度，而是从同一周总额度中消耗。

只有达到 Fable 专属上限后，继续使用 Fable 才需要 usage credits；也可以切换其他模型使用可能剩余的计划额度。因此，网页 Usage 同时显示总周额度和 Fable 周额度均未耗尽时，通用 credits 提示与官方规则不一致。

已知复现场景有什么特征

公开问题报告使用 Max 计划、Claude Code 2.1.215 和 macOS，在 settings.json 中保存了以下模型：

{
  "model": "claude-fable-5[1m]",
  "switchModelsOnFlag": false
}

新会话启动后，Claude Code 没有进入 Fable，而是静默切换到 Opus，并提示 Fable 需要 credits。此时账户周额度很低，说明不能用“额度已经用完”解释。

可能原因一：1M 模型别名解析不一致

[1m] 后缀代表请求百万 token 上下文。问题报告推测，客户端在资格检查时可能把带后缀的完整字符串当作模型 ID，而没有先解析为 Fable 模型与 1M 上下文标志，导致计划资格匹配失败。

这是报告者根据客户端表现提出的假设，并非维护者确认的最终根因。后续也有不带 [1m] 仍出现相似问题的报告，所以别名解析最多解释一部分案例。

可能原因二：客户端没有取得最新资格

模型可用性不仅取决于本地设置，还取决于账户计划、席位和服务端资格数据。计划规则刚调整、旧会话长期运行或本地资格缓存为空时，Claude Code 可能回退到通用 credits 分支。

Team 高级席位的公开案例显示，即使重新登录，模型访问缓存也可能保持为空。这说明问题可能发生在资格获取或识别环节，而不只是界面文案错误。

可能原因三：认证方式权限不足

Claude Code 可以通过交互式 Claude 账户登录，也可以使用 setup-token 或环境变量 token。部分长期 token 只有推理权限，无法读取用户资料或计划资格；客户端因而可能把无法确认的 Fable 访问权当成 credits-only。

如果相同账户在网页和交互式登录中能使用 Fable，而 setup-token 会话不能，应优先检查认证方式。不要把个人凭据、OAuth token 或完整调试日志发布到公开 issue。

第一步：用 Usage 页面确认事实

  1. 确认当前账户确实是 Max，而不是另一个 Pro 或工作组织。
  2. 检查 Current week 和 Current week (Fable) 两个指标。
  3. 确认 Fable 指标低于计划允许的上限。
  4. 记录重置时间、席位类型和提示出现时间。

如果 Fable 指标已经达到上限，credits 提示是正常行为；如果指标仍有明显余量，才进入客户端故障排查。

第二步：去掉 1M 后缀做对照

先临时把保存模型改为标准 Fable，而不是直接使用带 [1m] 的别名。可以通过模型选择器重新选择，也可以在备份设置后修改 model 字段。

新建会话后再次选择 Fable。如果标准上下文可用、只有 [1m] 触发 credits，证据更偏向别名或 1M 资格判断；如果两者都失败，则继续检查认证和账户资格。

第三步：重启并更新 Claude Code

完全退出当前 Claude Code 进程后重新启动，让客户端重新获取资格信息。随后升级到当前稳定版本，再用新会话测试，不要只在原有恢复会话中切换模型。

版本升级只能排除已修复的客户端问题，不会改变账户计划。应同时保留升级前后的版本号和测试结果。

第四步：改用交互式登录验证

若当前使用 setup-token、CLAUDE_CODE_OAUTH_TOKEN 或其他自动化凭据，可在安全环境中用正常交互式账户登录进行对照。交互式登录可用而长期 token 不可用，说明问题更接近 token scope 或资格读取。

不要通过手工修改本地资格缓存伪造计划类型，也不要把从其他账户复制的 token 当作解决方案。这会带来凭据泄露和错误计费风险。

第五步：避免误扣 credits

在原因未确认前，不要为了绕过提示直接开启无限额按量计费。如果必须继续工作，可切换到计划内其他模型；确需 Fable 时，先设置保守的月度上限并坚控每次任务支出。

若已经在额度仍充足时产生可疑扣费，应保存 Usage 截图、时间段、客户端版本和提示文本，联系官方支持核对。公开 issue 适合提交可复现信息，不适合包含身份资料。

提交故障报告需要哪些信息

  • Claude Code 版本、操作系统和终端环境。
  • 计划与席位类型，但不包含账号隐私信息。
  • 标准 Fable 与 [1m] 的对照结果。
  • 网页 Usage 中总周额度与 Fable 周额度百分比。
  • 交互式登录和 setup-token 的对照结果。
  • 完整提示文本、发生时间和是否自动回退模型。

FAQ

Max 有 Fable 就能无限使用吗？

不能。Fable 最多占每周总额度的 50%，达到后继续使用需要 credits，或者切换其他模型。

去掉 [1m] 一定能解决吗？

不一定。它是低风险的诊断和临时规避手段，但不带后缀的案例也曾出现，认证资格和服务端状态仍需检查。

看到错误提示就会自动扣费吗？

提示本身不等于已经扣费。是否继续消费取决于 credits 是否启用、是否有余额和用户确认；仍应及时检查 Usage 与记录。

总结

Max 计划有 Fable 余量却收到 credits 提示时，先用网页 Usage 证明额度状态，再依次测试标准模型别名、重启升级、交互式登录与新会话。公开问题表明 [1m] 解析和资格读取都可能参与，但在维护者确认前不能把单一假设当成根因。排查期间应限制额外消费，并保留足够证据交给官方支持。

相关文章

精彩推荐