MiniMax M3 已在官方页面和第三方 API 平台上线。官方把它定位为首个同时覆盖编程智能体、百万上下文和原生多模态的开源权重前沿模型，但截至发稿，权重与技术报告仍是“约 10 天内发布”的承诺，不能等同于权重已经公开可下载。

发布重点不是单一榜单，而是三项能力打包

MiniMax 在官方发布页中给 M3 的主标题是“Frontier Coding, 1M Context, Native Multimodality”。这三项分别对应编程与智能体任务、最高 100 万 token 上下文，以及从训练阶段开始的原生多模态能力。

这也是本次发布的核心卖点：不是只做长上下文模型，也不是只做编程模型，而是试图把代码生成、工具调用、长程上下文和图像/视频输入放进同一个通用模型。

官方披露的编码和智能体评测包括：SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%、SWE-fficiency 34.8%、KernelBench Hard 28.8%、MCP Atlas 74.2%。这些数字目前主要来自 MiniMax 官方口径和其披露的内部评测流程，尚未看到独立第三方复现。

MSA 把百万上下文从容量问题变成成本问题

M3 采用 MiniMax Sparse Attention（MSA）。官方称，在 100 万 token 上下文规模下，M3 单 token 计算量约为上一代模型的二十分之一；预填充阶段加速 9.7 倍，解码阶段加速 15.6 倍。

这组数字的意义不在“上下文窗口更大”本身。百万上下文已经不是新概念，真正卡住工程落地的是读取长仓库、长视频和长任务历史时的成本与延迟。如果 MSA 的质量损失可控，长程 Agent 才有机会把完整代码库、历史 issue、终端日志和多轮工具调用历史留在同一个上下文里处理。

但这里仍要保留边界：MSA 的性能曲线、质量保持方式、训练细节和部署约束，需要等技术报告和权重发布后才能被社区验证。

API 已开放，权重还没真正落地

可用性上，M3 已出现在 MiniMax 官方导航、Vercel AI Gateway 和 OpenRouter 模型目录中。OpenRouter API 返回的模型 ID 是 minimax/minimax-m3，标注上下文长度为 1,048,576，输入形态为文本、图像、视频到文本输出；其顶层 provider 当前给出的可用上下文为 524,288。

价格方面，OpenRouter 目录显示 M3 限时 5 折后输入价格为 0.30 美元/百万 token，输出价格为 1.20 美元/百万 token，缓存读取为 0.06 美元/百万 token。第三方平台价格会随 provider 和促销变化，正式选型仍应以调用平台实时价格为准。

更关键的是“开源权重”状态。MiniMax 官方社交发布称权重和技术报告将在约 10 天内发布；Hugging Face 的 MiniMaxAI/MiniMax-M3 模型卡目前无法直接读取。也就是说，M3 现在可以通过 API 测试，但还不是一个已经完成社区复现链路的开源权重模型。

• API：http://platform.minimax.io
• Token 计划：https://platform.minimax.io/subscribe/token-plan

OpenAI 将 Codex Open Source Fund 扩展为面向开源维护者的申请制项目。入选者可获得 6 个月 ChatGPT Pro、项目 API 额度，以及按仓库需求评估的 Codex Security 访问权；目前核心信息来自 OpenAI 官方页面。

计划从 API 额度扩展到维护者工具包

OpenAI 开发者社区页显示，Codex for Open Source 面向开源维护者开放申请。项目不是新的开源模型发布，而是给维护者提供 Codex 相关工具和额度，覆盖日常编码、问题分类、代码审查、维护自动化和发布流程。

官方页面同时提到，过去一年 Codex Open Source Fund 已以 100 万美元规模支持需要 API credits 的项目，其中包括把 Codex 用于 GitHub PR 工作流的团队。现在该基金的支持范围扩大到 ChatGPT Pro with Codex、API credits 和 Codex Security。

入选维护者能拿到什么

OpenAI 列出的支持包括三项：

• 6 个月 ChatGPT Pro，包含 Codex，用于日常编码、triage、review 和维护工作流。
• 面向项目的 API credits，可用于 PR review、维护自动化、发布工作流和其他核心 OSS 工作。
• Codex Security 的有条件访问权限，主要面向有更深安全覆盖需求、且符合条件的仓库。

这里需要区分事实和官方口径：6 个月 Pro、API 额度、Codex Security 条件访问是官方页面明确写出的项目内容；这些工具实际能为维护者节省多少时间，OpenAI 暂未给出统一的第三方评测数据。

申请门槛看重维护职责，而不只看星标

OpenAI 表单要求申请者填写 GitHub 用户名、公开仓库 URL、维护者角色、仓库星标数、月下载量或生态重要性说明，还要求填写 OpenAI 组织 ID 和 API 额度用途。

开发者社区页给出的申请对象是“核心维护者或广泛使用的公开项目”。如果项目没有典型的高星标或高下载量，但在生态系统中承担明确角色，OpenAI 也建议申请者解释原因。这意味着审核会看仓库使用情况、生态重要性和持续维护证明，而不是单一指标。

对开源维护者的真实价值在低可见度工作

这类计划值得关注的点，不在“免费 Pro”本身，而在维护任务的结构：PR 审查、issue 分类、版本发布、依赖和安全修复都很耗时，但外部贡献者通常看不到这部分劳动。

Codex 如果能稳定接入这些流程，价值会先出现在低可见度的维护环节：重复性 review、变更摘要、测试失败定位、release checklist、漏洞修复建议。反过来，风险也在这里：自动化系统接触代码、CI、权限和安全上下文时，维护者仍需要保留最终审查权。

🔗 申请链接：https://openai.com/zh-Hans-CN/form/codex-for-oss/

CC Switch v3.16.0 把 Codex 的第三方供应商能力补上了关键一环：本地代理可将 Codex Responses 请求转换为 Chat Completions，再把响应重建回 Responses 形态。它解决的是协议适配问题，不是模型能力本身的保证。

Codex 不再只等 Responses 上游

CC Switch 在 2026 年 5 月 29 日发布 v3.16.0。发布说明把首要更新放在 Codex Chat Completions 路由：Codex 供应商现在可以由只支持 OpenAI Chat Completions API 的上游提供服务。

这层代理做三件事：

• 把 Codex 发出的 Responses 请求转换成 Chat Completions 请求；
• 把 JSON 与 SSE 流式响应重建回 Responses 形态；
• 尽量保留 reasoning、<think>、工具调用状态和 previous_response_id 续接。

对用户来说，变化很直接：过去一些只能给 Claude Code、OpenCode 或普通 OpenAI 兼容客户端用的模型服务，现在有机会进入 Codex CLI / Codex Desktop 的工作流。

22 个预设只是入口，关键在协议转换

v3.16.0 还加入了 22 个带 Chat 路由的 Codex 第三方供应商预设，并让 Stream Check 对 Chat 格式供应商使用 /chat/completions 形态探测，而不是拿 /v1/responses 去误判。

这不是简单的 base URL 改写。Codex 的客户端语义仍偏向 Responses API：流式事件、工具调用、历史续接、usage 统计、错误信封都要重新拼回来。发布说明中列出的修复也集中在这里：MiniMax 非首位 system 消息、Kimi / MiniMax 流式 usage 丢失、Chat 错误体无法被 Codex 识别、工具调用推理内容回填等。

换成工程语言：CC Switch 在 Codex 与一批 Chat Completions 上游之间补了一个协议整流层。

推理参数开始按供应商适配

Codex 接入第三方模型后，最容易出问题的是 reasoning 参数。不同供应商的 OpenAI 兼容接口并不兼容：有的用 reasoning_effort，有的用 enable_thinking，有的只接受开关，不接受 effort 档位。

v3.16.0 增加了 Codex Chat 思考能力自适应。CC Switch 会根据供应商名称、base URL 和模型名注入对应参数；OpenRouter、DeepSeek、StepFun 这类有 effort 档位的供应商会透传等级，Kimi、GLM、Qwen、MiniMax、MiMo、SiliconFlow 这类只暴露思考开关的供应商则会丢弃 effort 等级。

这点值得单独看：Codex UI 里调了思考等级，并不代表每个第三方模型都会按同样语义执行。供应商接口只给开关时，等级调节不会产生实际效果。

历史会话也被一起修

这次更新不只做新路由，还处理了 Codex 第三方供应商的身份问题。过去 Codex 会按 model_provider 过滤可恢复历史，供应商 id 一变，老会话可能看起来像消失了。

v3.16.0 把第三方 Codex 供应商统一归入稳定的 custom model-provider 桶，并提供一次性迁移：改写历史 JSONL 会话与 state_5.sqlite 线程表，原文件备份到 ~/.cc-switch/backups/codex-history-provider-migration-v1/。这类迁移不改变模型能力，但会影响老会话能不能被找回。

“任意大模型”的边界

把这次更新称为“Codex 接入任意大模型”可以理解，但要加边界：它依赖上游能提供可兼容的 Chat Completions 接口，或者通过 cc-router 这类路由器把 Anthropic / OpenAI 协议上游翻译成 Codex 能调用的 /v1/responses 或等价接口。

cc-router 文档也给出类似路径：Codex CLI 和 Codex Desktop 共用 ~/.codex 配置，可以把自定义 provider 指向本地路由服务，由路由器再分发到不同虚拟模型槽。安全边界同样清楚：~/.codex/auth.json 会保存访问 token，不应提交到仓库；本地路由端口只应暴露在可信网络。

OpenAI 在 2026 年 5 月 29 日更新 CodeX app 26.527，把 Computer Use 带到 Windows。Windows 版现在能让 CodeX 在前台看屏幕、点击、输入，并把手机端远程控制接到 Windows 设备上。

更新内容：Windows 终于补上 Computer Use

OpenAI 的 CodeX changelog 把这次更新列在 2026 年 5 月 29 日，版本号为 26.527，标题是 “Computer use and mobile access on Windows”。三项变化很直接：

• Computer Use 现在可用于 Windows，CodeX 可以在前台操作 Windows 桌面应用。
• 远程控制支持 Windows 设备，可从 ChatGPT iOS / Android 应用，或另一台运行 CodeX 的 Mac，启动或查看 Windows 设备上的 CodeX 工作。
• Profile 区域新增个人资料、用量统计和 token 活动信息。

这不是模型发布，也不是 IDE 插件更新。它补的是 CodeX 从“代码代理”走向“桌面代理”的平台覆盖。4 月 16 日 OpenAI 发布 CodeX 桌面操控能力时，Computer Use 先落在 macOS；5 月中旬手机端远程控制上线时，官方仍写着 Windows 支持“coming soon”。现在这条线补上了。

Windows 版的关键限制：只能前台操作

OpenAI 文档对 Windows 的边界写得很明确：CodeX 在 Windows 上运行 Computer Use 时，目标应用需要保持在当前活动桌面可见。它会移动鼠标、输入内容、接管前台窗口，不能像 macOS 背景电脑操控那样在同一个桌面会话里与你并行工作。

这决定了 Windows 版的第一批真实场景：

• 让 CodeX 打开桌面应用，复现只能在 GUI 中出现的 bug。
• 在浏览器或本地客户端里跑一段必须手动点击的流程。
• 检查应用设置、安装向导、登录后页面、桌面端数据源。
• 通过手机端远程查看进度，必要时给 CodeX 追加指令。

不适合的场景也很清楚：你想一边在同一个 Windows 桌面继续工作，一边让 CodeX 在后台点击别的窗口。官方建议是，要么让设备保持解锁并联网后离开桌面，要么把 CodeX 放进 Windows 虚拟机，让它接管 VM 而不是主桌面。

和 macOS 的差异：没有 Locked Use

此前 macOS 版的一个强功能是 locked computer use：Mac 锁屏后，CodeX 仍可在受控窗口里临时解锁并继续操作应用。OpenAI 文档把这项能力限定为 macOS。Windows 目前没有对应机制，文档直接写明：Locked use is for macOS；Windows 上 Computer Use 是前台能力。

这不是小差异。对个人开发者，Windows 版已经足够处理“我不想自己点 UI”的任务；对企业或长任务自动化，它仍需要更谨慎的运行环境设计。远程控制能让手机端介入，但不能改变 Windows 前台接管的物理事实。

可用范围：部分地区暂不可用

OpenAI 文档还给出区域限制：CodeX app 的 Computer Use 现在支持 macOS 和 Windows，但在发布时不面向欧洲经济区、英国和瑞士开放。使用前需要在 CodeX 设置中安装 Computer Use 插件；macOS 需要授权屏幕录制和辅助功能，Windows 侧重点则是保持目标窗口可见。

权限模型仍然重要。Computer Use 会处理屏幕内容、截图、窗口、菜单、键盘输入和剪贴板状态。OpenAI 建议用户把任务范围收窄，对敏感流程保持在场，审批应用权限，不要让 CodeX 在错误窗口里继续操作。

这套提示不是合规套话。桌面操控类 Agent 的失败模式和代码补全不同：它可能点错按钮、改错设置、把敏感内容带入上下文。Windows 用户拿到能力之后，第一步不是把所有软件都交给 CodeX，而是用一个可回滚、低风险的窗口验证它的可靠性。

CodeX 过去几个月的路线很清晰：先做独立桌面 app，再加 Computer Use、in-app browser、插件、远程 SSH、手机端远程控制。Windows Computer Use 上线后，OpenAI 把开发者主机覆盖从 Mac 扩到更大的 PC 基盘。

这会改变 CodeX 的定位。它不再只是终端里的代码执行器，也不是只在 GitHub PR 上工作的云代理。它开始接近一个可以跨代码、浏览器、桌面应用执行任务的本地工作台。

但能力边界也要看清：

• Windows 上是前台操控，不是后台并行。
• 远程手机端是控制与监督入口，不是在手机上本地执行代码。
• 图形界面任务适合 Computer Use；本地 Web 应用验证仍应优先用 CodeX in-app browser。
• 敏感账户、支付、隐私、网络与安全设置仍需要人工在场。

这次更新的实质信号是：OpenAI 正在把 CodeX 从“会写代码”推进到“能操作开发环境”。Windows 支持让这个方向不再只属于 Mac 用户。真正要验证的是后续两个问题：前台操控的稳定性够不够做日常 QA，以及远程控制能不能让长任务在 Windows 设备上持续跑完。

Anthropic 在 2026 年 5 月 28 日发布 Claude Opus 4.8。它不是 Mythos 级别的新旗舰，而是面向编码 Agent、长上下文知识工作和企业部署的 Opus 线更新：默认 100 万 Token 上下文、API 价格不变、fast mode 加价换速度，并把 Claude Code 的动态工作流推到研究预览。

发布状态：Opus 4.8 已全量可用

Anthropic 官方发布页显示，Claude Opus 4.8 于 2026 年 5 月 28 日上线，开发者可通过 Claude API 使用 claude-opus-4-8。官方称它是当前“generally available”范围内能力最强的 Claude 模型，但同时明确：Mythos 级别模型仍在后面，预计“未来几周”才会面向更广客户开放。

API 价格没有跟随版本号上涨：

fast mode 目前是 Claude API 的研究预览能力。Anthropic 文档称，它可让同一模型的输出速度最高提升至 2.5 倍，但价格按常规模式的 2 倍计费。Axios 的报道则把这条线索解读为：Anthropic 正在把模型更新和成本控制放在同一叙事里，而不是只讲能力排名。

API 变化：100 万上下文、128K 输出、中途 system 消息

Claude API 文档把 Opus 4.8 的开发者变化列得很清楚：

• 模型 ID：claude-opus-4-8
• 上下文窗口：Claude API、Amazon Bedrock、Vertex AI 默认支持 100 万 Token；Microsoft Foundry 为 200K。
• 最大输出：128K Token。
• prompt cache 门槛：最低可缓存 prompt 长度降至 1,024 Token。
• 中途系统消息：Messages API 现在允许在 messages 数组里追加 role: "system"，用于在长任务中更新权限、预算或环境上下文，同时保留前文 prompt cache 命中。
• 拒绝响应细节：stop_details 的拒绝类别公开文档化，便于应用区分不同拒绝原因。

两个约束也被继承下来：Opus 4.8 与 Opus 4.7 一样，不支持非默认 temperature、top_p、top_k；也不支持手工设置 extended thinking budget。开发者需要使用 adaptive thinking 和 effort 参数控制推理深度。

这不是小改动。中途 system 消息直接服务长链路 Agent：任务跑到一半，权限变化、预算变化、环境变化，不再必须把完整系统提示重塞一遍。对依赖 prompt cache 的 Agent harness，这会影响实际成本。

Claude Code 同步上新：dynamic workflows

和 Opus 4.8 一起发布的，是 Claude Code 的 dynamic workflows。Anthropic 的定义是：Claude 可以把一个大任务拆成多个子任务，在同一会话中运行数十到数百个并行 subagents，再做交叉验证后汇总。

官方给出的典型场景包括：

• 大代码库 bug hunt、性能审计、安全审计。
• 框架迁移、API 废弃迁移、语言迁移。
• 高风险改动前的多路独立验证。

这项能力目前是研究预览，面向 Claude Code CLI、Desktop、VS Code 扩展，以及 API、Bedrock、Vertex AI、Microsoft Foundry 等通道。计划层面，Max、Team 默认可用；Enterprise 默认关闭，需要管理员开启。Claude Code 里还新增了 ultracode 设置：把 effort 拉到 xhigh，并允许 Claude 自动判断是否启用 workflow。

官方也给了成本提示：dynamic workflows 会明显消耗更多 tokens。第一次触发时，Claude Code 会展示即将执行的内容并要求确认。这个设计很现实。多 Agent 并行不是免费能力，适合代码库级迁移和审计，不适合日常小修小补。

能力叙事：不是 Mythos，但补 Opus 4.7 的短板

Anthropic 对 Opus 4.8 的官方定位比较克制：相比 Opus 4.7，是“modest but tangible improvement”。重点不在参数规模或新模态，而在三个方向：

• 长周期 agentic coding：更好的长上下文处理、更少 compaction 后跑偏。
• 推理 effort 校准：不同 effort 档位下表现更稳定。
• 工具触发：减少该调用工具却跳过工具的情况。

这些说法目前主要来自 Anthropic 官方口径和早期客户引述。Cognition 在官方发布页中表示，Opus 4.8 修复了 Opus 4.7 的注释冗长和工具调用问题；Cursor、Harvey、Databricks、Hebbia 等也给出正面反馈。但这些都是发布页里的客户证言，不等同于独立基准复现。

官方还特别强调“honesty”。Anthropic 称，内部评估显示 Opus 4.8 比前代“约四倍更少”让自己写出的代码缺陷未经提示地通过；alignment 团队则认为其支持用户自主性、维护用户利益等 prosocial traits 达到新高，misaligned behavior 低于 Opus 4.7，接近 Claude Mythos Preview。

这里需要分清两层：模型是否更少胡说，是官方评测结论；真实工程项目里是否减少返工，还需要外部长期使用数据。

分发：AWS、GitHub Copilot 同步接入

AWS 在 5 月 28 日同步宣布 Claude Opus 4.8 可通过 Amazon Bedrock 和 Claude Platform on AWS 使用。Bedrock 路径强调数据留在 AWS 基础设施内，并可结合 Guardrails、Knowledge Bases 和区域数据驻留能力。对企业客户来说，这比直接 API 更像采购和合规入口。

GitHub 也在同日宣布 Claude Opus 4.8 进入 GitHub Copilot，覆盖 Copilot Pro+、Business、Enterprise 用户，可在 VS Code、Visual Studio、Copilot CLI、Copilot cloud agent、github.com、GitHub Mobile、JetBrains、Xcode、Eclipse 中选择。上线初期采用逐步 rollout；在 2026 年 6 月 1 日 Usage Based Billing 上线前，Opus 4.8 按 15X premium request multiplier 计量。

这说明 Opus 4.8 的核心战场仍是开发者工作流。Anthropic 自己推 Claude Code dynamic workflows，GitHub 则把它接入 Copilot Agent 体系，AWS 提供企业部署入口。模型升级和渠道分发是同一天发生的。

看点：Opus 线在给 Mythos 铺路

Opus 4.8 的关键不是“最强模型”这个标签，而是 Anthropic 公开承认：更高智能的 Mythos-class 模型尚未普遍开放，原因是网络安全防护要求更高。现在的小范围 Claude Mythos Preview 已在 Project Glasswing 下用于网络安全工作。

这让 Opus 4.8 更像一个过渡版本：把可商用、可广泛部署的 Opus 线继续打磨，同时把动态工作流、effort 控制、fast mode、中途 system 消息这些 Agent 基础设施补上。真正的分水岭可能不在 4.8，而在 Mythos-class 模型是否能带着足够安全边界进入公开市场。

对开发者而言，短期需要看的不是发布页排名，而是三个可验证问题：

• 迁移到 claude-opus-4-8 后，长任务 compaction 后是否更少跑偏。
• adaptive thinking + effort 控制是否降低无效思考 token。
• dynamic workflows 在大代码库审计和迁移中，是否能稳定产出可合并结果。

这些问题要靠真实项目跑出来。发布日能确定的事实只有一个：Anthropic 正在把 Opus 线从“更会回答”继续推向“更会长期执行”。

小米 MiMo-V2.5 系列 API 在 2026 年 5 月 27 日 0 点完成一次永久调价。核心变化不是单一模型促销，而是价格表、Token Plan 和缓存计费规则同时重写：V2.5 Pro 国内缓存命中输入价降到每百万 Token 0.025 元，V2.5 降到 0.02 元；官方称最高降幅达到 99%。

价格表被重新压到 DeepSeek 级别

小米 MiMo 开放平台公告显示，本次调价在北京时间 2026 年 5 月 27 日 0 点生效，全球同步。官方给出的总括口径是：MiMo-V2.5 系列 API 永久降价，最高降幅 99%，且不再按输入长度区分价格。

新的国内按量价格如下：

海外价格同步更新：

这个价格结构把真正的成本重心放在缓存命中率上。对长上下文 Agent、代码助手和多轮工具调用来说，缓存命中输入的价格比输出价格更敏感。小米这次把 V2.5 Pro 缓存命中输入从旧 V2 Pro 的 1.40 元 / 百万 Token 压到 0.025 元 / 百万 Token，降幅接近 98.2%；如果按旧 V2 Pro 256K-1M 区间的 2.80 元计算，降幅约 99.1%。

Token Plan 从买额度变成买 Credits

这次不是只改按量 API。小米还把 Token Plan 的额度和换算规则一起重置。

官方价格图显示，Token Plan 在价格不变的情况下提高 Credits：

新的 Credits 换算规则更贴近实际调用成本：mimo-v2.5-pro 缓存命中、缓存未命中、输出分别消耗 2.5、300、600 Credits / Token；mimo-v2.5 分别消耗 2、100、200 Credits / Token。相比旧版 V2 Pro 的 140、700、2100 Credits / Token，缓存命中输入的权重被大幅压低。

小米还宣布，所有仍在有效期内的 Token Plan 用户额度在 5 月 27 日 0 点全量重置，且按新规则执行。这个动作会直接影响已经通过 MiMo Orbit 获得套餐权益的开发者，也覆盖 Apache Software Foundation 专属福利用户。

免费 Token 激励提前耗尽

MiMo Orbit 的 100T Token 创造者激励计划在 4 月 28 日启动，原计划持续到 5 月 28 日。小米在本次公告中披露，截至 2026 年 5 月 26 日 16:08，北京时间，100T Token 已全部发放完毕，活动提前结束。

这解释了调价时点：小米先用免费额度扩大开发者触达，再把价格体系改成可长期使用的按量和套餐模型。免费激励结束后，API 单价就是留存开发者的主要杠杆。

降价理由指向推理系统，而不是模型缩水

小米官方把降价归因于推理系统优化。公告提到，团队基于 SGLang HiCache 支持 SWA（Sliding Window Attention），将 KV Cache 在 GPU 显存、CPU 内存、SSD 等多级存储间的数据传输量降到优化前约 1/7，可缓存 Token 数提高到优化前约 5 倍。同时，团队还调整了专家并行方案和输入长度分桶策略。

这部分目前只有官方口径，尚未看到第三方对新价格下吞吐、延迟、缓存命中率和稳定性的独立复测。对开发者更实用的验证方式，是用自己的 Agent 工作流跑一轮长上下文任务，分别记录缓存命中比例、输出 Token、端到端延迟和实际账单。

开源模型价格战进入缓存计费阶段

MiMo-V2.5 系列在 4 月 28 日以 MIT 协议开源，官方称两个版本都支持 100 万 Token 上下文窗口。其中，MiMo-V2.5-Pro 面向 Agent 和 Coding，MiMo-V2.5 面向文本、图像、视频和音频理解。

这次降价把竞争点从“每百万 Token 名义价格”推进到三个更细的指标：

• 缓存命中输入能否真正便宜；
• 长上下文任务是否能保持稳定命中；
• 套餐 Credits 是否足够透明，能否让开发者预估月度成本。

如果只看价格表，MiMo-V2.5 Pro 已经进入国内主流推理模型的低价区间。但对 Agent 场景，账单通常不是由单轮 prompt 决定，而是由多轮工具调用、长上下文复用、缓存写入和输出长度共同决定。小米给出的新规则降低了缓存命中输入成本，真正的成本优势还要看实际工作流是否能吃到缓存。

Code Wiki，基于 Gemini 自动生成并持续更新 GitHub 仓库文档。同一赛道上，Cognition 的 DeepWiki 已先发运行。学术界 ACL 2026 收录的独立评测显示，多智能体代码文档框架在 Claude Sonnet 4 上质量得分 68.79%，领先 DeepWiki 基线 4.73%。AI 代码文档生成从玩具进入产品竞争阶段。

1. Google Code Wiki：自动再生的仓库文档

2025 年 11 月 13 日，Google 在 Developers Blog 公开预览 Code Wiki，基于 Gemini 模型，可为任意公开 GitHub 仓库自动生成结构化 Wiki 文档。

核心机制：扫描完整代码库，生成层次化文档，每次代码 push 后自动重建。文档内含架构图、类图、序列图（Mermaid 格式），所有符号（函数、类、模块）均带链接可跳转至源码。此外内置 Gemini 驱动的问答聊天代理，以最新 Wiki 作为知识上下文。

访问方式：codewiki.google/<owner>/<repo> 直接生成。私有仓库的 Gemini CLI 扩展已在等待名单中，尚未开放。

Google 在博客中称该系统”加速代码理解”，目标场景是开发者 onboarding 和理解陌生代码库。

2. 赛道对手：Cognition DeepWiki

Cognition AI（Devin 团队）推出的 DeepWiki 在 2025 年初就已上线，访问模式相同：deepwiki.com/<owner>/<repo>。

两者的技术路径差异：

两者定位高度重合：输入 GitHub 仓库地址，输出可交互的知识库。区别在于 Code Wiki 强调”持续更新”——代码变了文档自动重建，而 DeepWiki 需要手动重新生成。

3. 学术评测：CodeWiki 框架超越 DeepWiki

除了 Google 的产品，学术界也给出了独立评测。FSoft AI Center 与墨尔本大学联合开发的 CodeWiki 开源框架被 ACL 2026 收录，论文标题为 “Evaluating AI’s Ability to Generate Holistic Documentation for Large-Scale Codebases”。

该框架采用三阶段架构：

1. 层次分解 — 将仓库分区为连贯模块，保留多粒度架构上下文
2. 递归多智能体处理 — 动态任务委派，扩展至仓库级别仍保持质量
3. 多模态合成 — 文本描述 + Mermaid 可视化（架构图、数据流图、序列图）

评测基于自建基准 CodeWikiBench（21 个仓库，86K–1.4M LOC，覆盖 8 种编程语言）。关键结果：

在 Python 项目 OpenHands（229K LOC）上，CodeWiki 得分 82.45% vs DeepWiki 73.04%。TypeScript 项目 Puppeteer（136K LOC）差距更大：83.00% vs 64.46%。

系统语言（C/C++）是 DeepWiki 唯一领先的类别，差距约 3 个百分点。这与 LLM 对底层语言的代码理解能力整体偏弱一致。

需要注意的是，该评测中 CodeWiki 使用的是 Claude Sonnet 4 作为后端 LLM，DeepWiki 的具体模型配置未在论文中披露。论文作者来自 FSoft 和墨尔本大学，非 Google 或 Cognition 关联方。

4. 代码文档自动化的信号

三个值得注意的点：

• 产品化竞争已经启动：Google 和 Cognition 用几乎相同的入口模式（<product>.<domain>/<owner>/<repo>）争夺同一场景，说明这个需求的用户价值已被验证。
• “持续更新”是差异点：代码文档最大的痛点不是”写不出来”，而是”写出来就过期”。Code Wiki 的自动重建机制如果真正可用，解决了文档维护的核心瓶颈。
• 开源框架提供独立基准：学术界的 CodeWikiBench 是目前唯一公开可复现的仓库级文档质量评估基准，后续新进入者可以用同一把尺子衡量。

X Premium+ 用户不再局限于 xAI 官网使用 Grok。通过 OAuth 认证，Hermes Agent、OpenClaw、OpenCode 三大开源 AI Agent 框架已相继接入 Grok API，月费 40 美元的订阅成了最具性价比的 Agent 模型调用方案。

X（原 Twitter）Premium+ 订阅用户现可通过 xAI 的 OAuth 认证流程，在 Hermes Agent、OpenClaw、OpenCode 三款开源 AI Agent 框架中直接调用 Grok 模型。

此前，Grok 的使用场景基本被限制在 x.com 和 grok.com 的网页界面内。这次 OAuth 打通意味着：一个 $40/月的 X Premium+ 订阅，不仅能刷信息流、用 Grok 聊天，还能作为底层模型驱动本地运行的 AI Agent。

技术实现

认证方式：浏览器 OAuth 2.0 PKCE 流程。用户在 Hermes Agent 中执行 hermes auth add xai-oauth，跳转到 accounts.x.ai 完成授权，token 自动保存到本地 ~/.hermes/auth.json，无需手动配置 API key。OpenClaw 的接入方式类似，同样通过 Grok OAuth 绑定订阅。

模型能力：默认调用 grok-4.3，端点为 https://api.x.ai/v1。单张 bearer token 覆盖对话、TTS、图像/视频生成和转录。Hermes 底层复用 codex_responses 适配器，reasoning、tool-calling、streaming 和 prompt caching 均正常工作。

后台刷新：access token 过期后 Hermes 会在后台自动刷新，不需要用户重新登录。远程/无头模式下可通过 --no-browser 配合 SSH 端口转发完成授权。

性价比算一笔账

Grok API 按量付费的价格是 输入 $2/M tokens，输出 $6/M tokens，上下文窗口 200 万 tokens。作为对比，Claude Sonnet 4.6 的输入价格是 $3/M tokens，输出 $15/M tokens。

X Premium+ 月费 $40（年付 $395），包含较高的 Grok 使用额度。对于运行本地 Agent 的开发者来说，这个额度远比直接按量调用 xAI API 或其他模型便宜。这也是为什么有开发者在 X 上直接评价：”X Premium Plus 成为最具性价比的订阅产品。”

三个 Agent 的差异化定位

Hermes Agent（Nous Research）—— 定位自学习 AI Agent。内置学习闭环、RL 研究支持，执行速度快。在 Grok OAuth 接入上走得最快，官方文档已覆盖完整的中文配置指南。还支持 X 搜索工具作为 Agent 的技能之一。

OpenClaw —— 本地优先的开源 Agent 框架。支持更广泛的渠道统一（Telegram、Discord、Slack 等），社区技能生态更大。xAI 官方也有独立页面介绍如何在 OpenClaw 中使用 Grok。

OpenCode —— 同样支持 X Premium 订阅通过 Grok OAuth 调用，面向 coding 场景。

三者定位不同但共享同一个 Grok OAuth 认证路径，用户可以根据自己的 Agent 使用场景选择框架。

已知问题

xAI 的 OAuth 后端曾出现对标准 SuperGrok 订阅用户返回 HTTP 403 的情况（OAuth 层级 gating 问题）。兜底方案是改用 API key：设置 XAI_API_KEY 环境变量，将 provider 切换为 xai 即可绕过 OAuth。

DeepSeek 宣布 V4-Pro 限时 75% 折扣结束后，价格永久锁定在原定价的 1/4。这意味着目前的促销价就是未来的常态价，而非回归原价。

事件要点

2026 年 5 月 23 日，DeepSeek 开放平台同时公布价格调整：

• V4-Pro 限时 2.5 折（75% off）优惠活动，原定 5 月 31 日结束，现改为 V4-Pro 价格永久调整为原定价的 1/4

与此同时，全部模型的缓存命中（Cache Hit）价格也永久降至原价的 1/10，于 4 月 26 日 12:15 UTC 生效。

V4-Pro 具体价格

对比同期调整的 V4-Flash：输入缓存命中 $0.0028/M、输入缓存未命中 $0.14/M、输出 $0.28/M。V4-Pro 永久价约为 V4-Flash 的 1.3 倍（缓存命中）至 3.1 倍（缓存未命中），差距在同级别模型中处于较低水平。

背景：国产模型价格战

DeepSeek 此次调价并非孤立事件。2025 年 2 月，DeepSeek 曾率先推出错峰时段 75% 折扣（夜间空闲时段降价），但同年 9 月取消了该政策。2026 年 4 月的这次调整，将价格直接拉到原价 1/4 的位置且不再区分时段。

同期，字节豆包、阿里通义、智谱清言等国产模型也在持续下调 API 价格。V4-Pro 永久定价后，输入缓存命中 $0.003625/M 的水平在同参数量级模型中处于行业低位。

影响

限时折扣变永久定价，直接消除了用户的”折扣结束后续费暴涨”顾虑。对 Agent 场景尤其利好——长链路调用可以按当前促销价做长期成本规划，而不需要为价格回弹留预算冗余。

腾讯应用宝团队推出操作系统级 AI Agent Marvis（马维斯），Windows/Mac/安卓三端可用，无需邀请码直接开放，每日 1000 万免费 Token。桌面 Agent 赛道再添大厂玩家。

产品定位与架构

Marvis 定位为”操作系统 Agent”，不是聊天机器人。它将系统、文件、应用、网络搜索纳入同一个 AI 中间层，用户通过自然语言指令直接操控整台电脑。

内置 6 个协同智能体，由 1 个 Supervisor Agent 统一调度：

• PM Agent：接收用户指令，拆解任务并分发给子 Agent，支持多任务并行执行
• File Agent：文件搜索、格式转换、去重合并、表格分析出报表、OCR 识别
• Computer Agent：管理系统设置（改默认浏览器、查硬件状态、设开关机时间、检测高耗电进程）
• APP Agent：联动常用软件，跨应用操作（查机票、电商比价）
• Search Agent：网络搜索与信息聚合
• Browser Agent：接管网页交互、数据抓取

端云协同与隐私模式

提供两种运行模式：

• 效率模式：依托云端大模型完成语义理解和任务规划，操作执行在本地完成
• 隐私模式：全部对话与数据在设备本地处理，不上传云端，断网可用

敏感操作设有 L2 级安全兜底机制，需用户确认后才执行。

跨端协同

支持 Windows/Mac/安卓三端，同账号互通。iOS 版本仍在开发中。

手机端可直接查看电脑屏幕并实时接管，PC 锁屏状态下手机仍可远程输入密码解锁操控。桌面版负责本地操作执行，APP 版承担远程指令发出与状态同步。

开放策略

无需邀请码，官网 marvis.qq.com 直接下载。每人每天 1000 万免费 Token 额度。