MiniMax 同时兼容 OpenAI 和 Anthropic 两套 API：怎么选
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
先把结论说完：MiniMax 的语言模型可以用 OpenAI SDK 接，也可以用 Anthropic SDK 接，官方在接口概览页里给这两条路排了序——写的是「Anthropic SDK（推荐）」，OpenAI SDK 排在后面。两套兼容接口覆盖的模型清单是同一批 M 系列语言模型，模型名也一模一样，所以不存在「某个模型只能用某套 SDK 调」的问题。真正的差异藏在四个地方：入口 Base URL 不同、thinking 参数的默认值在两侧正好相反、被忽略的参数清单不同、以及 token 预估端点两侧都有但路径与所属形态不同。如果你是新项目、并且要用 cache_control 做显式缓存，走 Anthropic 兼容那条路——但要先确认你选的模型在主动缓存的支持清单里；如果你手上已经有一大堆 OpenAI 生态的代码，走 OpenAI 兼容改动最小，但动手前必须先对一遍被忽略的参数清单。
官方自己是怎么排序的
这件事值得先看清楚，因为它决定了你遇到问题时能拿到多少文档支持。
接口概览页在讲语言模型接入方式时写的是：可通过 HTTP 请求、Anthropic SDK（推荐）或 OpenAI SDK 接入。页面下方给了两张并列的卡片，一张标题是「Anthropic API 兼容（推荐）」，另一张是「OpenAI API 兼容」，「推荐」两个字只挂在前者身上。
更能说明问题的是「通过 SDK 接入」这一页——整页只讲了一条路，第一步的标题就是「安装 Anthropic SDK（推荐）」，全程没有出现 OpenAI SDK 的安装与调用示例。也就是说，官方的新手入门路径是单轨的，OpenAI 兼容那条路被放在了 API 参考里，定位更接近「为了满足开发者对 OpenAI API 生态的使用需求」而补齐的兼容层，这句话就是 OpenAI SDK 那一页的开场白。
需要说清楚的是：官方文档里没有找到解释「为什么推荐 Anthropic SDK」的说明。它只是标了推荐，没给理由。所以下面这些对照，是我逐条读两页文档比出来的差异，不是官方给的选型建议。
入口不一样：Base URL 和环境变量名
两条路的差别从环境变量就开始了。
OpenAI 那一侧配的是 OPENAI_BASE_URL，指向 MiniMax 的 /v1 路径；Anthropic 那一侧配的是 ANTHROPIC_BASE_URL，指向的是 /anthropic 路径。两者不是同一个端点的两种叫法，是两个真实存在的不同路径前缀，写错了不会自动纠正。
还有一处容易被忽略的域名差异。Prompt 缓存那一页在给环境变量示例时专门标了一句：「国内用户使用 https://api.minimaxi.com/v1，国际用户使用 https://api.minimax.io/v1」。也就是说，除了选哪套 SDK，你还得选对域名。这两件事是正交的，别混在一起想。
好消息是模型名不用改。两页给出的示例里，模型名都写作 MiniMax-M3，格式完全一致。所以从 OpenAI 兼容切到 Anthropic 兼容，模型标识那一行是不用动的。
最反直觉的一条：thinking 的默认值在两侧是相反的
这是我读下来觉得最该单独拎出来讲的一条，因为它会让同一段提示词在两套 SDK 下拿到形态不同的响应。
OpenAI 兼容那一页对 MiniMax-M3 的说明是：「如果省略 thinking，默认开启 thinking，响应会包含 thinking 内容。」
Anthropic 兼容那一页对同一个模型的说明是：「如果省略 thinking，默认关闭 thinking，响应不会包含 thinking 内容块。」
同一个模型、同样是不传 thinking 参数，两套兼容接口的默认行为正好相反。这意味着你如果照着 OpenAI 侧的代码去改 Anthropic 侧的调用，删掉了显式参数、以为「反正默认一样」，拿到的响应里可能根本没有 thinking 内容块，解析代码就会走到空分支。反过来也一样。
其余的语义两侧是一致的：thinking: {"type": "adaptive"} 在两页里都被描述为等同于开启 thinking；thinking: {"type": "disabled"} 用于关闭。对 M2.x 系列，两页都明确写了 thinking 无法关闭——即使传入 disabled，thinking 仍会保持开启。所以「关掉思考省点开销」这个念头，在 M2.x 上是不成立的，只有 M3 给了这个开关。
至于 thinking 内容怎么计费，这两页都没有写，得去官方定价页确认，别自己推。
thinking 的回传形态不同，多轮工具调用要按各自的规矩来
这一条的分量可以从官方文档的编排上看出来：两页的「快速开始」都只有四步，第四步的标题就叫「特别注意」，讲的是同一件事——多轮 Function Call 对话中，必须把完整的模型返回加到对话历史里，以保持思维链的连续性。官方把它摆在跑通第一个请求的同一节里，而不是丢进末尾的注意事项，这个位置本身就是提示。但「完整」在两侧指的东西不一样。
OpenAI 那一侧要回传的是完整的 response_message 对象，包含 tool_calls 字段。文档还补了一条细节：原生 OpenAI API 形态下，content 字段会包含 <think> 标签的内容，需要完整保留。也就是说思考内容是混在正文字段里的，你如果为了展示好看，顺手把 <think>...</think> 剥掉再存进历史，就把思维链切断了。
想避开这种手工解析，OpenAI 侧提供了 reasoning_split 这个开关。启用后 thinking 内容会拆到 reasoning_content 和 reasoning_details 字段里单独返回，开发者可以直接拿去展示，不用从 content 里抠。文档在函数调用那一页对此加了个重要提醒：包含 reasoning_details 在内的完整 response_message 必须保留在 Message History 中，下一轮回传给模型。换句话说，拆分只是改变了呈现位置，不是允许你丢掉它。
要注意 reasoning_split 并不控制思考的开关。文档写得很清楚：它只控制 thinking 内容的返回方式，为 false 时思考仍然留在 content 的 <think> 标签里。别把它和 thinking 参数混为一谈。
Anthropic 那一侧的形态干净一些：response.content 本身就是一个内容块列表，thinking、text、tool_use 各自是独立的块，你要做的是把整个列表原样回带。文档在 Messages 字段支持表里也单列了 type="thinking"，说明是「推理内容，多轮 thinking 对话中需要原样回带」。
从工程角度看，Anthropic 侧的结构化块比在字符串里找标签更不容易出错，这大概是很多人选它的实际理由——但再强调一次，这是我的判断，不是官方给的推荐理由。
被忽略的参数清单不一样，而且「忽略」不报错
这是选型时最该逐条核对的一节：两页的「注意事项」里各自列了一份会被忽略的参数清单，两份清单的内容并不重合。
Anthropic 兼容那一侧，文档明确列出了会被忽略的参数：top_k、stop_sequences、mcp_servers、context_management、container。这几个的支持状态一栏写的都是「忽略」，说明栏写的是「该参数会被忽略」。
OpenAI 兼容那一侧，注意事项里列的是另一批：部分 OpenAI 参数（如 presence_penalty、frequency_penalty、logit_bias 等）会被忽略；另外 n 参数仅支持值为 1；旧版的 function_call 已废弃，官方要求改用 tools 参数。
这里有个必须点破的机制细节：文档用的词是「忽略」，不是「报错」。参数带上去请求照样成立，只是不生效。这类问题在日志里是看不出来的——你以为设了停止序列，实际模型压根没收到这个约束；你以为挂了 MCP 服务，实际那一段配置被丢掉了。它不像鉴权失败那样当场炸给你看，而是安静地让行为偏离预期。
所以选型时的判据很直接：把你现有代码里实际用到的参数列出来，跟上面两份清单对一遍。如果你重度依赖 stop_sequences 或者 mcp_servers，Anthropic 兼容层这边是拿不到的，得考虑在应用层自己实现，或者改走别的形态。如果你在用 n 一次要多个候选，OpenAI 兼容层这边也满足不了，因为它只支持 1。
两侧确实一致的地方也有：temperature 的取值范围在两页里写的是同一个区间，都注明超出范围会返回错误；top_p 的默认值两页都区分了 M3 和 M2.x 系列，给的说明一致，具体数值以官方文档当前版本为准。
多模态与 token 预估：两侧都有预估端点，但路径不同
多模态的支持边界在两侧是一致的，都卡在模型上而不是卡在 SDK 上：只有 M3 支持图片和视频输入，M2.7、M2.5、M2.1 和 M2 系列仅支持文本与工具调用相关的内容块，不支持图片和视频。OpenAI 那一页还额外注明了一句「当前不支持音频输入」。
内容块的写法不同。OpenAI 侧用的是 image_url 和 video_url 内容块，detail 字段可取 low、default、high 三个值，另有 max_long_side_pixel 用来控制最长边，视频还有 fps 可调。Anthropic 侧用的是 type="image" 和 type="video" 这样的块类型。两侧都说明了：超过内联上限的视频要先通过 Files API 上传，再用 mm_file://{file_id} 的形式传入，具体体积上限以官方文档为准。
token 预估这件事，两侧都做得到，差的是端点路径和它挂在哪一页，别按「一侧有、一侧没有」去理解。
Anthropic 兼容那一侧写在正文里：POST /anthropic/v1/messages/count_tokens，官方说明是可用于 MiniMax-M3 调用前预估输入 token 用量，不会生成模型输出。OpenAI 兼容那一侧，SDK 那一页在讲图片 token 用量时只写了「准确用量以响应中的 usage 或可用的 token 计数接口为准」，确实没在那一页给出路径——但路径在另一页：Responses API 的「Token 估算」端点 POST /v1/responses/input_tokens，OpenAPI 段里的 servers 地址就是 https://api.minimaxi.com，也就是 OPENAI_BASE_URL 那个 /v1 前缀底下。官方对它的描述是：估算请求的输入 token 数，不真正调用模型生成，常用于在调用主接口前评估请求成本与是否触发上下文长度上限；请求体示例里的 model 写的就是 MiniMax-M3。
所以如果你要在请求发出去之前做成本估算或长度裁剪——比如判断这一轮上下文塞不塞得下、要不要先做摘要——两条路都能做，只是得去对的那一页找。习惯了 chat.completions 心智模型的人，很容易在 OpenAI SDK 那一页翻半天没找到，就得出「OpenAI 侧没有预估接口」的结论，然后为此换掉整套 SDK，那是多余的功夫。切换形态之前先把两页都翻一遍，比照着单页下结论稳得多。想了解通用的成本核算思路，可以对照看换厂商前的迁移核对清单。
缓存：自动的两边都有，主动的要看 cache_control 和模型清单
MiniMax 把缓存分成了两种，文档里用词很明确。
一种叫自动缓存，是被动的，自动识别重复的上下文内容，无需更改接口调用方式。Prompt 缓存那一页给了两个并列的代码示例页签，Anthropic SDK 和 OpenAI SDK 都有，说明这条路两侧都走得通。
这里要先破一个常见的误会：自动和主动的分界线是有没有显式设置 cache_control，不是你打的哪个端点。证据就在同一页上——自动缓存那一页给的第一个示例用的是 Anthropic SDK，模型写的是 MiniMax-M3，全程没有出现 cache_control，走的仍然是自动缓存。所以「OpenAI 端点等于自动、Anthropic 端点等于主动」这种二分法是错的，别拿它当选型依据。
另一种叫主动缓存，文档的原话是「在 anthropic API 中使用的需要显式设置参数的缓存模式，我们称之为主动缓存」。它的用法是在内容块上挂 cache_control 块，命中情况通过响应 usage 里的 cache_creation_input_tokens 和 cache_read_input_tokens 两个字段体现——前者是这次写入缓存的量，后者是这次从缓存读到的量，看这两个字段就能判断缓存到底有没有起作用。计费口径上，两种缓存的相同点是缓存读取按优惠价计费；不同点是主动缓存的首次写入需要额外计费，自动缓存的写入部分文档写的是无额外计费。具体单价与相对关系见官方定价页，本文不列。过期行为也不一样：自动缓存由系统按负载自动调整过期时间，主动缓存有一个明确的过期时长且持续使用会自动续期，具体时长以官方文档当前版本为准。
这条差异的结论必须连着模型边界一起看，否则会选错。主动缓存那一页的「支持的模型和定价」表里，列出来的是 M2.7、M2.5、M2.1 各自的标准版与 highspeed 版，再加上 M2；Prompt 缓存页结尾的 Cache 对比表写法一致，主动缓存那一栏是 M2.7 系列、M2.5 系列、M2.1 系列、M2 系列——两处都不含 M3，而同一张表里被动缓存那一栏是含 M3 的。
所以正确的说法是：如果你要精确控制哪一段内容进缓存（比如把一份很长的固定文档钉住、只让用户提问那部分变化），主动缓存是 Anthropic 兼容形态下的能力，且你选的模型得在上面那份清单里。如果你正打算用 M3，官方文档目前在这两页给出的是自动缓存这条路，那就别把「要显式缓存」当成选 Anthropic 兼容的理由——因为在 M3 上这条理由不成立。想搞清楚缓存计费的通用逻辑，可以看缓存计费机制怎么算。
service_tier 两侧一致，这块不用担心
有一个参数在两页里的描述是完全对齐的：service_tier，用于指定请求的准入服务层级，取值是 standard 和 priority，省略时默认使用 standard。文档说明 priority 会确保请求获得优先准入，排在其他请求之前处理。两页也都注明了 priority 的价格高于 standard，并把具体数值指向了官方定价页，本文同样不列。
对选型来说这是好消息：这块逻辑换 SDK 不用重写，参数名和取值都一样。
怎么选，以及切换时该改哪几处
把上面的差异压成一张决策路径：
倾向 Anthropic 兼容——新项目从零开始；需要 cache_control 做主动缓存，并且你要用的模型在主动缓存那份支持清单里（这份清单不含 M3）；多轮工具调用里 thinking 内容较多，希望拿结构化的内容块而不是从 <think> 标签里抠。另外，官方入门文档只覆盖了这条路，遇到问题时可参照的官方示例更多。具体接法可以看用 Anthropic SDK 接入 MiniMax。
倾向 OpenAI 兼容——你已经有成规模的 OpenAI 生态代码，改 Base URL 和模型名就能跑；团队熟悉 chat.completions 那套心智模型；不依赖 stop_sequences、mcp_servers，也不需要 n 大于 1。
如果决定从一侧切到另一侧，改动清单就这几项，按顺序过：
- 环境变量名和 Base URL 路径前缀（
/v1与/anthropic不通用），顺带确认域名选的是国内还是国际那个 thinking参数——两侧默认值相反，切换后一律显式传，别依赖默认- thinking 内容的回传形态——是保留
<think>标签的content字段，还是原样回带内容块列表 - 被忽略的参数清单——按上面两份清单逐条核，忽略是静默的，不会报错
- 如果用了主动缓存，确认你要用的模型在主动缓存的支持清单里；如果用了调用前的 token 预估，把端点路径换成目标形态的那一个（
/anthropic/v1/messages/count_tokens与/v1/responses/input_tokens不通用）
最后提醒一件容易想当然的事：兼容层不是全模态入口。两页各自的「支持的模型」表里，列的都只有 M 系列语言模型；Anthropic 兼容那一页说得更直白，在列完支持的模型之后补了一句「如需使用其他模型，请使用标准的 MiniMax API 接口。」OpenAI 那一页在相同位置的措辞要弱一些，写的是「更多模型信息请参考标准的 MiniMax API 接口文档。」措辞强弱不同，但两页的模型表已经把边界划出来了：视频、语音、图像、音乐这些能力不在这张表里，你要用就得回到 MiniMax 原生接口。别以为配好了一套 SDK 就把整个平台都接通了。