mimo code 正式发布，号称无限上下文，越用越聪明

这不就是自动压缩吗？

反正我 15 块钱的 token ，一个任务没完成直接欠费了。 同样任务让 deepseek 花了 0.3 元

写的是 内置 MiMo-V2.5 限时免费通道，无需注册即可使用 这个 token 能免费用吗？

@mfkliq 别想太多。右上角有 xx% ，大概发个几十轮对话就没了

@ajaxfunction 安装好后要自已切换下模型，改成 MiMo Auto ，这个是限免的，其他要花钱的

营销米，最会搞的就是文字游戏

mimo 2.5 还是挺好用的，个人自用和 deepseek v4 falsh 差不多

@IqBbOBIS 觉得华为才是营销之王 , 还出了饱和式攻击营销的书.
这段时间一直在 opencode 上用 mimo 2.5 和 deepseek v4 flash 刚都不错.

@Foralrec 如果是 opencode 又上角 哪个是会话的长度 会重置的 不是免费额度

4 楼是挺搞笑的，没用过就来喷，只会输出情绪。

基于 opencode ，我就知道我选对了工具

无限上下文？

@Rickkkkkkk 你好，我是 MiMo
尊敬的用户，
Xiaomi MiMo 正式发布并开源 MiMo Code ，一款运行在终端的探索性 AI 助手。模型与 Agent 协同优化，迈向自进化时代。

跨会话持久记忆 + 近乎无限上下文
独创 Compose 编排模式，先设计再编码
Dream 记忆固化与自进化机制
支持语音输入与控制
同时，MiMo Code 内置限时免费的顶级多模态模型 —— MiMo V2.5 ，并支持接入 DeepSeek 等主流模型以及第三方 Token Plan ，满足不同开发者的需求。

👉 零配置起步，开箱即用。立即体验：MiMo Code

Xiaomi MiMo 开放平台

官网 · 文档

此邮件为系统自动发送 · © 2026 Xiaomi

近乎无限上下文，刚收到的邮件，改词了

@wangchengwu 就算是 codex/cc 都不会用这种词，“几乎无限”也是瞎说呀...

@Rickkkkkkk 博客有提到，实现方式有点不一样。
https://mimo.xiaomi.com/zh/blog/mimo-code-long-horizon


3.1 Cycle：无界会话的基本单元

把会话想象成一串从左到右排开的 turn。窗口有上限，turn 在累积，窗口终会被填满。如果不干预，会话到达上限时要么结束，要么悄悄退化。

运行时在到达上限之前的几个固定位置介入。我们称这些位置为 checkpoint。每个 checkpoint 处，运行时派出一个独立的 writer subagent：读取迄今的对话，将一份结构化状态写入磁盘。主 Agent 继续工作，writer 并发执行，互不干扰。

当窗口接近真正的上限，运行时执行一次 rebuild：切断当前窗口，开启新窗口，用已持久化的文件作为种子重建上下文。主 Agent 在新窗口中醒来，状态已摆在面前，继续工作。从模型视角看，对话从未中断；从运行时视角看，一个新的物理窗口已经开始。

一段被 checkpoint 打过点、最终以 rebuild 收尾的 turn 序列，是一个 cycle。Cycle 没有数量上限——每一个 cycle 受限于物理窗口大小，但逻辑会话是 cycle 的链，而那条链没有最大长度。
3.2 为什么提早提取

一种自然的直觉是把提取拖到窗口快满时。我们发现这恰好是反着的。

第一，模型在高上下文利用率下能力会衰减。这在文献中被称为 "lost in the middle"：随着输入变长，对中段材料的注意力下降，结构化提取的可靠性显著降低。要求模型在它的压缩能力正在退化的时刻去做最关键的压缩，是一桩划不来的交易。

第二，提取本身需要空间。Writer 必须读完历史、维持解读、写出结构化输出——全部在同一个窗口里。95% 利用率下已无处思考；30% 利用率下则游刃有余。

因此 checkpoint 在远低于上限处触发——大致在已配置预算的 20%、45%、70%。每一次触发都是对前一次的增量更新，没有任何一次是孤注一掷的总结。最末尾接近上限的那次 rebuild，不是一次仓促的压缩，而是将一路记下来的结构化记录变现的时刻。

这就是忽悠不懂的人 开源都是这么做的 mi 又给自己招黑一次

@eret9616 有一说一 支持国产 希望 mi 做得更好。

@tanszhe 那里居然是上下文占比啊。opencode 搞这东西没有 statusline 的形式让人容易理解

对小米营销已经无感了

还是小米会营销，技术上也来手机汽车那一套