1. 从 Token Plan 到 M Plan这次额度体系到底改了什么如果你最近一直在用 MiniMax 的 API 做开发大概率已经注意到一个明显的变化过去那套按 Token 单独计费、按模态分别扣额度的逻辑正在被一套更统一的东西取代。这就是 M Plan。我第一时间把自己的几个项目从旧的 Token Plan 迁到了 M Plan迁移过程比想象中顺但中间有几个细节如果不注意很容易在账单上吃亏。先说结论层面的东西。M Plan 最核心的变化是把文本、语音、视频这几类模态的额度做了大一统。以前你做多模态应用文本对话扣文本的额度语音合成扣语音的额度视频生成再单独算一笔三套账本各管各的月底对账的时候得把三张表拼起来看。M Plan 把这件事简化成了一本账你充进去的额度是一个池子不同模态按各自的换算比例从这个池子里扣。对做全模态应用的团队来说这个改动省掉的不只是对账时间更重要的是预算规划变得可预测了——你不用再猜这个月视频会烧掉多少、文本会烧掉多少只需要盯住一个总盘子。另一个被讨论很多的点是 H3 视频解禁。之前 H3 系列的视频生成能力在额度体系里是受限的很多开发者想拿它做长一点的视频或者批量生成额度根本不够用。M Plan 之后H3 的视频生成被正式纳入统一额度配合 H3 本身在显存效率上的优化本地部署和云端调用两条路都变得可行了。我实测下来H3 在 20 系显卡上做推理显存占用比上一代方案低了一截这对还在用老卡的用户来说是个实打实的利好。那这套东西适合谁我的判断是三类人最该关注一是做多模态产品的独立开发者二是需要把 AI 能力接进现有工作流的技术团队三是想用 Claude Code、Cursor 这类工具但又不想被单一模型绑死的重度用户。前两类关心的是成本和额度第三类关心的是怎么把 MiniMax 的模型接进自己日常写代码的工具链里。这篇我就把这三件事串起来讲重点放在最后一件上——怎么免密打通 Claude Code 和 Cursor让它们直接调用 MiniMax 的模型。提示M Plan 的额度换算比例会随官方策略调整迁移前建议先在小额度账户上跑一遍确认自己常用模态的扣费比例再决定要不要一次性把大额度迁过去。2. 全模态额度大一统背后的账本逻辑2.1 为什么一本账比三本账更难做但更值得做很多人以为把多个模态的额度合并成一个池子技术上就是加个字段的事。实际不是。不同模态的计算成本差异极大一段十秒的视频生成消耗的算力可能是几万次文本对话的量级。要把它们塞进同一个额度池平台必须设计一套换算系数让每个模态的消耗都能折算成统一的额度单位。这套换算系数怎么定直接决定了你用起来是赚还是亏。我的经验是如果你的应用以文本为主、视频为辅M Plan 通常比旧的分离计费更划算因为文本的换算系数相对低你相当于用文本的低成本去补贴了偶尔的视频调用。反过来如果你的应用是视频密集型那就得仔细算一下因为视频的换算系数高统一池子意味着视频会更快地吃掉你的总额度。这里有个实操上的坑迁移的时候旧账户里剩余的文本额度、语音额度、视频额度折算成 M Plan 额度的比例是不一样的。我见过有人直接把三个数字加起来当成新额度结果发现实际到账少了一截。正确的做法是分别看每一类额度的折算率尤其是视频额度折算率往往和文本不同。2.2 H3 视频解禁在额度层面的真实影响H3 解禁这件事表面看是视频能用了深层看是视频的边际成本降了。H3 这一代在架构上做了显存效率的优化同样的视频生成任务占用的显存和算力都比前代低。这意味着两件事第一云端调用的单价有下降空间第二本地部署的门槛降低了。我拿一台 2080 Ti 的机器试过 H3 的本地推理在合理设置分辨率和帧数的前提下跑短片段是能跑起来的。当然你要是想跑高分辨率长视频老卡还是吃力这个得实事求是。但对于做原型验证、做小批量生成的场景20 系显卡已经够用了。这也是为什么minimax h3 20系显卡优化会成为热词——大家关心的不是能不能跑而是怎么在老卡上跑得不那么痛苦。具体到额度消耗H3 视频生成在 M Plan 里是按生成时长和分辨率综合计算的。我建议的做法是先用低分辨率短时长做提示词调试确认效果满意了再用高分辨率出终版。因为提示词调试阶段往往会生成很多废片如果一上来就用高分辨率额度会掉得很快。这个习惯能帮你省下相当可观的额度。2.3 迁移 M Plan 时我踩过的两个坑第一个坑是自动续费。旧 Token Plan 如果开了自动续费迁移到 M Plan 之后续费逻辑不一定自动跟着变。我有一次就是迁移完忘了检查结果旧套餐又扣了一笔。迁移后第一件事去账单页面确认自动续费的状态该关的关该改的改。第二个坑是额度有效期。M Plan 的额度有效期规则和旧套餐可能不同。如果你的项目是阶段性的比如集中两个月开发然后停一段时间那就要注意额度会不会过期。我的做法是把大额度拆成几次充而不是一次性充很多这样即使有效期规则变了损失也可控。3. 免密打通 Claude Code 与 MiniMax 的完整链路3.1 为什么是免密以及免密到底免的是什么先说清楚免密这个词。这里的免密不是说不做任何认证而是说不用每次调用都手动填 API Key、不用在多个工具之间反复复制粘贴密钥。核心思路是把 MiniMax 的 API Key 配置成环境变量或者写进工具的配置文件让 Claude Code 和 Cursor 在启动时自动读取。为什么值得这么做因为 Claude Code 和 Cursor 这类工具默认是绑定特定模型提供方的。你想让它们调用 MiniMax 的模型就得改配置。如果每次开新项目都要重新配一遍效率极低而且容易把 Key 泄露到代码仓库里。免密配置的目标是一次配好全局生效且 Key 不进版本控制。我自己的做法是把 Key 放在系统的环境变量里工具配置文件里只引用变量名不写明文。这样即使配置文件被同步到别的地方Key 也不会跟着跑出去。3.2 环境准备API Key 的获取与安全存放第一步是拿到 MiniMax 的 API Key。登录 MiniMax 的开发者后台在 API Key 管理页面创建一个新的 Key。这里有个细节创建 Key 的时候如果平台支持设置权限范围尽量只勾选你实际需要的权限不要图省事给全权限。最小权限原则在 API Key 上同样适用。拿到 Key 之后不要直接写进任何会进 Git 的文件。正确做法是写进环境变量。Linux 和 macOS 下编辑~/.bashrc或~/.zshrc加一行export MINIMAX_API_KEY你的keyWindows 下用系统环境变量设置界面或者 PowerShell 里[Environment]::SetEnvironmentVariable(MINIMAX_API_KEY, 你的key, User)设置完记得重启终端或者 source 一下配置文件让变量生效。验证方法是echo $MINIMAX_API_KEYWindows 用echo %MINIMAX_API_KEY%能打印出来就对了。注意环境变量里的 Key 对当前用户的所有进程可见。如果你在共享服务器上操作要确认其他用户没有权限读取你的环境变量或者干脆用更隔离的方案。3.3 Claude Code 侧的配置从安装到接入 MiniMaxClaude Code 的安装本身不复杂但接入第三方模型这一步很多人卡在配置格式上。我梳理一下完整流程。安装 Claude Code按官方文档走就行。装完之后关键是找到它的模型配置文件。不同版本的 Claude Code 配置文件位置可能不同常见的是用户目录下的隐藏配置文件夹。你需要在这个配置里指定模型提供方为 MiniMax 的兼容接口并把 API Key 指向刚才设置的环境变量。配置的核心是三个东西base URL、模型名称、API Key 引用。MiniMax 提供兼容主流接口规范的端点你需要在配置里把 base URL 改成 MiniMax 的地址模型名称填 MiniMax 对应的模型标识API Key 用环境变量引用而不是明文。这里有个容易忽略的点Claude Code 默认可能会去连它自己的服务你要确保配置改完之后它真的走了 MiniMax 的端点。验证方法是发一条测试消息然后去 MiniMax 后台看调用记录如果有记录说明接通了如果没有说明配置没生效大概率是 base URL 或者模型名写错了。我实测下来配置生效后 Claude Code 的响应速度和稳定性都还不错尤其是文本类的代码生成和解释任务。但要注意Claude Code 有些高级功能可能依赖特定模型的能力换成 MiniMax 之后不一定全部可用这个要有心理预期。3.4 Cursor 侧的配置自定义模型与中文回复设置Cursor 这边的情况稍微不同。Cursor 支持自定义模型你可以在设置里添加 MiniMax 作为模型提供方。步骤大致是打开 Cursor 设置找到模型配置区域添加一个新的模型提供方填入 MiniMax 的 base URL 和 API Key然后选择对应的模型。配置好之后Cursor 的对话和代码补全就可以走 MiniMax 了。但这里有个热词里反复出现的问题Cursor 怎么设置中文回复。默认情况下Cursor 的回复语言可能跟随你的输入语言也可能固定为英文。要让它稳定用中文回复有两个办法一是在对话里明确用中文提问它通常会跟着用中文二是在 Cursor 的设置里找语言相关选项或者用自定义指令custom instructions明确要求用中文回复。我自己的做法是在项目的规则文件里写一条所有回复使用简体中文。这样每次对话都会带上这个指令回复语言就稳定了。这个技巧对 Claude Code 同样适用在它的配置里加一条语言偏好能省掉每次都要提醒的麻烦。还有一个热词是cursor 注册时手机号怎么填写。这个属于账号注册环节的问题不同地区的号码格式要求不同按页面提示的格式填就行。如果遇到收不到验证码的情况先检查号码格式再检查网络环境多数是格式问题。3.5 验证链路是否真正打通配置完之后别急着投入正式使用先做一轮验证。我的验证清单是这样的验证项操作方法预期结果环境变量生效终端打印 Key 变量能正确输出Claude Code 连通发一条测试对话有回复且后台有调用记录Cursor 连通在编辑器里提问有回复且模型标识正确中文回复用中文提问回复为中文额度扣减查看 M Plan 额度有对应消耗这一轮跑下来基本就能确认链路是通的。如果某一项不对就回到对应的配置环节排查。最常见的失败点是 base URL 写错或者模型名不匹配这两个占了我遇到问题的八成以上。4. 本地部署 H3 与老显卡的适配实战4.1 什么情况下值得本地部署本地部署 H3 不是所有人都需要。我的判断标准是如果你对数据不出本地有硬性要求或者你的调用量极大、云端成本算下来不划算那本地部署值得考虑。否则直接用 M Plan 的云端额度更省心。本地部署的另一个价值是调试方便。你在本地可以随便试提示词、随便调参数不用担心额度消耗。等效果调好了再决定是继续本地跑还是转云端。这种本地调、云端跑的组合是我目前用得最多的模式。4.2 20 系显卡上的显存优化思路20 系显卡的显存普遍在 8G 到 11G 之间跑视频生成确实紧张。但 H3 这一代在显存效率上做了优化配合一些设置技巧是能跑起来的。核心思路是降低单次生成的资源占用降低分辨率、缩短生成时长、减少并行任务数。具体来说我建议先把分辨率降到能接受的最低值把时长控制在短片段确认能跑通之后再逐步往上加找到你那张卡的极限。这个过程有点像调游戏画质先保证帧率再慢慢加特效。另外显存不足的时候可以开启一些内存卸载的选项把部分计算放到内存里。代价是速度会慢但至少能跑起来。对于不追求实时性的场景这个取舍是值得的。4.3 本地部署的常见报错与排查本地部署最容易遇到的报错是显存不足OOM。遇到这个先别急着换卡按顺序排查是不是分辨率设高了、是不是并行任务开多了、是不是有其他程序占着显存。我见过有人一边开着游戏一边跑推理然后抱怨显存不够这种就是自己给自己找麻烦。第二类常见报错是依赖版本冲突。H3 的部署对某些库的版本有要求装错版本会报各种奇怪的错。我的习惯是严格按照官方文档给的版本清单来装不要自作主张升级或降级。如果已经装乱了最干净的办法是新建一个虚拟环境重装。第三类是模型文件损坏或不完整。下载大文件的时候网络中断会导致文件不完整加载时报错。解决办法是校验文件哈希对不上就重新下载。5. 把 MiniMax 接进日常开发流的几个实用技巧5.1 用 CLI 做批量任务MiniMax 提供了 CLI 工具适合做批量任务。比如你要批量生成一批视频或者批量处理一批文本用 CLI 写个脚本比在图形界面里一个个点要高效得多。CLI 的好处是可以和 shell 脚本结合做定时任务、做流水线。我用 CLI 最多的场景是批量文本处理。把待处理的文件放在一个目录里写个循环脚本逐个调用结果输出到另一个目录。整个过程无人值守跑完检查结果就行。5.2 多模型切换的配置管理实际开发中你不太可能只用 MiniMax 一个模型。有时候要用这个有时候要用那个。如果每个工具的配置都写死一个模型切换起来很麻烦。我的做法是把不同模型的配置写成不同的配置文件用的时候切换配置文件而不是改配置内容。更进一步可以用环境变量来控制当前使用哪个模型。工具启动时读取环境变量决定加载哪套配置。这样切换模型只需要改一个环境变量不用动任何配置文件。5.3 额度监控与成本控制M Plan 额度大一统之后监控变得更简单了但也更容易不知不觉用超。我的做法是设置一个额度预警用到某个比例的时候提醒自己。另外把开发和生产的 Key 分开开发用的 Key 额度小一点生产用的额度大一点这样即使开发环境出问题也不会影响生产额度。还有一个习惯定期看调用记录找出消耗最大的调用类型。有时候你会发现某个功能在偷偷烧额度比如某个定时任务调用频率过高或者某个提示词导致模型生成了超长回复。找到这些额度黑洞优化掉成本能降不少。6. 迁移与接入过程中那些没人告诉你的细节6.1 配置文件里的字段冲突Claude Code 和 Cursor 的配置文件里有些字段是互斥的。比如你同时指定了默认模型和自定义模型提供方工具可能不知道该用哪个。我遇到过配置写了两处模型设置结果工具用了错的那个排查了半天才发现是字段冲突。解决办法是配置尽量精简一个设置只在一处定义。改配置的时候先备份原文件改完对比一下确认没有引入重复或冲突的字段。6.2 版本升级带来的配置失效Claude Code 和 Cursor 都在频繁更新有时候一次升级就会导致原来的配置失效。表现是升级前好好的升级后突然连不上了。遇到这种情况先看更新日志确认配置格式有没有变。多数时候是配置项改名了或者挪位置了按新格式改一下就好。我的习惯是升级前先备份配置升级后如果出问题能快速回滚对比。这个习惯帮我省过好几次重配的时间。6.3 网络环境对调用稳定性的影响调用云端模型网络稳定性直接影响体验。我遇到过调用偶尔超时的情况排查下来是网络抖动。对于关键任务建议加重试逻辑一次失败自动重试而不是直接报错给用户。重试的时候注意加退避不要失败后立刻重试那样可能加重网络负担。另外如果你在多个网络环境之间切换比如公司和家里配置里的端点地址要确认在两边都能访问。有些内网地址换到外网就不通了这个要提前测。6.4 关于 Key 泄露的防范最后强调一下 Key 的安全。我见过太多把 Key 硬编码进代码然后推到公开仓库的案例。防范措施就几条Key 只放环境变量、配置文件里只引用变量名、提交代码前用工具扫一遍有没有疑似 Key 的字符串、定期轮换 Key。如果怀疑 Key 泄露了第一时间去后台吊销旧 Key生成新 Key然后更新环境变量。不要心存侥幸泄露的 Key 可能被人拿去刷额度损失的是你自己。这套从 M Plan 迁移到 Claude Code、Cursor 接入的流程我前后折腾了大概一周才理顺。中间踩的坑基本都写在上面了。如果你刚开始弄建议按顺序来先把 Key 和环境变量搞定再配 Claude Code再配 Cursor最后做验证。一步一步来比一上来就全配要稳得多。