1. cc-switch 用量查询为什么总在小米 mimo 上翻车cc-switch 是一款把多家大模型 API 用量聚合到一个面板里的监控工具能做什么简单说它让你不用来回登录各家控制台就能看到余额、套餐积分、消耗进度。适合谁同时用好几家模型、又懒得天天手动对账的开发者。但小米 mimo 这块比较特殊cc-switch 原生并不支持它的用量查询所以很多人第一次配的时候会直接撞上本地代理失败或者 401 报错。我自己也踩过这个坑。当时在 cc-switch 里加了个自定义数据源endpoint 直接填了小米 mimo 控制台的地址结果面板一直转圈日志里刷的是local proxy failed偶尔换成 401。折腾半天才明白问题不在 cc-switch 本身而在于 endpoint 的指向和鉴权字段的写法。小米 mimo 的用量接口需要带上浏览器里那套 Cookie 认证信息而 cc-switch 的本地代理在转发时如果 endpoint 写成了需要额外跳转的地址或者鉴权头没带全就会在代理层被拦下来。这篇就聚焦一件事把 cc-switch 里小米 mimo 的 endpoint 改到能正常查询用量的状态顺带把 401 和本地代理失败的排查路径讲清楚。核心思路是用量查询请求最终要落到小米 mimo 平台提供的两个接口上——按量计费的余额接口和 TokenPlan 的套餐用量接口。cc-switch 的自定义数据源功能本质上就是让你写一段请求配置加一个结果提取函数把接口返回的 JSON 映射成面板能显示的指标。这里有个关键认知cc-switch 的“本地代理”并不是让你去搭什么网络通道而是它内部在发起请求时走的一层转发逻辑。当 endpoint 指向的域名和鉴权信息不匹配或者请求头里缺少必要的 Cookie 字段这层转发就会失败。401 则更直接就是鉴权没通过服务端认为你没权限读这个数据。所以排查顺序应该是先确认 endpoint 是不是小米 mimo 的官方接口地址再确认 Cookie 里的几个 token 字段有没有填全、有没有过期。小米 mimo 平台提供两种计费模式按量计费和 TokenPlan 套餐制。按量计费看的是余额类指标比如总余额、现金余额、赠送余额、冻结金额、透支额度TokenPlan 看的是套餐积分和补偿积分的已用、总量、剩余通常还会用百分比展示消耗进度。这两种模式对应两个不同的接口配置时不能混用。很多人 401 的原因就是把按量计费的 Cookie 拿去请求 TokenPlan 接口或者反过来字段对不上自然过不了鉴权。另外要提醒一句Cookie 里的 serviceToken、userId 这些属于个人敏感信息别往公开仓库或者群里发。Cookie 有效期一般 24 小时左右如果昨天还能查、今天突然 401大概率就是过期了重新从浏览器抓一次就行。这个机制决定了 cc-switch 里的用量查询不是一劳永逸的得有个重新填 Cookie 的心理准备。理解了这些后面的配置就有方向了endpoint 要精确指向小米 mimo 的接口路径鉴权字段要完整复制浏览器请求里的 Cookie提取函数要按接口返回结构来写。下面先把 TaoToken 这边的接入前置说清楚因为如果你同时用 TaoToken 的 APIcc-switch 里也可以把它作为一个数据源统一管理思路是一样的。2. TaoToken 接入前置Base URL、Key 与 Model ID 三件套在动 cc-switch 的配置之前先把 TaoToken 这边的接入信息准备好。TaoToken 的官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。如果你打算在 cc-switch 里同时监控 TaoToken 的用量或者用 TaoToken 的模型来做 coding 类任务那 Base URL、API Key、Model ID 这三件套必须先拿到手。Base URL 就是请求的根地址TaoToken 这边统一用 https://taotoken.net/api 。注意这个地址后面不加 UTM 参数保持干净。API Key 需要你去控制台生成入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 进去之后找到 API Keys 页面新建一个 key 并复制保存。Model ID 则取决于你要调用的具体模型可以在模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 里查看当前可用的模型列表。为什么要在讲小米 mimo 的文章里提 TaoToken因为实际工作流里很多人是多家 API 混用的。cc-switch 的价值就在于把这些分散的用量集中到一个面板。你完全可以在 cc-switch 里配一个小米 mimo 的数据源再配一个 TaoToken 的数据源两边余额和消耗一目了然。而且 TaoToken 的接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的请求示例配 cc-switch 自定义数据源时可以对照着写。如果你是要做长期编码或者 Agent 类任务可以考虑 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。这类套餐制的东西用量监控尤其重要因为你要盯着积分消耗进度别跑到一半额度没了。cc-switch 的 TokenPlan 类数据源就是干这个的小米 mimo 的 TokenPlan 接口和 TaoToken 的套餐用量接口在配置思路上是一致的都是请求一个 usage 接口然后从返回里提取 used、total、remaining 这些字段。这里先把三件套的对照关系列一下方便你配 cc-switch 时直接抄配置项值说明Base URLhttps://taotoken.net/api请求根地址不带 UTMAPI Key控制台生成在 API Keys 页面新建Model ID模型列表里查按需选择具体模型拿到这三样之后cc-switch 里无论是配小米 mimo 还是配 TaoToken套路都是request 里写 url、method、headersextractor 里写解析逻辑。区别只在于 url 指向哪个平台的接口headers 里带的是哪套鉴权字段。小米 mimo 用 CookieTaoToken 用 Authorization Bearer这个后面配置章节会具体展开。还有一点cc-switch 的配置文件通常是 JSON 或 TOML 格式具体路径取决于你的安装方式。Windows 下一般在用户目录的 AppData 里macOS 下在 ~/Library/Application Support 下。改之前先备份一份改错了能回滚。这个习惯在排查 401 的时候特别有用因为你可以对比改前改后的差异快速定位是哪个字段写错了。3. 可复制配置cc-switch 里改 endpoint 与鉴权字段这一节直接给可复制的配置片段。cc-switch 的自定义数据源配置核心是两段request 定义请求怎么发extractor 定义返回怎么解析。下面按小米 mimo 的按量计费和 TokenPlan 两种模式分别给。先看按量计费的余额查询。endpoint 要指向 https://platform.xiaomimimo.com/api/v1/balance method 是 GETheaders 里最关键的是 Cookie。这个 Cookie 需要你从浏览器开发者工具里抓具体是打开小米 mimo 平台后按 F12切到 Network 面板找到名为 balanceAlertConfig 的请求在请求详情里复制完整的 cookie 值。配置片段如下{ request: { url: https://platform.xiaomimimo.com/api/v1/balance, method: GET, headers: { Cookie: serviceToken\你的serviceToken\; xiaomichatbot_ph\你的ph\; api-platform_serviceToken\你的api-platform_serviceToken\; userId你的userId; api-platform_slh\你的slh\; api-platform_ph\你的api-platform_ph\, Accept: application/json, User-Agent: cc-switch/1.0 } }, extractor: function (response) { const data response?.data || {}; const unit data.currency || CNY; const isValid response?.code 0; const balanceConfigs [{ key: balance, planName: 总余额 }, { key: cashBalance, planName: 现金余额 }, { key: giftBalance, planName: 赠送余额 }, { key: frozenBalance, planName: 冻结金额 }, { key: overdraftLimit, planName: 透支额度 }, { key: remainingOverdraftLimit, planName: 剩余透支额度 }]; return balanceConfigs.map(({ key, planName }) { const value Number(data[key] || 0); return { isValid, planName, remaining: value, unit }; }); } }注意 Cookie 里那几个字段serviceToken、xiaomichatbot_ph、api-platform_serviceToken、userId、api-platform_slh、api-platform_ph一个都不能少。少一个就可能在代理层被拦或者服务端返回 401。userId 是数字不用加引号其他几个是字符串要带引号。这个格式必须和浏览器里复制出来的一致别自己改。再看 TokenPlan 的套餐用量查询。endpoint 换成 https://platform.xiaomimimo.com/api/v1/tokenPlan/usage Cookie 还是同一套。extractor 里要做单位换算因为接口返回的数值是原始 token 数需要除以 1000000 再除以 multiplier 得到“百M”单位。配置如下{ request: { url: https://platform.xiaomimimo.com/api/v1/tokenPlan/usage, method: GET, headers: { Cookie: serviceToken\你的serviceToken\; xiaomichatbot_ph\你的ph\; api-platform_serviceToken\你的api-platform_serviceToken\; userId你的userId; api-platform_slh\你的slh\; api-platform_ph\你的api-platform_ph\, Accept: application/json, User-Agent: cc-switch/1.0 } }, extractor: function (response, multiplier 100) { const SCALE 1000000; const items response?.data?.usage?.items || []; const planConfigs [{ name: plan_total_token, planName: 套餐积分 }, { name: compensation_total_token, planName: 补偿积分 }]; const formatPercent (used, total, fallbackPercent 0) { const percent total 0 ? used / total : Number(fallbackPercent || 0); return ${(percent * 100).toFixed(2).replace(/\\.?0$/, )}%; }; const formatValue (value) { return (value / SCALE) / multiplier; }; return planConfigs.map(({ name, planName }) { const item items.find((i) i?.name name); if (!item) { return null; } const used Number(item?.used || 0); const total Number(item?.limit || 0); const remaining Math.max(total - used, 0); return { isValid: true, planName, used: formatValue(used), total: formatValue(total), remaining: formatValue(remaining), unit: 百M, extra: formatPercent(used, total, item?.percent) }; }).filter(Boolean); } }如果你用的是 TOML 格式的配置文件结构类似只是语法不同。关键是 request 和 extractor 这两块要对应上。改完之后保存重启 cc-switch 让配置生效。这里要强调一下cc-switch 的本地代理失败很多时候是因为 endpoint 写成了带重定向的地址或者域名拼错。小米 mimo 的接口域名是 platform.xiaomimimo.com路径是 /api/v1/balance 和 /api/v1/tokenPlan/usage别写成别的。另外 User-Agent 建议保留 cc-switch/1.0有些接口会对 UA 做校验。如果你同时在 cc-switch 里配 TaoToken 的数据源那 request 里的 headers 要换成 Authorization: Bearer 你的API Keyurl 换成 https://taotoken.net/api 下对应的用量接口。三件套里的 Base URL、Key、Model ID 在这里就派上用场了。Model ID 虽然不直接出现在用量查询里但如果你配的是模型调用类的数据源就需要它来指定请求哪个模型。配置改完只是第一步接下来得实际发一次请求验证确认返回的是正常计费数据而不是错误码。4. 验证请求确认返回正常计费数据配置写好后别急着看面板先用命令行手动发一次请求确认接口能通、返回结构对得上。这一步能帮你把 cc-switch 的问题和接口本身的问题分开。以按量计费的余额接口为例你可以用 curl 模拟 cc-switch 发出的请求。把 Cookie 替换成你自己的curl -X GET https://platform.xiaomimimo.com/api/v1/balance \ -H Cookie: serviceToken\你的serviceToken\; xiaomichatbot_ph\你的ph\; api-platform_serviceToken\你的api-platform_serviceToken\; userId你的userId; api-platform_slh\你的slh\; api-platform_ph\你的api-platform_ph\ \ -H Accept: application/json \ -H User-Agent: cc-switch/1.0正常返回应该是一个 JSON里面 code 为 0data 里包含 balance、cashBalance、giftBalance、frozenBalance、overdraftLimit、remainingOverdraftLimit 这些字段。如果 code 不是 0或者返回里带 error 字段那就是鉴权或参数有问题。如果 curl 直接报连接失败那可能是域名解析或者网络层的问题跟 cc-switch 无关。TokenPlan 接口同理curl -X GET https://platform.xiaomimimo.com/api/v1/tokenPlan/usage \ -H Cookie: serviceToken\你的serviceToken\; xiaomichatbot_ph\你的ph\; api-platform_serviceToken\你的api-platform_serviceToken\; userId你的userId; api-platform_slh\你的slh\; api-platform_ph\你的api-platform_ph\ \ -H Accept: application/json \ -H User-Agent: cc-switch/1.0返回里 data.usage.items 应该是一个数组每个 item 有 name、used、limit、percent 这些字段。name 为 plan_total_token 的是套餐积分compensation_total_token 的是补偿积分。如果 items 是空数组说明当前账号没有对应的套餐数据不是报错。curl 通了之后回到 cc-switch 里触发一次刷新。如果面板还是显示本地代理失败那就去看 cc-switch 的日志。日志里通常会写明是请求哪个 url 时失败的以及失败原因。常见的是 Cookie 里的引号被转义错了或者 JSON 配置里字符串没转义。cc-switch 的 extractor 是作为字符串存的里面的引号需要转义这个在复制配置时容易出错。验证成功的标志是面板上出现总余额、现金余额等指标数值和你在小米 mimo 控制台看到的一致TokenPlan 那边出现套餐积分和补偿积分的已用、总量、剩余百分比也对得上。如果数值是 0 或者显示异常先检查 extractor 里的字段名有没有写错比如 balance 写成了 balances。还有个小技巧cc-switch 一般有“测试连接”或者“预览数据”的按钮点一下能看到原始返回和解析后的结果。用这个功能可以快速定位是请求失败还是解析失败。请求失败看 request 配置解析失败看 extractor 逻辑。验证通过之后建议把这次成功的配置和 Cookie 记在一个安全的地方因为 Cookie 24 小时过期后你需要重新抓取并替换。如果不想频繁手动更新可以考虑用 TaoToken 这类提供稳定 API Key 的服务来做长期监控API Key 不像 Cookie 那样短期失效省心不少。5. 常见报错排查401、local proxy failed 与 reading choices这一节把几个高频报错拆开讲每个都给出对照的排查路径。401 报错是最常见的。cc-switch 里看到 401说明请求发出去了但服务端认为鉴权不通过。原因通常有三个Cookie 过期、Cookie 字段缺失、Cookie 格式错误。先确认 Cookie 是不是 24 小时内抓的过期了就重新抓。再检查 serviceToken、userId、api-platform_serviceToken 这几个关键字段有没有漏。格式上字符串字段的引号要保留userId 不加引号分号后面的空格也要和浏览器里一致。如果是从浏览器复制的建议直接整段粘贴别手动改。local proxy failed 是 cc-switch 本地代理层的报错通常发生在请求还没到服务端就被拦了。原因可能是 endpoint 域名写错、协议写错http 写成 https 或反过来、或者请求头里带了不被允许的字段。排查时先确认 url 是不是 https://platform.xiaomimimo.com/api/v1/balance 或 /api/v1/tokenPlan/usage一个字符都别差。再看 headers 里有没有多余的自定义头cc-switch 的代理对某些头比较敏感建议只保留 Cookie、Accept、User-Agent 这三个。reading choices 这个报错一般出现在解析阶段意思是 extractor 期望的返回结构里没有 choices 字段。这通常是因为你把模型调用类的 extractor 用在了用量查询接口上。用量查询接口返回的是 data.balance 或 data.usage.items不是 choices。检查一下 extractor 里的字段路径按量计费用 response.data.balanceTokenPlan 用 response.data.usage.items。如果接口返回结构变了也会导致这个报错这时候打印一下原始 response 看看实际结构。OAuth 相关的报错通常是因为某些接口需要 OAuth token 而不是 Cookie。小米 mimo 的用量接口目前用 Cookie 鉴权如果你看到 OAuth 报错可能是 endpoint 指到了别的接口上。确认 url 路径正确别把模型推理接口的地址填到用量查询里。还有一个容易忽略的点cc-switch 的配置文件里extractor 是字符串形式里面的函数体需要正确转义。如果转义错了cc-switch 加载配置时可能不报错但执行时抛异常表现就是面板一直加载或者显示空数据。排查方法是把 extractor 单独拿出来在浏览器控制台或者 Node 里跑一遍传入模拟的 response看能不能正常返回数组。如果你在 cc-switch 里同时配了 TaoToken 的数据源报错排查思路一样401 看 API Key 对不对local proxy failed 看 Base URL 是不是 https://taotoken.net/api reading choices 看 extractor 是不是用错了接口类型。TaoToken 的接入文档里有各接口的返回示例对照着写 extractor 能少走弯路。最后提醒改配置前备份改完重启验证用 curl 先跑通再看面板。这个顺序能帮你把问题范围缩到最小。6. 把用量查询稳定跑起来CTA 与长期维护配置调通只是开始长期稳定跑起来还需要一点维护习惯。Cookie 24 小时过期这个机制决定了小米 mimo 的用量查询没法完全自动化你得定期更新。如果只是偶尔看看余额手动更新可以接受但如果你要长期监控消耗、做成本控制建议把 TaoToken 这类用 API Key 鉴权的服务作为主力监控对象API Key 不会短期失效cc-switch 里的数据源可以一直跑。具体操作上TaoToken 的 API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 生成和管理接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。把 Base URL、Key、Model ID 三件套填进 cc-switch 的自定义数据源就能持续看到用量。如果你做的是编码类任务Coding Plan 的额度监控尤其重要入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 配好之后积分消耗进度一目了然。想快速验证模型返回是否正常可以用模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 发一条测试请求确认 Key 和 Model ID 都对。控制台入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 日常管理 Key 和查看账单都在这里。回到小米 mimo 这边如果你确实需要长期监控它的用量又不想天天抓 Cookie可以考虑写个小脚本定时抓取并更新 cc-switch 配置但这涉及自动化登录复杂度较高。更实际的做法是把小米 mimo 的用量查询当作按需查看需要的时候更新一次 Cookie把 TaoToken 的用量查询当作常驻监控两者在 cc-switch 面板里并存各取所需。最后说个实操细节cc-switch 的配置文件改完后建议用版本管理工具存一份脱敏后的模板把 Cookie 和 Key 用占位符代替。这样下次换机器或者重装直接套模板填新值就行不用从头写 extractor。这个习惯能省不少重复劳动。