昨天下午我在 MiniMax 控制台里看到订阅页面悄悄换了样子第一反应是Token Plan 那套总算结束了。对老用户来说这绝对是个历史性节点——以前为了跑一批图、一段视频、几轮长对话得反复盯着 Token 余额做算术现在 M Plan 直接把文本、图像、视频的额度统一到一个池子里H3 的视频生成也跟着解禁这对天天用 Claude Code 写代码、拿 Cursor 改需求、顺手还要用 H3 出素材的开发者来说等于把成本模型和工作流都重新洗了一遍盘。这篇文章不打算给你复述官方公告我直接聊三件核心事M Plan 的全模态额度到底怎么理解H3 视频生成解禁之后能做哪些事以及大家问得最多的——怎么把 Claude Code 和 Cursor 免密接到 MiniMax 的 API 上。全程都是实操向的配置步骤、踩坑记录和我的个人建议适合正在用或准备用 MiniMax 做统一 AI 工作流的开发者参考。1. M Plan 究竟改了什么从 Token 计量到全模态额度大一统1.1 旧 Token Plan 时代的真实痛点先说旧方案的问题因为只有弄明白旧东西哪里难受你才知道 M Plan 这次改得有多对胃口。Token Plan 时代MiniMax 把资源拆成了文本 Token、图像生成次数、视频生成时长、语音合成字数这些独立条目。听起来清晰实际用起来非常分裂。我自己当时就有过一个很典型的场景上午用 API 跑了一批文本分类下午用图像生成做了几张配图晚上再用视频模型试了一条 5 秒短片结果三个池子各自消耗文本额度还剩一大截视频额度却先见了底而文本余额又不能挪给视频用。这还不算最难受的。Token 池的“记忆”也是分开算的——对话历史占的记忆 Token、输出占的生成 Token、还有系统层面的上下文缓存经常让人分不清到底是哪一层把余额烧掉的。不少人在社区里吐槽“明明没生成多少内容额度却像漏了一样往下掉。”说白了旧的计量单位太多、太碎用户心智负担重更关键的是它不符合现在多模态混用的真实工作流。1.2 M Plan 的额度模型与档位设计M Plan 最大的变化就是不再让你盯着 Token 这个宏观度量单位做算术而是直接把所有模态揉进同一个额度体系。按我目前看到的信息控制台里会是“标准版、专业版、团队版、企业版”这种分档方式每个档位给一个总体的资源额度包文本对话、图像生成、视频生成、语音处理都从这个统一池子里扣。具体额度数字我不替你拍板因为价格页和权益表会不定期调整你登录 MiniMax 平台订阅页看到的一定是最终版本。但有一点可以确定它在产品逻辑上取消了“这个额度只能用于某个模态”的硬隔离。你不需要再预判这个月视频会跑多少、图像会跑多少只要总量在预算内临时多生成几条视频少生成一批图片都不会出现“某个池子爆了、另一个池子浪费”的尴尬。以下是我个人整理的档位选择参考适用于大多数个人开发者和中小团队档位适合人群核心优势我的建议标准版个人开发者、轻量用户成本低日常对话和轻度图像生成够用适合只跑 Claude Code 或偶尔出图的场景专业版深度使用者、内容创作者视频生成额度更充裕多模态比例均衡适合同时使用 Claude Code、Cursor、H3 视频生成的重度用户团队版小型团队、工作室统一额度池便于多人协作管理适合多人共享 API Key、需要集中管控预算的团队企业版中大型项目、商用产品更高并发、定制资源、优先服务有 SLA 诉求的商用场景再考虑还有一个值得关注的点M Plan 把“订阅额度”和“API 调用”的绑定关系做得更直接了。以前充值 Token 更像预付费套餐现在订阅制更像包月服务对你规划成本挺有帮助——你的心态从“省着点花”变成“在固定池子里弹性分配”这不只是体验差异而是使用策略的转变。1.3 新旧计费对比到底省在哪光说“大一统”可能不够直观我拿一个真实项目举例。假设你要做一个内容工作流每天用 Claude Code 处理 50 次代码/文本任务用 Cursor 做 30 轮代码补全对话再用 H3 生成 5 条短视频片段。旧的 Token Plan 下你得分别估算文本 Token、图像/视频次数一旦某天需求波动可能出现视频次数超额、文本 Token 却大量剩余。M Plan 下你只需要看一个总余量所有模态共享消耗计划的颗粒度直接从“模态”下降到“任务”。从账面上算如果你本来就在用多个模态M Plan 的单位成本曲线更平滑。尤其是 H3 视频解禁后单条视频生成的成本不再单列滴的是统一池子里的水这对内容创作者来说非常友好。用一句话总结M Plan 把“算力包”改成了“服务包”你买的不再是按模态拆分的 Token 量而是 MiniMax 全模态能力的使用权。2. H3 视频解禁与多模态生成能力拆解2.1 H3 到底是一个什么样的模型这次 MiniMax 的突袭不光是计费改革H3 模型本身也放出了视频生成能力。先简单梳理一下定位H3 是一个多模态生成模型不是单纯的文本对话模型也不是单纯的视频模型。它同时支持文本理解、图像生成、视频生成、声音合成等能力模型结构上走的是 MoE混合专家路线效果上更偏向“创作者助手”而不是“推理答题器”。很多开发者会对 H3 和 M3 分不清这里我做个小对比模型侧重点典型应用minimax-m3长文本、工具调用、Agent 型任务Claude Code 编程、长对话、复杂任务编排minimax-h3多模态生成、图像/视频/语音分镜出片、配图生成、创意素材生产在这两个模型同时存在的前提下我建议你在 Claude Code 和 Cursor 里偏向用 minimax-m3 做代码和文本任务在 ComfyUI 或官方工坊里用 minimax-h3 做视频和图像生成。一个是“会干活的”一个是“会创作的”配合起来才是完整工作流。2.2 H3 视频生成的参数配置与上手体验H3 视频解禁后最常见的玩法是在 Web 端或 API 端输入一句提示词让它直接吐出一段短视频素材。先说参数维度。以我目前实测和社区反馈来看H3 视频生成支持的分辨率通常在 1080P 级别帧率在 24FPS 到 30FPS 之间单次生成的视频时长集中在 5 到 10 秒区间。这个时长设计有心机——短视频时代的素材颗粒度本来就以“秒”为单位5 秒和 10 秒足以覆盖大部分分镜需求而更长的视频需要通过分镜脚本拼接完成。这里要特别提醒如果你想一次性生成“1 分钟完整视频”大概率会失望。H3 更适合“一条提示词产出一个镜头”然后你把这些镜头用剪映或 Premiere 拼起来。我踩过这个坑一开始拿它直接生成 30 秒长镜头结果提示词越复杂中段内容越容易失控。后来改成“5 秒一个镜头、每个镜头独立提示词、最后拼接”的方式整体质量明显提升。视频提示词的写法也会影响出片质量。结合 H3 的模型特性我常用的提示词结构是主体 环境 运镜 氛围 镜头时长。举个例子镜头1远景黄昏时分的海边灯塔海浪拍打礁石镜头缓慢向前推进金色夕阳洒在水面氛围安静怀旧5秒。这种写法信息密度高模型不用猜你要什么出片成功率会高很多。至于提示词具体写多少字我的经验是一个 5 秒镜头控制在 30 到 60 字左右最稳。太短则画面信息不足太长了反而会引入歧义。2.3 本地部署 H3 的显存规划与轻量方案很多人在热搜里搜“windows10 部署 minimax”和“minimax h3 本地部署”这里我也统一说一下。H3 本地部署不是不能做但先要有心理预期它是一个多模态模型参数量比纯文本模型大显存占用不会低。如果你想跑 16 位精度实际显存需求相当夸张个人电脑基本吃不消。比较现实的路线是量化部署也就是用 GGUF 格式跑 Q4 或 Q8 量化版本。我参考过社区里一些实测数据配置和效果因驱动、内存交换策略不同会有差异大致可以按这个表来规划量化等级显存占用预期体验建议Q8偏高约 20GB 以上效果最好适合显存充裕的机器Q4_K_M适中约 12~16GB常规推荐兼顾效果与资源占用Q4 Mem Eff Swap较低可压到 10GB 以下适合显存不足时体验但速度会有牺牲这里“Mem Eff Swap”显存与内存交换是显卡显存不够时的一种常用优化策略简单理解就是允许 GPU 在显存不够时把一部分权重临时放到内存里交换使用。代价是推理速度变慢但至少能跑起来。Windows 上建议优先尝试 LM Studio 或 Ollama 这类现成工具它们对量化模型的支持比较省心不太需要自己折腾 llama.cpp 的编译参数。如果你是想在 ComfyUI 里接 H3 做视频工作流也可以走“API 远程生成 ComfyUI 后期处理”的路径本地反而不用承担模型推理压力。我个人的判断是本地部署 H3 适合学习、测试和隐私敏感场景但生产环境直接走 MiniMax 官方 API 更高效。3. 免密打通 Claude Code 与 Cursor 的完整配置指南3.1 前置准备API Key 与基础认知在配置之前你需要去 MiniMax 开放平台注册账号并创建 API Key。这一步不多说控制台界面上引导得很清楚创建完 Key 后复制保存注意别泄露给任何人。然后你要理解一个概念MiniMax 提供的是 Anthropic 兼容 API 端点也就是说 Claude Code 这类专为 Anthropic 设计的工具可以通过环境变量直接把请求指向 MiniMax 的服务器而不需要你真的拥有一套 Anthropic 官方 API Key。这就实现了“用 Claude Code 的交互体验跑 MiniMax 模型”的效果。配置的前提是网络链路畅通这一点按你自己的实际环境处理就行我这里只讲配置本身。如果你已经装了 Claude Code建议在改配置之前先看一下当前版本claude --version老版本对自定义端点的支持可能有差异升级到新版更省心。3.2 Claude Code 免密接入 MiniMax两种配置方式Claude Code 的接入核心就是改两个环境变量ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN。前者指定请求发到哪后者指定调用身份也就是你的 MiniMax API Key。设置好之后Claude Code 启动时就不会再弹官方登录、也不会要求你输入 Claude 账号密码这就是“免密”的含义。先看 macOS/Linux 下的命令行方式export ANTHROPIC_BASE_URLhttps://api.minimaxi.com/anthropic export ANTHROPIC_AUTH_TOKEN你的MiniMax_API_Key export ANTHROPIC_MODELminimax-m3 claudeWindows 10 用户用 PowerShell 则这样写$env:ANTHROPIC_BASE_URLhttps://api.minimaxi.com/anthropic $env:ANTHROPIC_AUTH_TOKEN你的MiniMax_API_Key $env:ANTHROPIC_MODELminimax-m3 claude你可能注意到我特意加了ANTHROPIC_MODEL。这是因为 Claude Code 默认会请求 Anthropic 的模型名如果环境变量没指定模型当它向 MiniMax 端点发请求时可能匹配不到模型就会报错。显式指定为minimax-m3后它才会准确路由到 MiniMax 的模型上。第二种方式是写在 Claude Code 的配置文件中这样不用每次启动终端都重新 export 一遍。路径是~/.claude/settings.json内容如下{ env: { ANTHROPIC_BASE_URL: https://api.minimaxi.com/anthropic, ANTHROPIC_AUTH_TOKEN: 你的MiniMax_API_Key, ANTHROPIC_MODEL: minimax-m3 } }写完保存重启 Claude Code 就生效了。两种方式的区别在于命令行 export 适合临时切换、多供应商测试settings.json 适合固定使用、团队统一配置。在团队场景下我一般建议把 settings.json 纳入初始化脚本管理减少新人上手成本。安装 Claude Code 本身也比较简单如果你还没装先执行npm install -g anthropic-ai/claude-code安装完成后用claude --version验证版本号能正常输出就说明装好了。这里提醒一句不要忽视 Node 环境版本Claude Code 对 Node 版本有要求旧版 Node 会导致安装卡在依赖阶段。3.3 Cursor 配置 MiniMax 模型步骤与参数Cursor 的接入路径和 Claude Code 不太一样它不是通过终端环境变量而是在编辑器内部完成配置。Cursor 支持 OpenAI-compatible 接口的自定义模型所以你可以把 MiniMax 的 OpenAI 兼容端点配进去。具体操作步骤是这样的打开 Cursor进入 Settings快捷键Ctrl,或Cmd,。找到 Models 或 Model 配置区域开启自定义模型选项。在 OpenAI API Key 区域填入你的 MiniMax API Key。在 OpenAI Base URL 区域填入https://api.minimaxi.com/v1这是 MiniMax 提供的 OpenAI 兼容端点。在模型列表里手动添加minimax-m3或minimax-h3保存设置。完成之后新建对话时就能在模型选择器里看到你添加的 MiniMax 模型。由于 API Key 已经写进 Cursor 的配置存储里之后每次使用都不会再要求输入这就是“免密”在 Cursor 端的体现。这里有个容易被忽略的细节Cursor 的模型名必须和服务端返回的模型 ID 精确匹配否则会出现“模型不存在”的报错。如果你添加模型之后报 404 或 Model Not Found不要急着怀疑 Key 有问题先检查模型名是不是写成了中文或带空格。模型名统一用小写连字符格式比如minimax-m3。另外Cursor 默认的对话模式里可能仍然绑定着官方模型你要在对话界面顶部手动切换到自定义模型。如果你同时配了多个供应商建议给每个供应商起一个容易辨认的名字比如“MiniMax-M3”切换的时候一眼就能选中。3.4 用 CC Switch 做多供应商一键切换很多开发者不止一个 API 供应商随手备着 DeepSeek、Qwen、GLM、MiniMax 的 Key 是很正常的事。如果用 Claude Code 工作你会很快发现每次切换供应商都要重新改环境变量太麻烦了。这时候社区里开源的 CC Switch 这类小工具就能帮上忙。CC Switch 的核心逻辑是用配置文件把多个“供应商 模型 API Key Base URL”的组合存成预设之后在命令行里执行简单命令就能一键切换。对 Claude Code 用户来说它最大的价值是省掉了手动改ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN的重复劳动。按照社区里常见的用法你可以在 CC Switch 的配置模板里添加类似下面的条目配置名ANTHROPIC_BASE_URLANTHROPIC_AUTH_TOKENANTHROPIC_MODELminimaxhttps://api.minimaxi.com/anthropic你的MiniMax Keyminimax-m3deepseekDeepSeek 的 Anthropic 兼容地址你的DeepSeek Key对应模型名qwen阿里云的 Anthropic 兼容地址你的DashScope Keyqwen-plus 等用的时候执行cc-switch use minimax它会重写 Claude Code 的配置文件然后你重新打开 Claude Code 就完成了供应商切换。从实操角度来看多供应商管理是团队开发里最容易被低估的需求特别是在不同客户环境、不同数据合规要求下能快速切换供应商比什么都重要。3.5 把本地模型也接进 Claude CodeLM Studio 方案热搜里有“claude code 调用 lmstudio 的本地模型”和“vscode配置 claude code”这类关键词说明很多人其实想在本地模型上也能用 Claude Code 的交互界面。这个需求完全可以用同样的环境变量思路实现。LM Studio 启动本地模型后会提供一个本地 OpenAI 兼容服务默认地址是http://127.0.0.1:1234/v1。你对照前面 Claude Code 的配置方式把ANTHROPIC_BASE_URL改成这个本地地址把ANTHROPIC_AUTH_TOKEN随便填一个占位符本地服务通常不校验身份再把模型名改成 LM Studio 里加载的模型名即可export ANTHROPIC_BASE_URLhttp://127.0.0.1:1234/v1 export ANTHROPIC_AUTH_TOKENlocal-test export ANTHROPIC_MODEL你加载的本地模型名 claude这套思路的本质是Claude Code 并不强制要求请求必须发到 Anthropic 官方只要目标端点兼容 Anthropic 的请求格式它就能工作。本地模型通过 LM Studio 做了协议转换因此也能无缝接入。这种“先本地试、再云端跑”的工作流非常适合对隐私敏感、或者想白嫖实验性代码任务的开发者。4. 实操中的踩坑与排查实录4.1 Claude Code 连官方订阅被禁用怎么办有相当多人在配置时报过这个错your organization has disabled claude subscription access for claude code。这其实是 Claude Code 尝试用 Claude 官方的订阅账号比如 Pro/Max 订阅去认证但当前账号所属的组织或团队关闭了 Claude Code 的订阅访问权限。这个问题的解法有两条路。第一种如果你是管理员去 Anthropic 的后台把 Claude Code 订阅访问打开第二种绕过订阅认证直接用 API Key 方式接入。注意我说的是 API Key 方式也就是前面已经展示的ANTHROPIC_AUTH_TOKEN方案这是正规、合规、被支持的接入模式只是它走的是按量付费的 API 通道不是订阅通道。在实际排查时我发现很多人配置了环境变量但还是报这个错原因是系统里残留了之前登录 Claude 官方时的认证缓存。解决办法是清掉~/.claude下的会话缓存文件或者执行claude auth logout后再启动。顺序很重要先退出旧会话再让新配置生效。4.2 Cursor 中文设置与中文回复Cursor 的中文问题也是高频搜索点分两个层面界面语言和回复语言。界面语言设置很简单。打开 Cursor按CtrlShiftPmacOS 是CmdShiftP唤起命令面板输入Configure Display Language选择简体中文重启 Cursor 就生效了。如果命令面板里没有中文选项说明你的版本没有下载语言包先去扩展市场安装中文语言扩展再进行切换。至于回复语言这是很多人忽略的。Cursor 的模型默认会根据代码上下文推断回复语言如果你希望它固定用中文回复可以在 User Rules用户规则里增加一条指令始终使用简体中文回答。很多新手只切换了界面语言结果模型回复还是英文就是因为没有设置这一层。4.3 视频时长与提示词长度的避坑思路关于 H3 视频生成两个问题被问得最多能不能生成一分钟提示词要写多少字一分钟视频的问题我在前面已经解释过不建议让 H3 直接生成一分钟内容而是拆成 6 到 12 个镜头每个镜头独立生成后再拼接。你甚至可以给每个镜头写一个分镜序号和衔接说明比如镜头2中景角色从码头走向灯塔镜头跟随侧面平移风吹起衣角画面由暗转亮5秒。这种写法比“写一段很长的完整故事”要可靠得多。提示词长度方面我的经验是 5 秒镜头 30~60 字10 秒镜头可以适当放宽到 80~100 字但不要超过 150 字。太长的提示词会让模型在有限的生成窗口里平均分配注意力结果就是每个元素都点到但每个元素都不精。另外提醒一句H3 对动态内容运镜、动作、光影变化的响应优于静态描述写提示词时尽量用动词短语来驱动画面比如“镜头缓缓拉远”“海浪翻滚”“光线逐渐变亮”不要只堆名词。4.4 显存占用与速度优化的几个策略如果你本地部署 H3 或跑 ComfyUI 工作流显存优化是绕不开的坎。先说三个我实际验证过有效的方向。第一个是量化等级选择。显存紧张就选 Q4_K_M想要画质就上 Q8。不要一上来就追求原版精度先把流程跑通再逐步提档位。第二个是 Mem Eff Swap 策略如果你是 Windows 10 NVIDIA 显卡可以在 LM Studio 或 llama.cpp 侧启用显存与内存交换牺牲一定推理速度换取显存占用大幅下降。第三个是并发控制本地推理时把 API 服务的并发请求数限制在 1避免多任务同时挤占显存导致 OOM。速度上如果觉得量化后的 H3 生成太慢可以检查一下是否打开了显卡加速。Windows 下最容易犯的错是用 CPU 跑了量化模型GPU 利用率显示为 0。这个排查不难打开任务管理器看 GPU 使用率如果一直是低值说明推理没有正确落到显卡上需要调整 LM Studio 或 Ollama 的 GPU 开关。5. 最后聊聊我的实操体会5.1 额度管理从“省”到“配”用了几天 M Plan 后我最明显的感受是以前我总在想“视频额度还够不够”现在我更关注“本周整体任务量是否有超预算的风险”。这种心态转变带来的实际好处是我不再动不动就去控制台检查余额减少了非常多的精神内耗。但 M Plan 的统一池子也有一个副作用因为不再分模态限制可能导致你在不知不觉中把额度全花在某个单项上。我的建议是给自己设一个简单的周预算习惯比如每周末记录一次剩余额度估算本周各类任务的消耗比慢慢你就能找到自己固定的用量节奏。团队场景下更建议设置多个子账号或项目分组避免一个人把全组额度跑光。5.2 工作流分工与后续扩展方向我现在的主力工作流基本是这样Claude Code 负责写代码、改脚本、做 Agent 型任务Cursor 负责日常补全和交互式修改H3 负责生成视频素材和创意配图需要本地调试时再用 LM Studio 拉起一个本地模型。三套工具互不冲突MiniMax 的 API 就是中间的统一通道。后续我打算再深入一点的是 ComfyUI H3 的组合。目前 H3 的主要入口是官方控制台和 API但社区已经有人在测试把 H3 接入 ComfyUI 的生成节点这样本地做工作流编排、远程跑模型推理等于既享受了本地节点的灵活性又不用扛本地推理的显存压力。对内容工作室来说这条路值得持续关注。说到底M Plan 这次改版最大的意义不是省了多少钱而是把“多模态模型组合成一条流水线”这件事变得简单了。当你不需要再为每种模态单独做预算和配额管理时你才能真正把精力放在内容创作和产品开发上。我个人在这些天的实操里最满意的一点就是 Claude Code 和 Cursor 的免密接入确实省下了大量切来切去的重复操作——这套配置装好一次后面就再也不用管了。