1. 执行框架旁边：TaoToken Key 在 MiMo Desktop 中如何被调用
在 MiMo Desktop 里把执行框架指向自定义 Base URL 后，如果 Claude Code 报401 invalid x-api-key，通常不是 Key 失效，而是ANTHROPIC_BASE_URL与ANTHROPIC_AUTH_TOKEN没有同时生效。先去 TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=miMo_intro 拿 Key，Base URL 统一写 https://taotoken.net/api。小米 MiMo Desktop 开放邀测后，智能分派会把任务路由给不同模型、Agent 和执行框架；对开发者来说，真正要观察的不是“哪个模型更强”，而是执行框架调用时谁在消耗 Token、消耗在输入还是输出、缓存有没有命中。TaoToken 在这个链路里只做两件事：发 Key、给接口地址。它不替 MiMo Desktop 做任务规划，也不替执行框架决定模型，只记录每一次带YOUR_API_KEY的请求最终落在哪个模型、哪个工具回调上。
把视角放到“执行框架旁边”，事情会清楚很多。MiMo Desktop 的智能分派决定任务走质量优先还是速度优先，执行框架决定用哪套 CLI、哪套配置、哪套工具链，而 TaoToken 的 Key 和执行框架的 Base URL 共同决定“这次调用从哪个入口发出、用哪个 Key 计费”。如果你正在 Beta 里观察 Token 消耗，建议先把执行框架的供应商切成 TaoToken，再让 MiMo Desktop 的分派去触发任务。这样你看到的是 Key 维度的轨迹，而不是只看到 Desktop 界面上一个模糊的进度条。
下面这套步骤围绕三件事展开：执行框架调用配置、Key 轨迹、Token 消耗对照表。配置覆盖 Claude Code、Codex CLI、CC Switch 三件套；轨迹覆盖请求头、usage 字段、控制台用量；对照表覆盖 MiMo Desktop 分派场景下常见的任务类型。所有命令都在本地执行，不涉及直连生产库，也不建议让 Agent 绕过执行框架去碰数据库。
2. 拿 Key 与确认 Base URL：控制台步骤不要写进执行框架配置
第一步不是改 Claude Code，也不是改 Codex，而是先确认 TaoToken 侧的 Key 和 Base URL。打开 TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=miMo_key_step ，进入控制台创建 API Key。创建时建议按用途命名，例如mimo-desktop-exec、claude-code-local、codex-cli-local，不要用一个 Key 跑所有执行框架。原因很简单：当 MiMo Desktop 的智能分派触发多个 Agent 时，你至少要能分辨 Token 消耗来自哪条链路。
Base URL 统一使用：
https://taotoken.net/api注意这个地址不要加 UTM 参数，不要加尾斜杠，也不要在后面随手拼/v1/chat/completions。不同客户端对路径拼接策略不同：Claude Code 会自己拼接 Anthropic 风格路径，Codex CLI 可能按wire_api拼接，CC Switch 则把 Base URL 当成供应商根地址。先用根地址，再用本地请求验证可达性。
可以用下面的命令验证 Key 是否有效。把YOUR_API_KEY替换成控制台新建的 Key：
curl -sS https://taotoken.net/api/v1/models \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" | jq -r '.data[].id'如果返回模型列表，说明 Key 和 Base URL 至少有一层是通的。如果返回 401，先检查请求头里是不是同时带了Bearer和旧 Key；如果返回 404，检查 Base URL 是不是被写成了https://taotoken.net/api/v1或https://taotoken.net/api/。这两个问题在执行框架里会以不同报错出现，后面会分别说明。
另外，控制台里的 Key 只在创建时完整显示一次。执行框架配置里统一用占位符YOUR_API_KEY，不要把真实 Key 写进博客、截图或 Git 提交。如果你在团队里共享执行框架配置，建议使用环境变量或本地密钥文件，而不是把 Key 硬编码进settings.json。
3. Claude Code 侧：settings.json 与 ANTHROPIC_* 的最小配置
Claude Code 是很多开发者观察执行框架调用的第一站。它的配置入口通常有两类：项目级或用户级settings.json，以及 shell 环境变量。两者选其一即可，不要同时写两套互相冲突的值。先给出最小settings.json示例：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "YOUR_MODEL_ID" } }如果你更习惯用 shell 环境变量，可以写成：
export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_AUTH_TOKEN="YOUR_API_KEY" export ANTHROPIC_MODEL="YOUR_MODEL_ID"这里的YOUR_MODEL_ID以 TaoToken 控制台或模型列表里实际可用的 ID 为准。不要凭记忆写一个模型名，否则 Claude Code 可能在启动时通过，但在第一次请求时返回model not found。配置完成后，用claude启动，观察第一行日志里请求地址是否是你设置的 Base URL。如果日志里仍然出现默认的 Anthropic 域名，说明环境变量没有被子进程继承，或者settings.json的层级被更高优先级配置覆盖。
Claude Code 常见报错与排查顺序：
401 invalid x-api-key：Key 没带、Key 写错、或者ANTHROPIC_AUTH_TOKEN与ANTHROPIC_API_KEY同时存在且值不同。先只保留一个认证变量。404 not found：Base URL 写成了https://taotoken.net/api/v1，或者客户端自己拼接了重复路径。改回https://taotoken.net/api再试。model not found：ANTHROPIC_MODEL不在当前 Key 可用范围内，或者模型 ID 大小写不一致。去控制台确认模型 ID。- 请求能通但界面卡住：可能是流式响应被本地代理截断。先在本地用
curl测试非流式请求，再回到 Claude Code。
如果你希望把 Claude Code 的执行日志和 TaoToken 控制台用量对起来，可以在启动 Claude Code 时保留终端输出，并把每次请求的时间戳记下来。后面第 6 节会给出从日志里提取 usage 的本地命令。
4. Codex CLI 侧：config.toml 配置与不要混用 ANTHROPIC_*
Codex CLI 的配置习惯和 Claude Code 不同，它通常读config.toml，并且不认ANTHROPIC_*变量。把 Claude Code 的ANTHROPIC_BASE_URL直接套到 Codex 上，最常见的结果是 Codex 仍然访问默认供应商，或者报missing env_key。正确做法是定义一个 provider，再把模型指向这个 provider。
~/.codex/config.toml示例：
model = "YOUR_MODEL_ID" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "responses"然后在 shell 里设置：
export TAOTOKEN_API_KEY="YOUR_API_KEY"如果你的 Codex 版本使用wire_api = "chat"，就按版本要求调整，但base_url仍然保持https://taotoken.net/api。改完后运行一次只读任务，例如让 Codex 读取当前目录的README.md并总结，不要一上来就跑修改文件的命令。观察终端输出中 provider 名称是否变成taotoken，以及请求是否返回 usage 字段。
Codex 侧常见问题：
missing env_key：config.toml里写了env_key = "TAOTOKEN_API_KEY"，但 shell 没有导出这个变量。用echo $TAOTOKEN_API_KEY确认。401：TAOTOKEN_API_KEY为空或 Key 已删除。不要试图用ANTHROPIC_AUTH_TOKEN替代，Codex 不读它。404：base_url被写成了完整端点，例如https://taotoken.net/api/v1/chat/completions。改回根地址。- 请求发出但 Token 不增长：先确认 Codex 是否真的走了
taotokenprovider，再看模型 ID 是否被本地缓存到了旧值。
Codex 和 Claude Code 可以同时使用 TaoToken，但建议用不同的 Key。这样在 TaoToken 控制台里，你能一眼看出是 Claude Code 的会话在涨 Token，还是 Codex 的批处理在涨 Token。MiMo Desktop 的智能分派如果同时触发多个执行框架，多 Key 策略会比单 Key 更容易排查。
5. CC Switch 三件套：Provider、API Key、Base URL 的落地顺序
CC Switch 这类切换工具的价值在于把多个供应商配置集中管理。无论你用的是哪一版界面，核心都是三件套：Provider 名称、API Key、Base URL。建议按下面顺序填，避免“Key 填了但 Provider 没选中”这种低级问题。
| 字段 | 建议值 | 说明 |
|---|---|---|
| Provider | taotoken | 自定义名称，便于在执行框架日志里识别 |
| Base URL | https://taotoken.net/api | 根地址，不加 UTM，不加尾斜杠 |
| API Key | YOUR_API_KEY | 建议与 Claude Code、Codex 分开 |
| 协议类型 | OpenAI Compatible / Anthropic Compatible | 按执行框架要求选择 |
| 默认模型 | YOUR_MODEL_ID | 以控制台可用列表为准 |
如果 CC Switch 支持导出配置，导出的内容里不要包含真实 Key。可以在本地用环境变量占位，例如：
providers: - name: taotoken base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} protocol: openai落地顺序建议是：
- 先在 CC Switch 里新增 Provider，只填 Base URL，不填 Key，保存。
- 再把 Key 填入，并立即做一次“测试连接”。
- 测试通过后，把默认 Provider 切到
taotoken。 - 最后再启动 Claude Code 或 Codex，确认它们读取的是 CC Switch 当前选中的配置。
如果你在 CC Switch 里同时保留了官方供应商和 TaoToken，切换后一定要重启执行框架进程。很多 CLI 只在启动时读一次配置，运行中切换 Provider 不会自动生效。MiMo Desktop 的智能分派如果调用的是已经启动的 Agent 进程，那它看到的仍然是旧 Provider，Token 自然不会出现在 TaoToken 控制台。
6. Key 轨迹：从请求头到 usage 字段，谁在消耗 Token
把执行框架接到 TaoToken 后，Key 的轨迹大致如下：
- 执行框架启动，读取
settings.json、config.toml或 CC Switch 配置。 - 执行框架把
YOUR_API_KEY放进请求头，常见形式是Authorization: Bearer YOUR_API_KEY或x-api-key: YOUR_API_KEY。 - 请求发往
https://taotoken.net/api。 - TaoToken 根据 Key 识别调用方，并把请求路由到对应模型。
- 模型返回响应，响应体里通常带
usage字段。 - TaoToken 控制台按 Key、模型、时间窗口记录用量。
Claude Code 和 Codex 的请求头格式不同，但 usage 字段的结构通常接近。下面是一个响应片段的示例，实际字段以返回为准：
{ "id": "chatcmpl_xxx", "model": "YOUR_MODEL_ID", "usage": { "input_tokens": 1234, "output_tokens": 567, "cache_read_input_tokens": 800, "cache_creation_input_tokens": 200 } }如果你把执行框架的原始日志保存到本地，可以用jq提取每次调用的 Token 变化。例如：
cat codex-run.log \ | jq -r 'select(.usage) | [.model, .usage.input_tokens, .usage.output_tokens, .usage.cache_read_input_tokens] | @tsv' \ | column -tClaude Code 的日志格式可能不是逐行 JSON，可以先在启动时把输出重定向到文件，再用本地脚本按时间窗口聚合。关键不是工具本身，而是你要能回答三个问题：
- 这次请求用的是哪个 Key？
- 请求最终落在哪个模型？
- 输入 Token、输出 Token、缓存读取 Token 分别是多少？
在 MiMo Desktop 的智能分派场景里，同一个任务可能触发多次模型调用：一次用于理解材料，一次用于规划路径，一次用于生成成品，一次用于局部再生成。如果你只看到总 Token 上涨，却不知道哪一步在消耗，就很容易把“分派导致的多次调用”误判成“模型单价太高”。把 Key 按执行框架拆开，再结合 usage 字段，才能把消耗定位到具体步骤。
7. Token 消耗对照表：MiMo Desktop 分派场景下的观察维度
下面这张表不写具体数字，只写相对特征。因为不同模型、不同上下文长度、不同缓存策略都会让绝对值变化。你要观察的是“哪类任务容易让输入膨胀、哪类任务容易让输出膨胀、哪类任务可能命中缓存”。
| 任务类型 | 分派角色 | 输入 Token 主要来源 | 输出 Token 主要来源 | 缓存观察点 | 建议动作 |
|---|---|---|---|---|---|
| 纯对话问答 | 主模型 | 用户问题、少量上下文 | 简短回答 | 低 | 不需要过度优化 |
| 读取 Office 文件 | 解析器 + 模型 | 文件文本、表格结构 | 摘要、结构化结果 | 中 | 关注文件是否被重复读取 |
| 图片/音频理解 | 多模态模型 | 媒体编码、提示词 | 描述、标签 | 低 | 控制单次上传大小 |
| 浏览器检索 | 浏览器工具 + 模型 | 网页正文、搜索片段 | 提取结果、表单填写 | 低 | 限制抓取页数 |
| 长任务规划 | 规划模型 | 历史会话、任务目标 | 步骤列表、依赖关系 | 中 | 压缩历史上下文 |
| 局部再生成 | 执行模型 | 选中区域、修改描述 | 局部补丁 | 高 | 优先使用选择式编辑 |
| 版本回滚后重跑 | 执行模型 | 旧版本上下文 | 新版本结果 | 中 | 复用已有缓存 |
| 跨应用电脑操作 | 操作 Agent + 模型 | 屏幕截图、坐标、键盘鼠标事件 | 操作序列 | 低 | 记录回放，减少重复推理 |
这张表的用法是：当 TaoToken 控制台显示某个 Key 的 Token 上涨时，先对应到任务类型，再去看输入和输出哪边更大。输入大，通常是材料读取、网页抓取、历史上下文太长；输出大，通常是规划步骤太细、生成内容太长、局部再生成被误用成全量重写。缓存读取高，说明执行框架复用了之前的上下文，这是好事，但也要确认缓存内容没有过期。
MiMo Desktop 强调局部再生成和会话内缓存，这两点都会影响 Token 消耗。局部再生成让输出 Token 下降，缓存命中让输入 Token 中有一部分变成缓存读取。你在 TaoToken 控制台看到的计费口径，可能把缓存读取单独列出。不要只看总 Token，要看input_tokens、output_tokens、cache_read_input_tokens的相对比例。如果缓存读取占比高，说明执行框架的配置正在生效；如果每次请求都重新创建缓存，就要检查执行框架是否每次启动都换了 Key 或换了 Base URL。
8. 排障清单：401、404、429、上下文超限分别看哪里
执行框架接 TaoToken 后，报错基本集中在四类。下面按报错从早到晚排序。
401 / 403
- 检查 Key 是否复制完整，是否多了空格。
- 检查执行框架读的是哪个 Key：Claude Code 用
ANTHROPIC_AUTH_TOKEN，Codex 用TAOTOKEN_API_KEY，CC Switch 用界面里选中的 Provider。 - 检查是否同时存在多个认证变量，导致客户端发了错误的头。
404
- 检查 Base URL 是否为
https://taotoken.net/api。 - 检查是否误写成
https://taotoken.net/api/、https://taotoken.net/api/v1或完整端点。 - 检查客户端是否自动拼接了重复路径。可以在本地用
curl -v看实际请求 URL。
429
- 检查是否多个执行框架共用一个 Key，导致并发超过限制。
- 检查是否有循环任务在短时间内反复调用模型。
- 在 TaoToken 控制台按 Key 查看请求曲线，确认是突发还是持续。
上下文超限
- 检查执行框架是否把整个会话历史都塞进请求。
- 检查 MiMo Desktop 分派的任务是否把大文件全文传给了模型。
- 检查是否可以使用局部再生成、摘要、缓存来降低输入长度。
这些排查动作都不需要连生产库，也不需要把数据库连接串写进 Agent。执行框架只负责发模型请求，Token 消耗记录由 TaoToken 按 Key 汇总。你可以在本地保留请求日志，再和控制台用量做交叉验证。
9. 文末 CTA：把执行框架接到 TaoToken 的推荐路径
如果你已经走到这里，推荐按下面顺序完成接入：
- 先去模型对话页，确认当前可用的模型 ID 和协议类型。
- 再根据任务量选择 Coding Plan，避免在执行框架调试阶段频繁切换 Key。
- 创建专用 API Key，建议按 Claude Code、Codex、CC Switch 分开命名。
- 最后对照 Claude Code 文档，把
settings.json或ANTHROPIC_*配好，再用一个只读任务验证 Token 轨迹。
模型对话入口： https://taotoken.net/models/detail/chat?utm_source=taotoken_aicg_blog_end&utm_content=miMo_chat
Coding Plan 入口： https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=miMo_coding
创建 API Key： https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=miMo_keys
Claude Code 文档： https://taotoken.net/doc/ClaudeCodeAnthropic?utm_source=taotoken_aicg_blog_end&utm_content=miMo_claude_code
回到最初的问题：在 MiMo Desktop 的执行框架旁边，TaoToken Key 到底怎么被调用？答案是通过执行框架配置里的 Base URL 和认证变量被带到模型请求上。MiMo Desktop 的智能分派决定任务走哪条路，执行框架决定用哪套 CLI 和工具链，TaoToken 记录谁在消耗 Token。把 Key 按执行框架拆开，把 Base URL 统一成https://taotoken.net/api，再用 usage 字段和消耗对照表观察，你就能在 Beta 阶段看清每一次分派背后的真实成本。
