CodexBar MiniMax 用量接入指南：Coding Plan 令牌、浏览器会话与诊断排查全解析

CodexBar MiniMax 用量接入指南：Coding Plan 令牌、浏览器会话与诊断排查全解析

【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar

本文围绕 CodexBar 对 MiniMax 提供商的完整支持展开，覆盖 Coding Plan API 令牌、浏览器会话/ Cookie 自动导入、手动 Cookie 头三种数据接入方式，结合仓库源码说明区域切换、端点覆盖与安全策略、用量快照映射以及diagnose诊断命令的用法。读完本文，你将能够独立配置 MiniMax 用量统计、排查凭据失效与解析失败问题，并理解 CodexBar 底层如何解析 MiniMax 的 Coding Plan 配额与账单数据。

MiniMax 数据源总览

MiniMax 是 CodexBar 支持的非主提供商（defaultEnabled: false，需在菜单中手动开启），支持两种凭据形态：Coding Plan API 令牌与Web 会话。Web 会话模式下，CodexBar 使用浏览器/Session 状态，并在提供商支持的 Web 请求之间按需回退，确保配额数据尽量可用。

从源码看，CodexBar 通过MiniMaxAuthMode.resolve(apiToken:cookieHeader:)判定认证模式（见 MiniMaxAuthMode.swift）：

1. Coding Plan API 令牌

API 令牌可以在以下位置配置（按优先级从高到低）：

1. Preferences → Providers → MiniMax设置界面，持久化于~/.codexbar/config.json；
2. 环境变量MINIMAX_CODING_API_KEY；
3. 环境变量MINIMAX_API_KEY。

当两个环境变量同时存在时，MINIMAX_CODING_API_KEY优先。源码MiniMaxAPISettingsReader.apiToken(environment:)按["MINIMAX_CODING_API_KEY", "MINIMAX_API_KEY"]顺序读取（见 MiniMaxAPISettingsReader.swift）。这样设计的目的是保证标准sk-api-*密钥不会掩盖 Coding Plan 的sk-cp-*密钥——apiKeyKind(token:)通过前缀区分二者：sk-cp-判定为.codingPlan，sk-api-判定为.standard，其余为.unknown。

令牌类型直接影响取数策略。在MiniMaxProviderDescriptor.resolveStrategies（见 MiniMaxProviderDescriptor.swift）中：

• 标准sk-api-*密钥：仅使用MiniMaxCodingPlanFetchStrategy（Web 路径），因为这类密钥本身用于调用 API，CodexBar 会用它在 Coding Plan Web 接口上换取配额数据；
• 非标准密钥（含sk-cp-*）：依次尝试MiniMaxAPIFetchStrategy与MiniMaxCodingPlanFetchStrategy，先走直连 API，失败再回退到 Web 路径；
• 仅配置 Cookie：只使用MiniMaxCodingPlanFetchStrategy。

另外，当 API 令牌凭据被拒绝（invalidCredentials）或全局端点返回 404 时，Auto 模式会自动回退到 Web/Cookie 路径——这正是MiniMaxAPIFetchStrategy.shouldFallback(on:)中针对invalidCredentials与HTTP 404返回true的逻辑。

2. 缓存/导入的浏览器会话（自动 Web 路径）

Web 路径复用 CodexBar 标准的 Cookie 缓存（CookieHeaderCache）与浏览器导入流程。在MiniMaxCodingPlanFetchStrategy.isAvailable中，优先检查：

• 设置/环境中的手动 Cookie 覆盖；
• CookieHeaderCache.load(provider: .minimax)中的缓存会话；
• 浏览器 Cookie 导入（仅 macOS 且为用户主动触发的场景，allowsBrowserCookieImport要求context.runtime == .app && ProviderInteractionContext.current == .userInitiated）。

抓取流程会先尝试缓存会话；若凭据失效（invalidCredentials或解析失败），会清除缓存并继续尝试各浏览器导入的会话，直到命中有效会话，再把成功的 Cookie 写回缓存。

3. 浏览器 Cookie 导入（自动）

导入依赖提供商元数据中的浏览器扫描顺序与MiniMax 域名过滤器。当 Cookie 会话可用时，Chromium 系浏览器的存储（Session Storage / IndexedDB）还能补充access token上下文：MiniMaxLocalStorageImporter会导入访问令牌与groupID，并按来源标签与 Cookie 会话对齐。抓取时会依次尝试「Session Storage/IndexedDB 令牌 + HERTZ-SESSION bearer + 无令牌」多种组合，直到某组凭据通过（见MiniMaxCodingPlanFetchStrategy.attemptFetch，MiniMaxProviderDescriptor.swift）。

4. 手动 Session Cookie 头（可选 Web 路径覆盖）

• 在Preferences → Providers → MiniMax（Cookie source → Manual）中配置，持久化于~/.codexbar/config.json；
• 接受原始Cookie:头或完整的 "Copy as cURL" 字符串；
• 无界面（低层）运行时可通过MINIMAX_COOKIE或MINIMAX_COOKIE_HEADER环境变量读取。

MiniMaxCookieHeader.override(from:)（见 MiniMaxCookieHeader.swift）会从输入中智能解析出三部分：

请求端点与区域切换

Web 会话可访问全球主机或中国内地主机，两个区域由 MiniMaxAPIRegion.swift 统一定义：

不同区域映射出各自的核心端点：

• Coding Plan 页面：/user-center/payment/coding-plan?cycle_type=3（同时是 dashboard 地址）；
• Coding Plan remains：/v1/api/openplatform/coding_plan/remains（Web 会话路径）；
• Token Plan remains：/v1/token_plan/remains（API 令牌直连路径，命中 Token Plan/Token Plan Plus 等套餐）；
• 账单历史：/account/amount，分页参数page/limit/aggregate=false。

在Preferences → Providers的区域选择器中切换主机；也可用环境变量覆盖（见 MiniMaxSettingsReader.swift）：

安全策略：端点覆盖只有在满足以下条件时才被接受——使用https://、省略 userinfo、不包含编码的主机分隔符（如%2F）。自定义 HTTPS 代理/测试域名出于兼容性仍可使用，但http://端点一律被拒绝，避免 Cookie 与鉴权头明文传输。

严格提供商主机模式：设置MINIMAX_REQUIRE_PROVIDER_ENDPOINT_OVERRIDES=true（也接受1/true/yes/on）后，ProviderEndpointOverrideValidator的策略从.allowAnyHTTPSHost切换为.providerOwnedOnly，此时仅接受 MiniMax 自有域名（minimax.io或minimaxi.com后缀）下的主机，自定义代理/测试域名将被拒绝。若存在被拒绝的覆盖项，抓取会在入口处抛出ProviderEndpointOverrideError.minimax，保证凭据绝不被发送到非可信主机。

传输失败与重试行为

传输层失败会保留其 URL 错误码与 MiniMax 诊断描述：MiniMaxUsageFetcher.normalizedTransportError保持NSURLErrorDomain域与错误码不变，仅把描述替换为MiniMaxUsageError.networkError的可读文案。这意味着离线、DNS、连接失败等场景能保留既有用量缓存，并正常走 CodexBar 的启动重试策略，且不受系统语言影响。端点回退、被拒凭据处理与可选的账单信息增强（billing enrichment）均保持既有行为。

错误类型在 MiniMaxUsageError.swift 中统一建模：

Web 路径的MiniMaxCodingPlanFetchStrategy.shouldTryNextBrowser会在invalidCredentials与parseFailed时尝试下一个浏览器来源；API 路径则依据shouldTryNextEndpoint依次尝试 token-plan 端点与旧版 coding-plan 端点。API 令牌直连还内建了区域兜底：若默认全局主机拒绝令牌（invalidCredentials），会改用中国内地主机重试一次，避免老配置在升级后回归（见MiniMaxUsageFetcher.fetchUsage(apiToken:region:)，MiniMaxUsageFetcher.swift）。

手动抓取 Cookie 的步骤（可选覆盖）

只有当自动导入失败时才需要手动抓取：

1. 打开 MiniMaxCoding Plan 页面并登录；
2. 打开浏览器DevTools → Network；
3. 筛选出请求/v1/api/openplatform/coding_plan/remains；
4. 复制该请求的Cookie请求头（或使用 “Copy as cURL” 复制整行）；
5. 粘贴到Preferences → Providers → MiniMax的 Manual Cookie 来源中。

粘贴的内容既可以是纯Cookie:头，也可以是完整的 cURL 命令——解析器会自行提取 Cookie、Bearer 令牌与 Group ID。

快照映射与用量展示

抓取到数据后，CodexBar 将Coding Plan 响应字段或页面文本映射为统一用量快照：

• 主用量（primary usage）：可用配额、已用/剩余额度；
• 重置时间（resetsAt）：由当前区间的end_time与remains_time推算；
• 套餐/层级（plan/tier）：由plan_name、current_subscribe_title、combo_title等字段解析。

MiniMaxUsageParser.parseCodingPlanRemains会把model_remains数组转换为多服务配额列表（MiniMaxServiceUsage），每个模型各渲染「当前区间」与「周窗口」（仅当周配额真实存在时）两条记录，并兼容percent为数字或字符串两种 JSON 形态。响应若为 HTML，则优先解析__NEXT_DATA__内嵌数据，否则回退到页面文本正则解析；同时通过looksSignedOut检测页面是否包含sign in/log in/登录/登入等文案，以识别登出状态。

Web 会话账单历史（可用时）会映射进共享的内联用量仪表盘：

• 30 天 Token 趋势（30-day token trend）；
• 顶级模型与顶级方法拆分（top model / top method）；
• 近期账单历史合计的汇总行。

账单历史通过/account/amount分页抓取（每页limit=100），按 30 天窗口聚合。若账单历史端点不可用，但正常 Coding Plan 配额数据存在，CodexBar 仍展示配额卡片，仅省略图表，而不会把整个提供商判定为失败——这正是attachingBillingIfAvailable对失败静默降级的设计。

CLI 诊断命令

通用diagnose命令会对指定提供商执行一次真实诊断调用，并输出安全脱敏的 JSON 导出，用于问题上报与验证。MiniMax 会在输出中附加提供商专属的details块，包含安全的用量元数据。

用法

codexbar diagnose --provider minimax --format json --pretty

输出内容

• 结构化的诊断 JSON：提供商、来源/来源模式、认证摘要、用量摘要、抓取尝试次数与错误分类；
• 各服务配额百分比：已用值、限额、剩余值、重置元数据与不限量状态——与菜单中展示的非敏感值一致，可用于诊断「加量配额分母」（boosted quota denominators）异常；
• 所有敏感字段（API 令牌、Cookie、邮箱、鉴权头）均经LogRedactor脱敏；
• 错误映射为安全分类（network、auth、api、parse），并附带用户友好的描述；
• 不包含任何原始 API 响应、原始错误消息、令牌、Cookie、邮箱、账户 ID、组织 ID 或账单历史。

输出中排除的内容

• 原始 API 令牌（sk-cp-*、sk-api-*）与鉴权头；
• Cookie 头值；
• 邮箱地址；
• 账户 ID、组织 ID；
• 原始错误消息（替换为基于安全分类的描述）；
• 原始 HTTP 响应或请求体；
• 账单历史细节。

退出码

关键文件索引

• MiniMaxUsageFetcher.swift：核心抓取逻辑，含 Web HTML、remains API、token-plan API、账单历史分页与区域兜底；
• MiniMaxProviderDescriptor.swift：提供商描述、取数策略（API/Web）解析、Cookie 会话编排与品牌/展示配置；
• MiniMaxProviderImplementation.swift：App 层实现，对接设置存储与菜单展示；
• MiniMaxAPIRegion.swift：区域与端点定义；
• MiniMaxAPISettingsReader.swift：API 令牌读取与sk-cp-/sk-api-类型判定；
• MiniMaxSettingsReader.swift：Cookie/端点覆盖环境变量与安全校验；
• MiniMaxCookieHeader.swift：Cookie 头、cURL 与 Group ID 解析；
• MiniMaxAuthMode.swift：认证模式判定；
• MiniMaxUsageError.swift：错误类型建模。

小结

MiniMax 提供商的接入核心在于**「API 令牌优先、Web 会话兜底」**的取数策略：标准sk-api-*密钥走 Coding Plan Web 路径，sk-cp-*等其他令牌先直连 token-plan API 再回退，而 Cookie 会话则依次尝试缓存、浏览器导入与手动覆盖。区域切换、端点安全校验与严格主机模式共同保证了凭据只发送到可信 HTTPS 主机；即使账单历史不可用，配额卡片也依然可用。遇到问题时，codexbar diagnose --provider minimax --format json --pretty能给出经过脱敏、可直接用于上报的完整诊断快照。

【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar