在这套计费方案中，Token 消耗的最小计数单位被统一为 Credit。用户为后者付费，购买额度不一的套餐。在调用 MiMo 系列的不同模型时，每个 Credit 点数也对应着不同的 Token 额度，换算比例如下：
MiMo-V2-Omni 256k 上下文：1x（消耗 1 Token = 1 Credit）
MiMo-V2-Pro 256k 上下文： 2x（消耗 1 Token = 2 Credits）
MiMo-V2-Pro 256k~1M 上下文： 4x（消耗 1 Token = 4 Credits）
MiMo-V2-TTS：0x（限时免费，不消耗 Credit）
类似流量包的设计让用户对模型调用有了更大的自由度。在 Anthropic、OpenAI、阿里等主流模型厂商都通过“5 小时滚动窗口”限制用户的使用时间时，小米此次推出的 Token Plan 取消了这一规定，支持用户集中消耗 Token，编程 vibe 到爽。
这是一套完全不同的计费逻辑。
对用户而言，传统的订阅制是用固定成本换取模型调用权益，逻辑简单清晰，易于接受。但任务难度的波动让平台成本难以预测，模型厂商对用户加以使用时间和每周请求次数上限的限制，都是为解决这一问题。
另一种常见方案是按模型调用次数计费，同样可以避免用户遇到帐单冲击。但同样是一次请求，复杂任务编程和修改一份简历的 Token 成本天差地别，这种方案难以在计费上体现出不同任务的复杂度，专业开发者的 Token 成本最终会被小白玩家一起分担。
而小米从 Credit 到 Token 的换算，是对模型文本处理量直接计费，逻辑上确实更易于公平地衡量每个任务的实际成本。它把 AI 服务从一种固定消费，变成了随任务难度调整的弹性消耗。
但问题在于，Token 是模型思考的最小单位，普通用户却难以预估一项任务的实际消耗。当模型输出从单轮的回答转向直接交付任务结果，Token 消耗量更是会呈指数级增加，对用户而言又是一重认知负担。
模型成为新一代基础设施的未来已成定局。在 Claude Code、OpenClaw 越发广泛地进入生产环境时，什么是更合理的计费方案？
Xiaomi MiMo Token Plan 提供了一种全新的可能，对它的评价同样应该回到真实场景。为此我们向 Mimo V2 Pro 下达了真实的任务指令，看看模型的表现如何，以及小米为此开出了什么样的价格。
在 OpenClaw 框架之下，我们基于 MiMo V2 Pro 搭建了一套多角色协作系统，将科研流程拆解为五个相对稳定的职责：方向规划、算法实现、学术写作、文献整理与数据处理。对应地，我们引入了五个不同角色的 Agent，分别承担不同类型的任务：
唐僧：科研战略与方向规划（想清楚要去哪）
孙悟空：算法开发和工程落地（把事干出来）
猪八戒：学术写作与表达（把话说清楚）
沙僧：文献整理与知识管理（把信息理顺）
白龙马：数据处理与流程自动化（把基础打好）
目前大模型落地应用在工程技术上存在诸多挑战。一个常见现象是小范围的代码生成已不在话下，但面对复杂架构时，模型往往会出现一致性等问题。
为此我们将首个测试任务交给孙悟空 Agent，要求它基于公开文本分类数据集，完成一个“小样本垂直领域文本分类基线系统”的开发，借此观察 MiMo V2 Pro 在代码实现、复现以及工程封装上的表现。
经过 3-4 小时的运行，悟空构建了完整的框架与细节。
核心功能方面，悟空按需求实现了 TF-IDF+LogReg 传统机器学习路线和 BERT fine-tuning 深度学习路线，覆盖了不同计算资源场景，而且从数据下载、读取、清洗、划分、训练到评估的全流程闭环，形成了可复现的 ML pipeline。
工程化交付同样规范。通过 train.py 和 evaluate.py 提供统一入口，符合 Python 项目惯例。实验结果表格结合模型优劣分析的结构化输出，更展现了 MiMo V2 Pro 的能力不止于跑通代码，更在于解释结果。
另一项测试任务是多 Agent 的协同科研。
我们要求五个 Agent 协同完成一个小型科研项目，项目主题为“面向垂直领域 LLM 的轻量化蒸馏研究”，任务内容覆盖了从课题立项到可投稿初稿的完整闭环。这一任务旨在考察 OpenClaw 场景下 MiMo V2 Pro 的智能体协作能力。
值得注意的是，收到具体分工之后，MiMo V2 Pro 并未直接输出结果，而是进行即时的角色分离，让每个 Agent 都根据自身角色明确了输入依赖和输出产物。其中唐僧的输出会成为另外四个 Agent 的输出，沙僧检索到的文献会成为孙悟空实验设计的参考，后者又是白龙马进行 workflow 设计的依据，最后所有中间结果都服务于猪八戒的论文初稿。
这种有向无环图式的依赖结构能被模型自动识别，表明 MiMo V2 Pro 不仅对 Agent 的协作边界有着清晰的认知，而且真正理解了任务。
可以看到，在任务第一阶段首先由唐僧定义了“医疗+金融，≤3B小模型蒸馏”的研究目标，沙僧后续的文献调研进一步覆盖了白盒/黑盒/垂直领域，识别出 DDK、MiniLLM、GKD 等 SOTA 方法。
同时作为协调中枢，唐僧后续还执行了两轮协作反馈和对中间成果的统一验收，特别是在任务的第三阶段及时识别出了孙悟空和白龙马的交付延迟问题，启动补救机制。
值得注意的是在第二轮协作反馈中，唐僧提出建议“缩短迭代周期至 3 天 checkpoint”。在经历了孙悟空和白龙马的拖延之后，表现出了对任务的迭代复盘，这是 MiMo V2 Pro 执行长程任务不可或缺的能力。
MiMo V2 Pro 的编程和工具调用能力使其非常擅长处理多步骤任务，同时 1M 级的超长上下文设置，让该模型在处理具有长代码需求的架构级任务中更加胜任。这些表现，都意味着 MiMo V2 Pro 不是简单的对话模型，而是为复杂任务和开发场景而生。
两次交付结果均水平在线，那么成本如何？
答案约为一个 Lite 套餐额度的 60％。
Xiaomi MiMo Token Plan 提供了四档套餐：
Lite（中国 ¥39/月，海外 $6/月） —— 0.6亿（60M）Credits，可执行约 120 个中等~复杂任务 。适合刚接触 AI 开发的探索者，以一杯咖啡的价格开始。
Standard（中国 ¥99/月，海外 $16/月） —— 2亿（200M）Credits，可执行约 400 个中等~复杂任务 。为日常依赖 AI 提效的办公与开发者用户打造的主力方案。
Pro（中国 ¥329/月，海外 $50/月） —— 7亿（700M） Credits，可执行约 1400 个中等~复杂任务 。面向将 AI 深度嵌入工作流的专业用户。
Max（中国 ¥659/月，海外 $100/月） —— 16亿（1600M）Credits，可执行约 3200 个中等~复杂任务 。为全天候高强度使用的开发者准备，近乎无限制的使用体验。
这种多档位套餐、按 Credit 点数折算 Token 消耗的模式，意味着在传统“一个会员打包天下”的服务方案之后，又出现了真正按量计价的 AI 套餐。
但不知道小米有没有预料到的是，这种计费模式在应用中带来了全新的困惑：我开的套餐到底能用多久？一次 Coding 任务会消耗多少 Token？多轮调试的过程，会不会花光我的所有额度，甚至代码没调试完额度就没了？
用户再次想起了被账单冲击支配的恐惧。
特别是在 Coding 场景中，不同于一般的对话，多轮调试、复制粘贴长代码、不断追问与修改的任务属性，都会将 Token 消耗量拉到惊人的高度，而这是人脑难以预估的。至少在追求清晰的预算管理时，今天的大多数用户对 Token 消耗尚不具备可靠的直觉，这难免让小米的 Token Plan 变成一笔“糊涂账”。
那么抛开心理因素，小米让模型更便宜了吗？
对比各家厂商面向专业用户的 Pro 版本套餐，单一价格维度上，小米在一众厂商中不占优势。但这个对比的不公平之处在于，用户为智能付费，各家套餐背后的模型性能却各不相同。
MiMo V2 Pro 原生支持 1M 上下文窗口，上表的套餐中，只有阿里云百炼的 qwen3.5-plus 和 qwen3-coder-plus 达到了这一水平，其余模型上下文窗口多限制在 256K 以下。
小米对 MiMo 的定位是"面向 Agent 时代的旗舰基座模型"。显而易见的是，Agent 在多轮规划任务中保留历史对话时，累计 Token 会迅速增长，每次调用工具的返回结果也会追加到上下文中，而长链推理本身又是另一个 Token 消耗大户。
在这一场景下，Credit 和 Token 的换算，更像是支持用户为上下文窗口本身付费，将 1M 的超长上下文从成本负担变成价值锚点。作为 MiMo-V2-Pro 的核心能力，这正是其在生产环境中的差异化价值所在。便宜与否，取决于任务场景。
而值得注意的是，虽然小米是 Token “流量包”的首创者，但今天更常见的订阅制也并非无限 Token。
除了单次任务中，模型上下文窗口的硬性技术限制之外，用户还面临着隐性的经济约束机制。此前就曾有用户反映称，火山方舟 Coding Plan 标称配额为每 5 小时 6,000 次请求，但实际会根据单次请求的 Token 消耗量折算为多次请求，且不同模型的隐藏倍率不同。
火山的回应则是，“通常一次用户提问会触发多次模型调用，且每次模型调用均会计入一次额度消耗，因此实际消耗的请求次数一般会多于用户提问次数。”
阿里云百炼的 Coding Plan 也存在类似的限制，当输入超出允许长度时模型会返回报错信息，官方推荐的解决方案是精简输入或切换上下文窗口更长的模型。
算力成本压力让 Coding Plan 没办法真正实现无论 Token 消耗的计费模式，因而在计算请求次数时，会对超长上下文的任务适用惩罚倍数。如果说面对小米的 Token Plan 时，大多数用户还没有养成估算任务 Token 消耗量的直觉，那么 Coding Plan 也只是用模型调用次数“预估值”的表述模糊了争议地带。
Token 的价格，一直都写在账单里。
从 2026 年初的涨价潮，到小米率先直接根据消耗量计费，Token 的定价逻辑正在悄然转变。
此前更常见的是订阅制，一次性收费将按量计费的连续博弈过程变成单次博弈，用户觉得自己不是时时刻刻在花钱，预算也不会超额，但算力成本让这种方案的现金流未必能够打正。
神经计算引擎创业者梅一凡表示，在这一视角下，OpenAI、Anthropic 采用的混合计费方案成为了一种非常明智的选择，即订阅制基础上，超量部分按 Token 计费，前者降低用户心智成本，后者保障单位经济回正。
小米的 Token Plan 本身更像一个带有封顶机制的 API Plan，但主流模型厂商同样可以照搬，核心问题仍然是模型强度和成本。
但小米策略的不同之处在于，小米生态和用户数据构成了天然的护城河，这是 MiMo 模型的巨大应用空间。因此在战略上，小米 Token Plan 背后更统一的计费方式，或许是一个内部“人车家全生态”准备进一步发力的信号。
也许在小米设想的未来中，所有接入自家生态的 AI 功能，都会遇到统一的计费方案。那么 Xiaomi MiMo Token Plan 的真正意义，就是迈向这个未来的第一步。
雷峰网文章
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
相关文章
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。