哪些平台兼容 Anthropic API：这条路怎么走，坑在哪
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
Anthropic 兼容层的卖点是「只改 base_url 和 key」，这句话在打通第一个请求这件事上基本成立，但它掩盖了三层真实差异：参数层各家对 Anthropic 原生字段的取舍不一样（有的忽略、有的白名单、有的加了自己的扩展字段），模型层同一个兼容端点换个模型名能力就变（图片输入、思考能否关闭都会跟着变），工具层像 Claude Code 这种客户端内部按档位调好几个模型，只配一半变量会静默失败而不是报错。更要紧的是，这条路不是只增不减的——xAI 的文档已经把 Anthropic SDK 兼容整体标为废弃。所以选平台时别只看「支持 Anthropic 协议」这一行，要去翻那张「支持 / 忽略」的参数表，和它对模型名的具体要求。
兼容层长什么样：三处改动，但每家改的位置不一样
智谱这份 Claude API 兼容文档把迁移动作写得最直白：替换 base_url 为 https://open.bigmodel.cn/api/anthropic，在开放平台申请 api_key，调用时使用智谱的模型编码。官方给的 Python 示例里，客户端仍然是 anthropic.Anthropic(...)，只是构造参数换成了自家的 key 和 base_url；TypeScript 用 @anthropic-ai/sdk，Java 用 com.anthropic:anthropic-java 这个坐标。cURL 示例请求的是 /v1/messages，鉴权头用的是 x-api-key。文档自己带了一条提醒，原话是「某些场景下智谱与 Claude 接口仍存在差异，但不影响整体兼容性」——这句要认真读，它等于提前告诉你差异是存在的。
MiniMax 的入口是 https://api.minimaxi.com/anthropic，官方示例走的是环境变量路线：先 export ANTHROPIC_BASE_URL 和 ANTHROPIC_API_KEY，然后 anthropic.Anthropic() 空构造，让 SDK 自己去读。国际站文档里对应的域名是 api.minimax.io/anthropic。Kimi 的端点是 https://api.moonshot.cn/anthropic。
阶跃星辰这里有个容易踩的路径细节：Messages API 的完整地址是 POST https://api.stepfun.com/v1/messages，但文档明确写了，用 Anthropic SDK 时 base_url 应设为 https://api.stepfun.com，SDK 会自动拼接 /v1/messages，不需要手动带 /v1。而 Step Plan 场景的请求地址是 https://api.stepfun.com/step_plan/v1/messages，对应的 SDK base_url 是 https://api.stepfun.com/step_plan。同一家平台两个通道两个前缀，手写 URL 和交给 SDK 拼的写法还不一样。这种地方出错时报出来的未必是「地址错了」：阶跃自己的排查表里，model does not exist 这个报错的可能原因中就包含一条「Base URL 指向错误接口」，本文后面还会再碰到它。
兼容不等于全兼容：先去查那张「支持 / 忽略」表
这是我认为选型时最该先翻的一页。MiniMax 在 Anthropic SDK 文档里给了一张参数支持表，把每个 Anthropic 原生参数标成「完全支持」「部分支持」或「忽略」三种状态之一。标成忽略的有 top_k、stop_sequences、mcp_servers、context_management、container，文档对这几个的说明就一句「该参数会被忽略」。标成部分支持的只有 messages 一行，原因是内容块类型跟着模型走，下一节单说。
请注意「忽略」这个词的分量：它不是报错，是静默丢弃。你从 Claude 那边原样搬过来一段带 stop_sequences 的代码，请求会成功返回，只是那几个停止序列根本没生效，生成内容一路写到 max_tokens 才停。被忽略的参数不会在响应里留下任何痕迹，也不会进错误日志，只能靠事先对照这张支持表发现。迁移时的正确动作是：把你现有请求体里用到的字段列一遍，逐个去目标平台的支持表里对，凡是落在「忽略」那一栏的，都得在应用层自己补实现。
阶跃星辰用的是相反的策略——白名单。它的 Messages API 文档开头就写着，本文仅列出当前已确认支持的字段，未在本文出现的字段请不要传入。它列出来的请求参数包括 model、messages、max_tokens（必填且必须大于 0）、system、tools、output_config、stream、temperature、top_p、top_k、stop_sequences。有意思的是，MiniMax 明确忽略的 top_k 和 stop_sequences，在阶跃星辰这边是列在支持字段里的。这就是为什么「兼容 Anthropic」这五个字本身没有信息量：两家都兼容，但同一份请求体在两边的行为并不一致。
阶跃星辰还在兼容层里加了自己的扩展字段 output_config.effort，用于控制模型的思考深度，文档说支持三档推理强度的模型可选值为 low、medium、high，而 step-3.5-flash-2603 兼容 low、high 两档。这个字段不是 Anthropic 原生的，好处是能在同一套 SDK 里调思考强度，代价是这段代码换回 Anthropic 官方端点就没法直接跑。
另外别忽略通道级的差异。阶跃星辰文档单独列了 Step Plan 通道下 step-router-v1 这个模型的字段例外：model 字段只接受 step-router-v1，填别的名字返回 HTTP 400 request_params_invalid；messages.content 里的图像块和文档块不支持，用了会返回 unsupported_content_type；tools 里的 web_search 同样不支持，返回同一个错误码；output_config.effort 在这个通道下会被忽略。这是「同一个兼容端点、特定模型另有一套约束」的典型例子，跨模型复用请求体之前要专门确认一次。
同一个端点，换个模型名能力就变
MiniMax 的 messages 字段被标成「部分支持」，原因写在说明里：MiniMax-M3 支持文本、图片、视频、工具调用、工具结果和 thinking 内容块，而 M2.7、M2.5、M2.1 和 M2 系列仅支持文本与工具调用相关内容块，不支持图片和视频输入。内容块层面同理，type="image" 和 type="video" 标注的是仅 M3 可用，其中图片支持 JPEG、PNG、GIF、WEBP，视频支持 MP4、AVI、MOV、MKV，视频除了 URL 和 base64 还可以用 mm_file://{file_id} 的形式引用；官方对直接内联的体积设了上限，超过就要先经 Files API 上传再引用，具体数值以官方文档为准。
思考行为也是跟着模型名变的。按 MiniMax 的说明，MiniMax-M3 默认关闭 thinking，可以用 thinking: {"type": "adaptive"} 显式开启，用 disabled 显式保持关闭；而 M2.x 系列的 thinking 无法关闭，即使传入 thinking: {"type": "disabled"}，thinking 仍会保持开启。文档还强调，当响应包含 thinking 内容块时，后续轮次应原样保留这些块，尤其是在工具调用对话中——它把这条单独拎出来提醒过一次，说多轮 Function Call 对话必须把完整的 response.content（包含 thinking、text、tool_use 等所有块）加回消息历史，以保持思维链的连续性。
Kimi 那边给的三个模型在 Claude Code 里的思考行为也是三种：kimi-k3 默认开启思考，开箱即用；kimi-k2.7-code 始终开启思考，请求必须显式开启，未开启时请求会被拒绝，返回的错误信息是 invalid thinking: only type=enabled is allowed for this model；kimi-k2.6 思考可选，可以关掉。文档在常见问题里还补了一条：WebSearch 报这个 400 错误就是同一个原因，按 Tab 开启 Thinking on 再用，或者切到不受该限制的 kimi-k2.6；另外它写明当前端点暂不支持 WebFetch 抓取，这一条以官方文档当前版本为准。
模型名映射：客户端内部不止调一个模型
如果你的目标是把 Claude Code 这类客户端接到国产端点，最容易翻车的不是 base_url，是模型名。Kimi 的配置说明把原因讲得很清楚：Claude Code 内部会按场景使用不同档位的模型（主对话、后台摘要、子 Agent 等），只配置部分变量会让对应场景静默失败。
它给的变量清单包括 ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL，以及按档位选择模型时用到的 ANTHROPIC_DEFAULT_OPUS_MODEL、ANTHROPIC_DEFAULT_SONNET_MODEL、ANTHROPIC_DEFAULT_HAIKU_MODEL、ANTHROPIC_DEFAULT_FABLE_MODEL，再加上子 Agent 用的 CLAUDE_CODE_SUBAGENT_MODEL。每个变量漏配的后果它也逐条写了：base_url 不配，请求被发往 Anthropic 官方端点，鉴权失败；auth token 不配，返回 401；ANTHROPIC_MODEL 不配，客户端用 Claude 默认模型名去请求，对端无法识别，报模型不存在；档位变量漏配，对应档位的任务（比如 haiku 档的后台标题生成、摘要）请求失败。这张表的用法是反着查：主对话能聊、某个后台任务却报错时，先看那个场景对应哪一档，再回头看那一档的变量配没配，而不是从头改 base_url。
还有一个 CLAUDE_CODE_AUTO_COMPACT_WINDOW，作用是触发自动压缩上下文的窗口大小。这个值需要与所选模型的上下文窗口保持一致：设置过小会过早压缩丢失上下文，过大则报上下文超限错误。MiniMax 的配置示例里同样出现了这个变量，说明也是「与所用模型当前的上下文窗口保持一致」。具体填多少要按官方文档给出的对应模型窗口值来，别沿用上一个模型的旧值。
验证口径两家给的也不一样，值得对照着看。MiniMax 说启动后依次输入 /status 和 /model，/status 应显示 base url 指向自家域名，/model 应显示当前模型为对应模型名。Kimi 则明确说 Claude Code 的 /model 菜单是内置的固定别名列表，不会显示 Kimi 模型，也无需在其中切换，配置是否生效以 /status 显示为准。遇到「菜单里找不到我配的模型」这种疑惑，先看清楚你用的是哪家的文档。
阶跃星辰的排查表更偏错误码：报 model does not exist 时给了三种可能——模型名称填写错误、当前账号没有该模型权限、Base URL 指向错误接口；401 invalid_api_key 对应 Key 错误、过期被删、或者 Key 与当前 API 域名不匹配；402 quota_exceeded 表示额度用完，需要补充余额或升级套餐。最后一条尤其要注意，它和「配置错了」是两码事，别把配额问题当成接入问题去反复改 settings。
鉴权变量与优先级：这里有两份文档打架
Anthropic 生态里同时存在 ANTHROPIC_API_KEY 和 ANTHROPIC_AUTH_TOKEN 两个变量，各家推荐的不一样：智谱文档建议 export ANTHROPIC_API_KEY=YOUR_API_KEY 替代硬编码，MiniMax 的 SDK 示例用的也是 ANTHROPIC_API_KEY，而 Kimi 和阶跃星辰在 Claude Code 配置里用的是 ANTHROPIC_AUTH_TOKEN。Kimi 还专门写了一条 401 排查：如果之前配置过 ANTHROPIC_API_KEY，请把它删掉，避免与 ANTHROPIC_AUTH_TOKEN 同时存在导致冲突。
残留配置这一类问题特别难查，因为出问题的地方不在你刚改的那份配置里。Kimi 的文档说，如果之前通过第三方工具或手动改过 ~/.claude/settings.json，其 env 字段中残留的旧配置会覆盖终端里 export 的同名环境变量，导致新配置不生效或模型请求被静默改写，并给了一段只删除端点、密钥与模型相关变量、不影响权限主题等其他配置的清理脚本；同时提醒去检查 ~/.zshrc、~/.bashrc（Windows 检查用户环境变量）里有没有残留的 ANTHROPIC_* export。MiniMax 的提示方向一致：配置前先 unset ANTHROPIC_AUTH_TOKEN 和 ANTHROPIC_BASE_URL，若这两个变量在 ~/.bashrc 或 ~/.zshrc 中被永久导出，请同步删除对应行，否则新开 shell 会再次注入。
但优先级这件事，两份官方文档给出的说法是相反的：MiniMax 写的是环境变量 ANTHROPIC_AUTH_TOKEN 和 ANTHROPIC_BASE_URL 优先级高于配置文件，Kimi 写的是 settings.json 的 env 会覆盖终端里 export 的同名变量。这里不做调和——两家描述的是同一个第三方客户端的行为，而这个客户端的配置项和行为本身会随版本变化（Kimi 文档开头就说了界面、配置项和支持能力可能随版本变化）。实际生效的是哪一份，以你手上这个版本的 /status 显示为准，两家文档在这一点上倒是一致：都让你用 /status 确认。稳妥做法是别两种方式混用，Kimi 的原话是「任选其一，不要混用」。跨供应商切换如果用了 cc-switch 这类社区工具，Kimi 也提醒过这类工具并非官方维护，预设配置可能与官方推荐值有差异，用完要逐一核对再看 /status。密钥管理本身可以参考API Key 安全管理的通用做法，settings.json 里是明文 Key，别提交进仓库。
缓存也在兼容层里，但要自己标断点
MiniMax 把需要显式设置参数才生效的那种缓存叫「主动缓存」，与之相对的是自动识别重复上下文、不用改调用方式的「自动缓存 / 被动缓存」。这里要先纠一个容易想当然的分法：区分点是有没有在内容块上设 cache_control，不是你打的哪个端点——被动缓存那页给出的示例本身就用 Anthropic SDK、base_url 指向 /anthropic，只是请求体里没有 cache_control，走的仍是自动那条。
主动缓存的用法是在内容块上加 cache_control: {"type": "ephemeral"} 标记可缓存内容的结束位置，系统会检查该断点之前的 prompt 前缀是否已被缓存过，命中就复用，没命中就处理完整 prompt 并在生成响应时缓存下来。
模型边界要单独看一眼：官方那张两种缓存的对比表里，主动缓存一栏列的是 MiniMax-M2.7 系列、MiniMax-M2.5 系列、MiniMax-M2.1 系列和 MiniMax-M2 系列，被动缓存一栏才多出 MiniMax-M3；主动缓存页自带的定价表列的也是同一批 M2.x 型号。所以「用 Anthropic 兼容就能显式管缓存」这句话，得先确认你要用的模型在不在这张表里，模型列表以官方文档当前版本为准。
有几条机制值得单独记：一是缓存前缀按 tools → system → messages 的顺序创建，每一级的改动都会使该级及所有后续级失效，所以工具定义放最前面、别在中间频繁改，是有实际收益的；二是缓存内容是累积的，每个缓存都依赖它之前的所有内容，改动位置越靠前，作废的范围越大；三是系统在每个显式断点之前只回溯有限个内容块，超出这个回溯窗口还没匹配上就停止检查、转到上一个显式断点，所以内容块很多的请求要多设几个断点；四是一次调用支持的 cache_control 数量有上限，超过时只取从后向前最近的若干个，也就是说排在最前面的断点会被丢掉，具体数量以官方文档为准。缓存有明确的生命周期，命中时会自动刷新且无需额外费用，具体时长见官方文档。
效果怎么看，靠 usage 对象里的三个字段：cache_creation_input_tokens 是本次写入缓存的 token 数，cache_read_input_tokens 是从缓存中读取的 token 数，input_tokens 是既没从缓存读也没用于建缓存的部分（即最后一个缓存断点之后的 token）。三者相加才是总输入 token。流式场景下这组数字在 message_start 事件里。计费上，缓存读取按优惠价计费，首次写入需要额外计费，具体单价与相对关系见官方定价页。缓存这件事的通用原理可以看API 缓存计费机制那篇，这里只讲 Anthropic 兼容形态下的差别。
别把「兼容 Anthropic」当成永久承诺
xAI 的 REST 文档里，POST /v1/messages 和 POST /v1/complete 这两个 Anthropic 兼容端点上都挂着同一条 Deprecated 警告，原文说 Anthropic SDK 兼容已完全废弃，官方给出的迁移路径是转向 Responses API 或 gRPC。这是个有用的提醒：兼容层对平台方来说是获客通道，不是核心接口，它可以加，也可以标废弃。
所以如果你打算长期依赖某个 Anthropic 兼容端点，值得在选型阶段就问一句：这层是平台的主推入口，还是过渡方案？智谱把它写成「跟随 Anthropic SDK 更新，保持最新功能支持」，MiniMax 把模型列表接口也做成了 Anthropic 规范（GET /anthropic/v1/models 和 GET /anthropic/v1/models/{model_id}，前者带 limit、after_id、before_id 分页参数），这些是投入的信号；而挂着废弃警告的，就该按迁移窗口来规划了。换平台前的完整核对可以对着换厂商迁移清单走一遍，OpenAI 协议那条路的兼容程度差异，另见各家 OpenAI 兼容到什么程度。
上线前顺手做的三件事
第一，把成本预估接进去。MiniMax 的 Anthropic 兼容接口支持 POST /anthropic/v1/messages/count_tokens，官方说明它可用于 MiniMax-M3 调用前预估输入 token 用量，不会生成模型输出。这不是 Anthropic 兼容层独有的能力，它的 OpenAI 兼容体系下也有一个对应端点：Responses API 的 POST /v1/responses/input_tokens，官方描述是估算请求的输入 token 数、不真正调用模型生成，常用于调用主接口前评估请求成本与是否触发上下文长度上限。两侧都有预估手段，选哪个端点这件事不必拿它当理由；真正的用法是把它接进上线前的检查里，长 prompt 先算清楚输入侧的量级，而不是发完了看账单。
第二，确认额度扣的是哪一笔。智谱的 FAQ 里有一条很典型：买了编码套餐还报「1113 余额不足」或者扣了账号余额，官方给的答复是可能由于未满足编码套餐的使用条件——套餐仅限在官方支持的指定工具与产品环境中使用，且要配置特定的 Base URL 才能使用，官网体验中心不支持使用编码套餐。FAQ 这一页给的 Base URL 是按工具分的（Claude Code 一个地址，Cherry studio 一个地址，这两者之外的工具再一个地址）；把三种协议的入口列成表的是编码套餐的快速开始页和工具接入页：Anthropic Message 协议用 https://open.bigmodel.cn/api/anthropic，OpenAI Chat Completion 协议用 https://open.bigmodel.cn/api/coding/paas/v4，OpenAI Response 协议用 https://open.bigmodel.cn/api/v1，工具接入页还专门加了警告说错误配置端点将导致无法使用套餐额度。换句话说，同一个 key 走错端点，请求照样能成功，钱却从另一个口袋出。扣费明细可以在费用明细的抵扣资源包列表项里核对。
第三，把流式解析写对。阶跃星辰列出的常见 SSE 事件类型是 message_start、content_block_start、content_block_delta、content_block_stop、message_delta、message_stop、ping，返回工具调用参数时 content_block_delta.delta.type 可能为 input_json_delta；MiniMax 的流式示例里则要同时处理 thinking_delta 和 text_delta 两种 delta。非流式响应的 stop_reason，阶跃星辰给的可选值是 end_turn、tool_use、max_tokens。这些都是结构性枚举，照着官方文档当前版本对一遍即可。
最后把这条路上的坑按「会不会报错」分成两堆。一堆是改错了立刻报错的：base_url 写错、key 写错、模型名写错，各家文档都给了对应的错误码和排查项，照着查就能定位。另一堆是改错了照样返回 200 的：被静默忽略的参数、没补齐的档位模型变量、走错端点导致套餐额度没被抵扣——它们的共同点是「请求成功返回」，所以不会有任何东西提醒你。第一堆自己会找上门，第二堆得你主动去找。主动去找的动作也很具体：把你的请求体字段和目标平台的支持表逐行对一遍，把要用的模型放进对应能力表里确认一次，再用 /status 或者一次最小请求把实际生效的配置看清楚，最后去账单里核一遍扣的是哪一笔额度。