1. 从 Token Plan 到 M Plan这次改动到底动了谁的蛋糕如果你最近两个月一直在用 MiniMax 的 API 做开发大概率经历过这样的场景手上同时跑着文本对话、视频生成、语音合成三条业务线结果每个模态的额度是分开算的文本用超了要单独充值视频额度还剩一大半却没法挪给文本用。这种额度孤岛的体验说实话挺折磨人的。MiniMax 这次把 Token Plan 直接送进历史推出 M Plan核心就一件事——全模态额度大一统。文本、视频、语音、图像所有模态共享同一个额度池你充进去的钱不再被切成一格一格而是变成一个可以自由流动的总量。这件事对谁影响最大我观察下来是三类人。第一类是独立开发者和小团队预算有限最怕的就是这个月视频额度没用完但文本额度爆了还得再掏钱。第二类是做多模态 Agent 的团队一个任务链路里可能同时调用文本理解、图像生成、语音输出额度割裂直接导致成本核算做不清楚。第三类就是像我这样平时用 Claude Code 和 Cursor 写代码偶尔需要调 MiniMax 的模型做辅助生成的人——以前要在好几个平台之间切换看余额现在一个池子搞定。M Plan 的另一个重磅点是H3 视频解禁。之前 H3 的视频生成能力在额度体系里是相对独立甚至受限的现在纳入统一额度后意味着你可以用同一个额度去跑视频生成不用再单独申请或者走特殊通道。这对做短视频批量生产、电商素材生成的人来说是个实打实的利好。H3 本身在运动一致性和分镜连贯性上的表现我在实测中感觉比上一代稳不少尤其是 5 秒左右的短片段提示词写到位的话废片率能压到比较低的水平。但这里有个很多人会忽略的点额度统一不等于成本降低。统一的是池子不是单价。视频生成消耗的额度单位跟文本完全不是一个量级如果你拿统一额度去猛跑视频文本那边可能很快就见底了。所以 M Plan 真正的价值在于灵活性而不是单纯的更便宜。你得根据自己的业务结构重新算一遍额度分配策略。我后面会专门讲怎么算这笔账。还有一个变化值得单独拎出来说M Plan 对 Claude Code 和 Cursor 这类编码工具的接入做了优化。以前你想在 Claude Code 里调 MiniMax 的模型得手动配 API Key、改配置文件、处理各种路由问题稍不注意就报no api key for provider route这种错。现在 M Plan 的 Key 管理更集中配合一些免密打通的方式整个接入流程顺畅了很多。这也是我这篇博文要重点拆解的部分——怎么把手上的工具链跟 M Plan 接起来少走弯路。2. M Plan 额度池的底层逻辑与成本重算方法2.1 统一额度池不是一锅炖而是分层计量很多人一听全模态额度大一统第一反应是那是不是文本和视频一个价了不是的。M Plan 的统一额度池底层还是按模态分别计量消耗只是把充值入口和余额展示合并了。你可以理解成以前你有三张不同颜色的储值卡分别只能在三个店用现在变成一张通用卡但每个店的扣费标准还是不一样的。具体来说文本类调用对话、补全、embedding消耗的额度单位最低图像生成次之视频生成最高语音合成介于文本和图像之间。这个排序是符合算力成本逻辑的——视频生成要跑扩散模型帧间一致性还要额外计算成本自然高。所以你在规划额度时不能简单按调用次数来估而要按模态权重来算。我自己的做法是建一个简单的换算表把每个模态的单次典型消耗列出来然后根据业务量预估月度总消耗。比如模态典型单次消耗相对单位月调用量预估月消耗小计文本对话150000 次50000图像生成82000 次16000视频生成5秒120300 次36000语音合成38000 次24000合计--126000这张表的关键不是数字本身而是让你看清楚哪个模态在吃你的额度。我见过不少人以为文本调用量大所以最耗额度结果一算发现视频才是大头。M Plan 统一之后这种看不见的消耗更容易被忽略因为余额是一个总数你不太容易感知到是哪个模态在快速抽水。提示M Plan 后台一般会提供按模态的消耗明细建议每周看一次。如果发现某个模态消耗异常先查是不是有循环调用或者重试逻辑没做好。2.2 重算成本时最容易踩的三个坑第一个坑是把统一额度当成无限额度。以前分模态的时候视频额度用完了你会收到明确提示现在统一了视频猛跑可能把文本的份额也吃掉等你发现文本调不通的时候余额已经见底了。所以一定要设置模态级预警比如视频消耗达到总额度 40% 就提醒自己。第二个坑是忽略重试和失败调用的消耗。视频生成尤其明显一次失败的生成如果已经跑了部分推理额度是照扣的。H3 虽然稳定性提升了但提示词写得不好、分镜逻辑混乱的时候废片率还是会上去。我的经验是视频生成前先用文本模型把分镜脚本过一遍确认逻辑通顺再提交能省不少冤枉额度。第三个坑是没算上并发带来的额外开销。如果你用 Claude Code 或者 Cursor 做批量任务多个请求并发出去额度消耗是叠加的。有些人测试的时候单次调用没问题一上并发就发现额度掉得飞快就是因为没把并发系数算进去。一般建议在预估基础上留 20% 到 30% 的缓冲。2.3 H3 视频解禁后的额度分配策略H3 纳入统一额度后我建议把视频生成的额度占比控制在总预算的30% 到 40%之间。低于 30%说明你没充分利用 H3 的能力高于 40%文本和语音那边可能会紧张。当然这取决于你的业务重心如果你是做视频素材生意的那视频占比到 60% 也合理但就要接受文本调用要省着用。具体操作上我会把 H3 的调用分成两类探索性生成和生产性生成。探索性生成用来试提示词、试分镜这部分额度要单独留出来比如每月总预算的 10%。生产性生成是已经验证过的提示词模板直接批量跑这部分占 20% 到 30%。这样分开管理就不会出现试提示词把生产额度试没了的情况。H3 的提示词写法也有讲究。5 秒视频的提示词我实测下来控制在80 到 150 字比较合适。太短了模型抓不住重点太长了又会稀释关键信息。分镜描述要按镜头顺序来写每个镜头说清楚主体、动作、环境、光线不要堆形容词。比如一个穿红色外套的人从左侧走入画面背景是雨后的街道地面有积水反光镜头缓慢右移——这种写法比一个很酷的人走在很酷的街上有效得多。3. 免密打通 Claude Code 与 M Plan 的完整链路3.1 为什么免密这件事值得单独讲Claude Code 和 Cursor 这类工具默认是绑定自家或者特定供应商的模型的。你想让它调 MiniMax 的模型传统做法是手动配 API Key、改 base URL、处理路由映射。这个过程里最容易出的问题就是no api key for provider route deepseek-official这类报错——本质上是工具在找它认识的 provider但你配的是它不认识的路由对不上。M Plan 的免密打通不是说真的不需要 Key而是Key 的管理和注入方式被简化了。你不需要在每一个工具里重复填 Key而是通过一个统一的配置层让 Claude Code 和 Cursor 都能读到同一个凭证。这样既减少了配置工作量也降低了 Key 泄露的风险——毕竟你不需要把 Key 明文写在多个配置文件里。我实测下来整个链路可以拆成三步凭证准备、工具侧配置、连通性验证。每一步都有一些容易忽略的细节下面逐个说。3.2 凭证准备API Key 的获取与存放位置首先你得在 MiniMax 的开发者后台拿到 M Plan 对应的 API Key。这个 Key 跟以前的 Token Plan Key 不一定是同一个如果你之前用的是旧 Key建议重新生成一个避免权限或者额度映射出问题。拿到 Key 之后不要直接写进代码或者提交到 Git。我见过太多人图省事把 Key 硬编码在脚本里结果一不小心推到公开仓库额度被人跑光。正确的做法是放在环境变量或者本地的凭证管理文件里。Linux 和 macOS 下可以写进~/.bashrc或者~/.zshrcWindows 下用系统环境变量或者.env文件配合工具读取。# Linux / macOS 示例 export MINIMAX_API_KEY你的_M_Plan_Key export MINIMAX_BASE_URLhttps://api.minimax.chat/v1Windows 下如果你用 PowerShell可以这样设$env:MINIMAX_API_KEY你的_M_Plan_Key $env:MINIMAX_BASE_URLhttps://api.minimax.chat/v1设完之后记得新开一个终端验证一下因为环境变量在当前会话里可能还没生效。用echo $MINIMAX_API_KEYLinux/macOS或者echo $env:MINIMAX_API_KEYPowerShell确认能打印出来。注意如果你同时用多个供应商的 Key建议给每个 Key 加前缀区分比如MINIMAX_、OPENAI_避免混淆。Claude Code 和 Cursor 在读取环境变量时变量名要跟它们的配置对得上不然会报找不到 Key。3.3 Claude Code 侧配置从安装到跑通第一个请求Claude Code 的安装方式取决于你的系统。macOS 和 Linux 下一般用包管理器或者官方脚本Windows 下建议用 WSL 或者直接在 PowerShell 里跑。安装完之后核心是配置它去读 MiniMax 的端点。Claude Code 的配置文件通常在用户目录下的.claude文件夹里或者项目根目录的.claude.json。你需要指定 provider 为自定义端点把 base URL 指向 MiniMax 的 API 地址然后让它从环境变量读 Key。这里有个细节Claude Code 默认可能只认 Anthropic 的模型名你要把模型名映射到 MiniMax 对应的模型 ID不然会报模型不存在。{ provider: custom, baseUrl: https://api.minimax.chat/v1, apiKeyEnv: MINIMAX_API_KEY, model: minimax-text-01, models: { fast: minimax-text-01, reasoning: minimax-text-01 } }配完之后在终端里跑一个简单请求验证claude-code 用一句话解释什么是递归如果返回正常说明链路通了。如果报no api key for provider route八成是环境变量没读到或者 provider 名字写错了。这时候先检查echo $MINIMAX_API_KEY有没有输出再看配置文件里的apiKeyEnv字段是不是跟环境变量名完全一致——大小写敏感。VSCode 里用 Claude Code 插件的话配置逻辑类似但入口在插件的设置面板里。你需要找到自定义模型或者API 端点的选项把 MiniMax 的信息填进去。有些版本的插件会缓存旧的 provider 配置改完之后要重启 VSCode 才生效。3.4 Cursor 侧配置中文设置与自定义模型接入Cursor 这边稍微不一样因为它本身是个完整的 IDE模型配置在设置里的Models或者AI选项卡。你要做两件事把界面和回复语言设成中文以及把自定义模型指向 MiniMax。中文设置很多人找不到入口其实在Settings里搜language或者locale把显示语言改成zh-cn。回复语言的话Cursor 的 AI 对话默认跟随界面语言但有时候需要单独在 prompt 里指定请用中文回复。如果你希望它默认就用中文可以在用户规则User Rules里加一条始终用中文回复。自定义模型接入这块Cursor 支持填 OpenAI 兼容的端点。MiniMax 的 API 是兼容 OpenAI 格式的所以你可以把 base URL 填成 MiniMax 的地址API Key 填 M Plan 的 Key模型名填 MiniMax 的模型 ID。填完之后点Verify或者发一条测试消息看能不能通。{ openai.apiKey: 你的_M_Plan_Key, openai.baseUrl: https://api.minimax.chat/v1, cursor.model: minimax-text-01 }这里有个坑Cursor 有时候会把自定义模型的请求路由到它自己的代理层导致 base URL 被覆盖。如果你发现请求没走到 MiniMax检查一下是不是开了某些加速或者代理选项把它们关掉。另外Cursor 的免费额度跟自定义模型是分开的你用自定义模型不消耗 Cursor 的免费额度但会消耗 M Plan 的额度这点要心里有数。3.5 连通性验证与常见报错对照配置完之后别急着上生产先做一轮连通性验证。我一般会跑三个测试纯文本对话、带上下文的代码补全、以及一次视频生成调用。前两个验证文本链路第三个验证多模态额度是否真的打通。报错信息可能原因排查方向no api key for provider route环境变量未读到或 provider 名不匹配检查echo $MINIMAX_API_KEY核对配置文件 provider 字段model not found模型 ID 写错或该模型未在 M Plan 中开放去后台确认可用模型列表核对大小写insufficient quota额度不足或模态额度分配问题查看 M Plan 后台余额明细确认对应模态有余额connection timeout网络问题或 base URL 写错检查 URL 是否带/v1测试网络连通性invalid response format工具期望的返回格式跟实际不符确认是否开启了 OpenAI 兼容模式我踩过最坑的一次是no api key for provider route deepseek-official当时明明配的是 MiniMax但报错里出现了 deepseek。后来发现是 Claude Code 的某个插件默认注册了 deepseek 的 provider路由优先级比自定义配置高。解决办法是在配置里显式禁用不需要的 provider或者把自定义 provider 的优先级调到最高。4. H3 视频生成的实操细节与分镜写法4.1 H3 在 M Plan 里的调用方式变化H3 纳入 M Plan 统一额度后调用方式跟以前比有两个明显变化。第一是不再需要单独的 H3 额度申请你直接用 M Plan 的 Key 就能调视频生成接口。第二是计费粒度更细以前可能按次算现在按实际生成的帧数或者时长算5 秒的视频和 10 秒的视频消耗差距是线性的。调用接口本身还是标准的 HTTP 请求你可以在 MiniMax 的 API 文档里找到视频生成的端点。核心参数包括model指定 h3、prompt提示词、duration时长一般 5 秒或 10 秒、resolution分辨率。分辨率越高消耗越大测试阶段建议用低分辨率跑通流程确认提示词效果后再上高分辨率。import requests import os url https://api.minimax.chat/v1/video/generations headers { Authorization: fBearer {os.environ[MINIMAX_API_KEY]}, Content-Type: application/json } payload { model: minimax-h3, prompt: 一个穿红色外套的人从左侧走入画面背景是雨后的街道地面有积水反光镜头缓慢右移, duration: 5, resolution: 720p } resp requests.post(url, headersheaders, jsonpayload) print(resp.json())这段代码跑通之后你会拿到一个任务 ID视频生成是异步的需要轮询或者等回调。轮询的时候注意别太频繁一般 5 到 10 秒查一次就行查太勤也会消耗额外的请求额度。4.2 5 秒视频的提示词到底写多少字合适这是被问得最多的问题之一。我的实测结论是5 秒视频的提示词中文 80 到 150 字英文 50 到 100 词。这个区间之外效果都会打折扣。为什么是这个范围因为 5 秒的视频能承载的信息量有限。你写 300 字模型不可能在 5 秒里全表现出来反而会因为信息过载导致画面混乱。你写 30 字模型又缺少足够的约束生成结果随机性太大。80 到 150 字刚好能说清楚谁、在哪、做什么、镜头怎么动这四个核心要素。分镜写法上我习惯按时间轴来组织。比如一个 5 秒的视频可以拆成三个 1.5 秒左右的片段0 到 1.5 秒主体入画交代环境1.5 到 3.5 秒核心动作发生3.5 到 5 秒镜头移动或情绪收尾对应的提示词可以这样写开头一个人从画面左侧走入背景是雨后的城市街道地面有积水反射霓虹灯光中段他停下脚步抬头看向天空雨滴从屋檐落下结尾镜头缓慢向右平移露出街道尽头的路灯。这种写法比笼统描述有效得多因为模型能按顺序理解每个阶段要生成什么。提示H3 对光线和材质的描述比较敏感。如果你想要电影感加上柔和侧光浅景深胶片颗粒这类词会有帮助。但别堆太多选一两个最符合你意图的就行。4.3 本地部署 H3 的可行性边界热词里有人问minimax h3 本地部署我得泼盆冷水H3 这种级别的视频生成模型本地部署对绝大多数人来说不现实。它需要的显存和算力不是消费级显卡能扛住的而且模型权重也不一定开放。所谓本地部署更现实的理解是本地跑调用脚本推理还是在云端。如果你确实有数据不能出本地的需求那要考虑的是私有化部署方案这通常涉及商务对接和专门的硬件环境不是个人开发者能轻松搞定的。对大部分人来说用 M Plan 的云端额度调用 H3是性价比最高的选择。你本地只需要一个能发 HTTP 请求的环境Python 脚本也好Postman 也好甚至 curl 都行。Windows 10 下部署调用环境我建议用 Python 虚拟环境加 requests 库简单直接。别一上来就搞 Docker 或者复杂的编排除非你有多个服务要协同。先把单次调用跑通再考虑工程化。5. 多工具协同下的额度监控与异常处理5.1 为什么需要自己搭一层额度监控M Plan 后台虽然有余额展示但它是事后的。等你看到余额告急的时候可能已经超了。尤其是 Claude Code 和 Cursor 同时跑任务的时候额度消耗是并发的后台的刷新频率未必跟得上。所以我的做法是自己搭一层轻量监控在每次调用之后记录消耗累计到一定阈值就告警。最简单的实现方式是在调用封装里加一个计数器把每次请求的模态和预估消耗写进本地日志然后每天汇总一次。复杂一点可以用 SQLite 存调用记录写个查询脚本看趋势。我目前用的是后者因为可以按模态、按时间段分析找出消耗异常的时间点。import sqlite3 from datetime import datetime def log_usage(modality, units): conn sqlite3.connect(usage.db) c conn.cursor() c.execute(CREATE TABLE IF NOT EXISTS usage (ts TEXT, modality TEXT, units INTEGER)) c.execute(INSERT INTO usage VALUES (?, ?, ?), (datetime.now().isoformat(), modality, units)) conn.commit() conn.close()这个表跑一段时间之后你就能看出哪个模态在什么时间段消耗最快。比如我发现视频生成集中在下午文本调用集中在晚上那就可以据此调整额度预警阈值。5.2 并发场景下的额度竞争与限流Claude Code 和 Cursor 同时跑的时候最容易出的问题是额度竞争。两个工具都在调 MiniMax如果其中一个发了大量并发请求另一个的请求可能会因为额度瞬时不足而失败。这种失败往往不是真的没额度了而是并发扣减导致的瞬时不一致。解决办法有两个一是给不同工具分配不同的 Key虽然 M Plan 是统一额度但你可以生成多个 Key 分别给 Claude Code 和 Cursor 用然后在后台看每个 Key 的消耗便于定位问题。二是在调用层加限流比如用令牌桶算法控制每秒的请求数避免瞬时打满。import time class RateLimiter: def __init__(self, rate): self.rate rate self.tokens rate self.last time.time() def acquire(self): now time.time() self.tokens (now - self.last) * self.rate self.tokens min(self.tokens, self.rate) self.last now if self.tokens 1: time.sleep((1 - self.tokens) / self.rate) self.tokens 0 else: self.tokens - 1这个限流器加在请求之前能有效平滑并发。实测下来加了限流之后因为额度竞争导致的失败率能降不少。5.3 额度异常时的排查链路如果你发现额度掉得比预期快别急着充值先按这个链路排查看后台明细确认是哪个模态在消耗是不是有非预期的调用。查调用日志看有没有循环调用、重试风暴、或者测试代码忘了关。检查并发配置是不是某个工具的并发数设太高了。核对模型 ID有没有误用了高消耗的模型比如把文本请求发到了视频模型上。看是否有失败重试失败请求如果自动重试会重复扣额度。我遇到过一次额度异常最后发现是 Cursor 的某个插件在后台定时发心跳请求虽然每次消耗很小但一天下来累积也不少。把那个插件禁用之后额度消耗就正常了。所以排查的时候别忘了检查工具的后台行为。6. 我在这套链路里踩过的坑和留下的习惯先说一个最容易被忽略的环境变量的作用域问题。我在 macOS 上把 Key 写进了.zshrc然后在 VSCode 里跑 Claude Code结果一直报找不到 Key。折腾了半天才发现VSCode 是从图形界面启动的不一定会加载 shell 的配置文件。解决办法是在 VSCode 的 settings 里显式指定环境变量或者从终端启动 VSCode。这个坑在 Windows 上也存在尤其是用 GUI 启动的 IDE。第二个坑是模型名的映射。MiniMax 的模型 ID 跟 Claude Code 默认认识的模型名不一样如果你不在配置里做映射工具会拿一个它认识的模型名去请求然后报模型不存在。我的习惯是在配置文件里把所有用到的模型名都显式列出来不用默认值。这样虽然多写几行但省去了很多为什么跑不通的困惑。第三个坑是视频生成的异步特性。文本调用是同步的发出去等返回就行。视频生成是异步的你拿到任务 ID 之后要轮询。我一开始没注意以为请求发出去就完了结果发现额度扣了但视频没拿到。后来加了轮询逻辑并且设置了超时时间避免任务卡住一直查。轮询间隔我设的是 8 秒超时 5 分钟超过就放弃并记录日志。留下的习惯有这么几个每次改配置先备份因为 Claude Code 和 Cursor 的配置文件格式有时候会变改坏了能快速回滚。Key 定期轮换虽然 M Plan 的 Key 管理方便了但定期换 Key 能降低泄露风险。额度预警设在 70%不要等到 90% 才反应留出缓冲时间调整策略。测试用低分辨率、短时长验证提示词效果之后再上生产参数。最后分享一个提升 H3 出片率的小技巧先用文本模型把分镜脚本写出来再转成视频提示词。具体做法是让文本模型根据你的创意生成一个分镜表包含每个镜头的时间、主体、动作、环境、镜头运动然后你把这个表压缩成 80 到 150 字的提示词。这样出来的提示词结构清晰H3 理解起来更准废片率能明显下降。我实测下来这个方法比直接手写提示词的出片率高出不少尤其是做系列化内容的时候分镜脚本还能复用。