钉死你真正调用的 Sakana Fugu ID

1. Models 页当时列出的 ID

fugu 是默认可排除代理的模型。fugu-ultra 默认指向 fugu-ultra-v1.1，适合接受别名移动的原型。fugu-ultra-v1.1 用来钉死当时的 Ultra。fugu-ultra-v1.0 即旧的 fugu-ultra-20260615，用来复现旧版。fugu-cyber 默认 fugu-cyber-v1.0，只在准入和按量之后使用。同一页还列出 sakana-namazu，不要把它的费率折进 Fugu 估算。

2. 启动时应询问 Models API

用即将用于生成的同一把钥匙和 base URL 调用 GET /v1/models。目标 ID 不存在就在启动阶段失败，不要偷偷换成另一个 ID。官方写明 Cyber 只对符合条件的按量钥匙出现，所以缺少 Cyber 行常常是准入或计费模式问题，不是拼写错误。见 故障核对。

3. 运行日志里要存什么

至少保存：你请求的 ID、Models API 为这把钥匙列出的 ID、已知的计费模式、以及 Ultra 的完整 usage 对象。没有这四项，后来“Ultra 变差了”的报告无法调查。别名漂移和编排 token 意外，在最终答案截图里长得一样。可复制客户端见 API 快速开始。用语见 词汇表。

4. 保守默认

原型用移动别名。任何可能对内发表的对比，都钉死带版本的 ID。两个团队意见不合时，先比 Models API 输出，再比答案。官方预计新的公开前沿模型大约两周训练评估后才会进入 Fugu 更新，别名移动是预期事件，不是事故。需要看三种 API 信封时打开 API 形态。

5. 看起来像模型质量、其实是 ID 漂了

A 组钉死 fugu-ultra-v1.0。B 组使用移动别名，悄悄接到 v1.1。同一 prompt，答案不同。两边都怪“Ultra”。能了结争论的日志是当天早上的 Models API 列表。

第二种失败是 Cyber。README 里的 ID 是对的，钥匙能调 fugu，但 /v1/models 没有 Cyber，因为计费模式或准入不对。重试生成不会把 ID 加进列表。见 Cyber 准入。

第三种失败是合作方路径。列出的合作方可能只暴露 fugu-ultra，没有带版本的 ID。对方没列出的东西你钉不死。承诺可复现之前先对目录。见 第三方入口。官方还说新的公开前沿模型大约两周训练评估后才会进入 Fugu 更新，别名移动是预期事件。把钉死规则写进和地区规则同一份备忘：“预发接受别名；编号实验钉死带版本的 Ultra ID。”只活在聊天记录里的规则，扛不过下一位新同事。

本页不覆盖什么

这里不保证某个带版本的 ID 会永久留在 Models 列表里。官方可以下线旧别名。这里也不把 Namazu 的 ID 计划写进 Fugu 估算。需要复制客户端时看快速开始；需要看被忽略字段时看 API 形态；需要解释 usage 时看编排 token 页。运行日志里同时写下“请求的 ID”和“当天列表里的 ID”，比只截一张最终回答更有用。两个环境对不上时，先对这两行，再讨论模型“变聪明了还是变笨了”。预发和正式环境若共用别名、不共用钉死规则，争论会每周重复一次。词汇表里的 Models API 词条就是为了让这句话在别的文章里保持短。问答页只回答“该不该写死 fugu-ultra”，展开的表格和失败模式留在本页。

来源

• Sakana AI Models
• Sakana AI Pricing

2026 年核对后，默认别名仍可能再动。把“我们用 Ultra”写进架构图之前，先写清是别名还是 v1.1 / v1.0。这比再讨论一次分数更省时间。