1. 从 Token Plan 到 M Plan这次改动到底动了谁的蛋糕如果你最近半年一直在用 MiniMax 的 API 做多模态应用大概率对 Token Plan 那套按模态分别计费的模式又爱又恨。文本一个价、语音一个价、视频再单独算一笔做一个小型对话机器人还好一旦项目里同时涉及文本生成、语音合成和视频理解账单就像开盲盒月底看到数字才知道自己花了多少。M Plan 出来之后我第一时间把手上三个在跑的项目全部迁了过去原因很简单全模态额度大一统一个额度池覆盖文本、语音、视频不用再为每个模态单独充值、单独监控余量。这件事的意义不只是省事。从工程角度看多模态项目最麻烦的从来不是模型能力而是成本核算和额度管理。以前做预算我得给文本留一笔、给语音留一笔、给视频留一笔三笔钱互相不能挪用文本额度用超了语音还剩一堆只能干瞪眼。M Plan 把这三笔钱合成一笔本质上把模态从计费维度里拿掉了只按实际消耗折算。对于做 Agent、做多模态 RAG、做视频理解管线的团队来说这是实打实的成本结构优化。另一个被讨论很多的是H3 视频解禁。之前 H3 系列的视频能力在部分套餐里是受限的要么额度另算要么干脆不开放。这次 M Plan 把 H3 的视频生成能力纳入统一额度意味着你可以用同一个 Key 跑文本对话、跑语音、再跑视频生成不用在多个控制台之间来回切换。我实测下来H3 在 20 系显卡上的优化确实有感知本地推理的显存占用比上一代友好不少这对想在本地跑视频生成的开发者是个好消息。至于标题里提到的免密打通 Claude Code 与 Cursor这是很多人真正关心的部分。Claude Code 和 Cursor 本身是两套独立的开发工具前者偏向终端里的 Agent 式编码后者是 IDE 里的 AI 辅助。把它们接到同一个模型后端上意味着你在终端里让 Claude Code 改的代码和在 Cursor 里让 AI 补全的代码走的是同一套模型能力风格和上下文理解更一致。下面我会把整个迁移过程、配置细节、踩过的坑全部摊开讲。提示本文所有配置均基于公开的 API 接入方式涉及 Key 的部分请务必自己保管不要提交到任何公开仓库。2. M Plan 的核心设计逻辑为什么是大一统而不是多套餐2.1 多模态计费的历史包袱要理解 M Plan 为什么这么设计得先看 Token Plan 时代的问题。Token Plan 的逻辑是按模态分账文本走文本的 token 计费语音按时长或字符计费视频按生成秒数或分辨率计费。这套逻辑在单一模态场景下没问题但多模态应用天然是混合调用的。一个典型的视频理解 Agent流程是视频抽帧 → 图像理解 → 文本总结 → 语音播报。这一条链路下来跨了三个模态如果每个模态单独计费成本核算就变成了一个跨系统的对账问题。更麻烦的是额度隔离。假设你买了 100 万文本 token 和 1000 秒视频额度结果这个月文本只用了 30 万视频却超了 200 秒。超出的部分要么按量付费通常单价更高要么直接失败。你没法把文本没用完的额度挪给视频。这种刚性隔离在小规模测试时无所谓一旦上生产就是灾难。M Plan 的做法是把所有模态折算到一个统一的额度单位上。具体折算比例官方有说明我这里不重复重点是这个设计带来的工程收益你只需要监控一个余额数字。做预算时不用再拆三份做告警时不用再设三个阈值做成本归因时也只需要看一个消耗曲线。对于小团队来说这直接省掉了一个额度管理的模块。2.2 H3 视频解禁的技术背景H3 是 MiniMax 的视频生成系列这次解禁我理解有两层含义。第一层是套餐层面的解禁之前 H3 的视频能力在部分套餐里是单独收费或不开放的现在纳入 M Plan 统一额度。第二层是本地部署层面的优化热词里频繁出现的minimax h3 20系显卡优化minimax h3 mem eff s说明社区对本地推理的显存效率很关注。我拿一张 2080 Ti 试了本地部署显存占用比预期低。这里的关键是 H3 在注意力机制和 VAE 解码上做了内存效率优化具体来说是在时间维度上做了分块处理不需要一次性把整个视频序列的中间激活都放在显存里。这个优化对消费级显卡很重要因为视频生成的显存瓶颈往往不在模型权重而在中间激活。如果你之前因为显存不够放弃本地跑视频现在可以重新试试。注意本地部署的显存需求跟分辨率、帧数、batch size 强相关。5 秒 720p 和 5 秒 1080p 的差距可能是一倍以上。建议先用最低配置跑通再逐步往上调。2.3 免密打通的技术路径免密这个词容易让人误解它不是说不需要 API Key而是说不需要在多个工具里重复配置 Key。Claude Code 和 Cursor 各自有自己的配置方式传统做法是在每个工具里单独填 Key、单独选模型。免密打通的思路是把模型接入层抽出来让两个工具都指向同一个本地代理或同一个环境变量。具体实现上Claude Code 支持通过环境变量指定 API 端点和 KeyCursor 支持在设置里配置自定义模型。你可以把 MiniMax 的 API 端点配成一个兼容层然后让两个工具都走这个兼容层。这样你只需要维护一份 Key 和一份端点配置换模型时改一处即可。下面会详细讲怎么配。3. 手把手配置从零把 MiniMax 接进 Claude Code3.1 环境准备与依赖安装先说环境。Claude Code 目前主流的使用方式是通过 npm 安装 CLI然后在终端里运行。我用的环境是 Ubuntu 22.04Windows 10 和 macOS 也都能跑差异主要在路径和权限上。第一步是确认 Node.js 版本。Claude Code 对 Node 版本有要求建议 18 以上。用node -v看一下如果低于 18先升级。升级方式看你的系统Ubuntu 上我一般用 nvm 管理Windows 上直接去官网下安装包。node -v npm -v第二步是安装 Claude Code CLI。官方推荐全局安装npm install -g anthropic-ai/claude-code装完之后运行claude --version确认。如果提示命令找不到检查 npm 的全局 bin 目录是否在 PATH 里。Ubuntu 上通常是~/.npm-global/bin或/usr/local/binWindows 上是%APPDATA%\npm。提示如果你在公司网络环境下npm 安装可能因为镜像源问题变慢。可以临时切到国内镜像源但装完建议切回来避免后续包版本不一致。3.2 配置 MiniMax 作为模型后端Claude Code 默认走的是 Anthropic 的官方端点要换成 MiniMax需要设置环境变量。核心是两个ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY。前者指向 MiniMax 提供的兼容端点后者填你的 MiniMax API Key。export ANTHROPIC_BASE_URLhttps://api.minimax.chat/v1 export ANTHROPIC_API_KEY你的MiniMax API Key这里有个细节MiniMax 的兼容层对 Anthropic 协议的支持程度决定了 Claude Code 能不能正常工作。我实测下来基础的对话和工具调用是通的但一些高级特性比如某些特定的 tool use 格式可能有差异。如果你遇到工具调用失败先检查是不是协议兼容问题而不是 Key 的问题。把这两行写进~/.bashrc或~/.zshrc这样每次开终端都自动生效。Windows 上在系统属性 → 环境变量里加或者用 PowerShell 的$env:语法临时设置。# 写入 bashrc echo export ANTHROPIC_BASE_URLhttps://api.minimax.chat/v1 ~/.bashrc echo export ANTHROPIC_API_KEY你的Key ~/.bashrc source ~/.bashrc配完之后在终端里直接运行claude它应该会用 MiniMax 的模型来响应。你可以问一个简单问题测试比如帮我写一个 Python 的快速排序看返回是否正常。3.3 VS Code 里跑 Claude Code 的注意事项热词里有vscode配置claude codeclaude code for vs code说明很多人想在 VS Code 里用。Claude Code 本身是 CLI 工具但可以在 VS Code 的集成终端里跑。这样你既能用 VS Code 的编辑器又能在终端里让 Claude Code 操作文件。配置要点是VS Code 的集成终端会继承系统的环境变量所以你在 bashrc 里配的那两个变量在 VS Code 终端里也生效。如果没生效检查 VS Code 是不是从图形界面启动的有些桌面环境不会加载 bashrc。解决办法是在 VS Code 的settings.json里显式配置终端环境变量{ terminal.integrated.env.linux: { ANTHROPIC_BASE_URL: https://api.minimax.chat/v1, ANTHROPIC_API_KEY: 你的Key } }Windows 上把linux换成windows。这样不管从哪启动终端里都有这两个变量。注意把 Key 写在 settings.json 里意味着它会以明文存在磁盘上。如果这台机器是共享的建议用系统环境变量而不是 settings.json。4. Cursor 接入 MiniMax中文设置与自定义模型4.1 Cursor 的中文回复设置热词里cursor怎么设置中文回复cursor中文怎么设置cursor汉化出现频率很高说明这是很多人的痛点。Cursor 的界面语言和模型回复语言是两回事要分开设置。界面汉化Cursor 基于 VS Code所以汉化方式和 VS Code 一样。装一个中文语言包扩展然后在命令面板里选Configure Display Language选中文重启。具体步骤是CtrlShiftP打开命令面板输入Configure Display Language选择zh-cn。如果没有中文选项先去扩展市场搜Chinese装语言包。模型回复中文这个不是 Cursor 的设置而是提示词层面的控制。你可以在 Cursor 的设置里找到Rules for AI或自定义指令的地方加一句请始终用中文回复。更稳妥的做法是在项目根目录放一个.cursorrules文件里面写明语言要求。这样每次对话都会带上这个指令。请始终使用简体中文回复。 代码注释也用中文。实测下来.cursorrules的方式比在设置里写更稳定因为它跟着项目走换项目可以换规则。4.2 配置自定义模型指向 MiniMaxCursor 支持自定义模型这是接入 MiniMax 的关键。在设置里找到Models或AI相关选项开启自定义模型填入 MiniMax 的端点和 Key。具体路径Settings → Models → OpenAI API KeyCursor 用的是 OpenAI 兼容协议。这里填 MiniMax 的 Key然后在Override OpenAI Base URL里填 MiniMax 的兼容端点。Base URL: https://api.minimax.chat/v1 API Key: 你的MiniMax Key Model: 填 MiniMax 支持的模型名配完之后在 Cursor 的模型选择里应该能看到你自定义的模型。选它然后测试对话。如果报错先检查 Base URL 有没有多余的空格再检查 Key 是否有效。提示Cursor 的自定义模型功能在不同版本里位置可能不一样。如果找不到更新到最新版或者在设置里搜custom model。4.3 Claude Code 与 Cursor 共用一套配置免密打通的核心思路是共用环境变量。Claude Code 读的是ANTHROPIC_BASE_URL和ANTHROPIC_API_KEYCursor 读的是它自己设置里的 Base URL 和 Key。两者没法直接共用同一个变量但你可以用同一个 Key只是填在两个地方。更优雅的做法是写一个脚本把 Key 存在一个地方然后分别注入。比如用一个.env文件存 Key然后写个 shell 脚本在启动 Claude Code 前 source 它Cursor 那边手动填一次。这样换 Key 时只需要改一处。# .env MINIMAX_API_KEY你的Key # start-claude.sh source .env export ANTHROPIC_API_KEY$MINIMAX_API_KEY export ANTHROPIC_BASE_URLhttps://api.minimax.chat/v1 claude这样你运行./start-claude.sh就能带着正确的 Key 启动 Claude Code。Cursor 那边因为是一次性配置换 Key 频率低手动改可以接受。5. 实操避坑那些文档里不会写的问题5.1 常见报错与排查热词里有个很具体的报错llm-deepseek: no api key for provider route deepseek-official。这个报错的意思是模型路由找不到对应的 API Key。虽然它提的是 deepseek但同类问题在接 MiniMax 时也会遇到本质是路由配置和 Key 不匹配。排查思路是先确认你配的 Base URL 和 Key 是同一家的。有时候你 Key 是 MiniMax 的但 Base URL 还留着别的家的就会报这个错。再确认模型名是否在服务端存在有些兼容层对模型名大小写敏感。报错信息可能原因解决办法no api key for providerKey 未设置或路由不匹配检查环境变量和 Base URL 是否同源401 UnauthorizedKey 无效或过期重新生成 Key确认没有多余空格404 Not Found端点路径错误确认 Base URL 是否带 /v1429 Too Many Requests额度用尽或限流检查 M Plan 余额降低并发timeout网络或端点不可达检查网络确认端点地址正确5.2 额度监控与成本控制M Plan 虽然统一了额度但不代表可以随便造。视频生成的消耗远大于文本一条 5 秒视频的额度可能顶几千次文本对话。所以监控还是必要的。我的做法是写一个简单的脚本定时调 MiniMax 的余额查询接口把数字打到日志里。一旦低于阈值就发通知。这样不用天天登录控制台看。import requests import os API_KEY os.environ.get(MINIMAX_API_KEY) resp requests.get( https://api.minimax.chat/v1/balance, headers{Authorization: fBearer {API_KEY}} ) print(resp.json())具体接口路径以官方文档为准这里只是示意。重点是养成监控习惯别等跑崩了才发现额度没了。注意视频生成任务通常是异步的提交后要轮询结果。轮询频率别太高否则可能触发限流。我一般设 5 秒一次最多轮询 60 次。5.3 本地部署 H3 的显存调优如果你要在本地跑 H3 视频生成显存是第一个坎。我的经验是先用最低分辨率、最少帧数跑通确认流程没问题再逐步加参数。20 系显卡上720p 5 秒的视频显存占用大概在 8-10G 左右具体看优化程度。如果显存不够可以试这几个方向降低分辨率、减少帧数、开启内存效率模式如果模型支持、用半精度推理。半精度通常能省一半显存但可能影响生成质量需要自己权衡。# 伪代码示意具体 API 以官方为准 model load_model(minimax-h3, precisionfp16, mem_efficientTrue) video model.generate(prompt, resolution720p, frames120)热词里minimax h3 mem eff s应该就是指内存效率相关的选项开启后显存占用会明显下降代价是速度可能慢一点。这个取舍看你的硬件。6. 多模态额度统一后的项目架构调整6.1 从分模态调用到统一网关M Plan 统一额度后项目架构可以做一次简化。以前为了分别管理三个模态的 Key 和额度很多团队会写一个模态路由层根据请求类型分发到不同的客户端。现在可以把这个层去掉所有请求走同一个客户端只是调不同的接口。这个简化带来的好处是代码量减少、配置项减少、出错点减少。坏处是如果某个模态出问题影响面会变大。所以建议保留一个轻量的降级逻辑视频生成失败时至少保证文本和语音链路不受影响。6.2 成本归因的新做法统一额度后成本归因不能再看文本花了多少、视频花了多少因为额度是一个池子。替代做法是在应用层打点每次调用记录模态、消耗量、时间戳然后自己算占比。这样虽然多写一点代码但归因更准确也能发现哪个模态是消耗大户。我一般用一个简单的日志表字段是时间、模态、消耗单位、请求 ID。跑一周就能看出消耗分布然后针对性优化。比如发现视频生成占了 80% 的额度那就重点优化视频的提示词和参数减少无效生成。6.3 多工具共存的协作模式Claude Code 和 Cursor 接同一个后端后可以形成一种协作模式在 Cursor 里做日常编码和补全遇到需要大范围重构或批量操作时切到 Claude Code 在终端里跑。两者用同一个模型理解上下文的方式一致切换成本低。我自己的习惯是写新功能用 Cursor因为补全快改老代码、做重构用 Claude Code因为它能直接操作文件系统批量改更高效。两者都指向 MiniMax不用担心中间换模型导致风格突变。提示如果你同时开着 Cursor 和 Claude Code注意别让它们同时改同一个文件否则可能冲突。我的做法是改代码时只开一个另一个先关掉或暂停。7. 一些实测下来的经验与建议迁移到 M Plan 之后我最大的感受是心智负担降低了。以前要记三个额度、三个端点、三套配置现在只有一个。这种简化对个人开发者尤其友好因为你不用再花时间在管理上可以专注在开发上。H3 的视频能力纳入统一额度后我试了几个视频理解的小项目比如把一段产品演示视频丢进去让它生成文字摘要和语音解说。整条链路走同一个 Key调试起来很顺。视频生成的提示词我一般控制在 50-100 字太短效果不稳定太长模型可能抓不住重点。热词里有人问生成5秒视频提示词需要多少字我的经验是 60 字左右比较合适描述清楚主体、动作、场景三个要素就够了。Claude Code 和 Cursor 的配置最容易出问题的地方是环境变量没生效。尤其是 Windows 上图形界面启动的程序不一定读系统环境变量。遇到这种情况先在一个干净的终端里echo $ANTHROPIC_API_KEY看看有没有值没有就说明配置没生效去检查是写错了文件还是没 source。最后说一个我踩过的坑MiniMax 的兼容端点对请求格式有要求如果你从别的家迁过来请求体里的某些字段可能不兼容。比如有的家支持max_tokens有的家叫max_output_tokens。迁移时先跑一个最小请求确认格式对了再批量改。这个坑我花了半小时才定位到希望你别再踩。