API 对照
Sakana Fugu 有三种 API 形态，但不是三个相同的产品
官方 Models 现在同时列出 OpenAI 兼容的 Responses、Chat Completions，以及 Anthropic 兼容的 Messages。兼容描述的是请求信封，不表示每个字段都和 OpenAI 或 Anthropic 效果相同。
1. 先选形态，然后保持稳定
Sakana AI 目前建议新集成用 Responses，尤其是工具、多模态、推理控制和函数调用。Chat Completions 留给已经说这种方言的旧代码。Messages 留给 Anthropic 形态的客户端。中途换信封通常得不偿失，因为被忽略的字段和会话状态并不一样。
| 形态 | 适用 | 文档中的限制 |
|---|---|---|
| Responses | 新集成、工具、结构化输出 | 不接受 previous_response_id |
| Chat Completions | 暂时搬不走的 OpenAI 聊天客户端 | temperature、top_p、惩罚、seed、stop 被忽略 |
| Messages | 已有 Anthropic Messages 客户端 | 按标准 Messages 字段转发；不要假设所有 Anthropic 选项都已在此文档化 |
| Models | 启动校验 | Cyber 只出现在有权限的按量钥匙上 |
2. 模型 ID 也是合约的一部分
截至 2026 年 8 月 17 日：fugu 是默认模型；fugu-ultra 默认指向 fugu-ultra-v1.1；fugu-ultra-v1.0 即旧的 fugu-ultra-20260615；fugu-cyber 默认 fugu-cyber-v1.0。同一页还列出日语专用的 sakana-namazu。本站指南仍聚焦 Fugu，不要把 Namazu 费率混进 Fugu 估算。
3. “接受但忽略”是产品事实
团队常花几周去调一个服务端会丢掉的参数。当前 Models 写得很清楚：Responses 忽略 temperature 和 parallel_tool_calls（支持的模型会在服务端打开并行工具）；Chat Completions 忽略采样与惩罚类字段；previous_response_id 不被接受，必须把历史放进 input；Ultra 的 max_output_tokens 只限制最终模型；推理档位 xhigh 与 max 是别名。不要在设置界面暴露被忽略的字段，否则用户会以为滑块改变了答案。
4. 内置网页搜索已文档化，高级选项没有
官方写明 Responses 可用 {"type": "web_search"}，并写明不支持该工具的高级选项。上线前先在你自己的任务上验证引用处理。会话状态必须由应用自己发送，因此 token 增长是可见且计费的。Ultra 的编排 token 是额外真实用量，长对话加上深层路由可能让单次请求跨过 272K。详见 编排 token 记账。
选型时先问调用方已经会说哪种信封：新代码用 Responses；搬不走的 OpenAI 聊天客户端用 Chat Completions；已有 Anthropic 客户端用 Messages。不要为了“看起来更新”而中途换形态。被忽略字段若出现在设置界面上，用户会以为滑块改变了质量，那是对产品的误导，即使 JSON 被接受了。完整复制示例见 API 快速开始。
版本别名也属于合约。fugu-ultra 目前默认 fugu-ultra-v1.1，但默认值以后还可能再动。需要可复现实验时，把 Models API 返回的具体 ID 写进运行日志，而不是只写 README 里的稳定名。故障现象对应的下一步见 故障核对。别名一变，旧实验就不可比。
本页不覆盖什么
这里不把三种信封翻译成完整 SDK 教程，也不保证每个 Anthropic 或 OpenAI 可选字段都已在 Fugu 上验证。没写进官方 Models 页的行为，一律当未知。需要可复制请求时看快速开始，需要失败码时看故障核对。