CodexBar

为什么选择 CodexBar？

CodexBar 适合需要同时管理多个 AI 编程服务的开发者。例如，一个人可能同时拥有 Codex 订阅、Claude Code、Cursor 额度、Copilot 用量、OpenRouter 余额及多个 API 账号。各服务可能采用滚动周期、每周上限、月度额度、预付余额或支出预算。CodexBar 将这些信息统一呈现，无需反复打开多个计费和用量页面。

这一定位很重要。CodexBar 与 Cursor、Claude Code 或 Codex CLI 配合使用。开发者付费 AI 工具越多，它的价值越明显，尤其适合长时间编程受滚动额度周期影响，或多项订阅同时使用的情况。

核心工作流程

实际使用以数据来源为中心。不同服务商的数据可能来自 OAuth 会话、已安装 CLI、API 密钥、浏览器会话或特定本地文件。CodexBar 选择适合的获取方式，将响应转换为统一用量格式，再通过桌面界面和 CLI 展示同一状态。

这种设计有两点影响。其一，数据质量取决于服务商可用的数据来源，官方 OAuth 或公开 API 通常比浏览器会话集成更易维护。其二，同一服务的不同来源也可能提供不同信息：本地或 CLI 数据足以查看额度，可选网页来源则可能增加计费详情。

稳定配置应选择权限最少、又能提供所需信息的数据来源。支持时先用 OAuth 或现有服务商 CLI，确实需要额外仪表盘数据时再开放浏览器 Cookie 访问。API 密钥应限制权限并作为凭证管理。

适用场景

多订阅规划是最直接的用途。开始长时间智能体重构前，可查看哪个服务剩余额度最多，以及受限服务何时重置。CodexBar 不会自动在智能体间分派任务，但能更清楚地提供决策所需信息。

费用意识对同时使用订阅与按量 API 的用户很重要。订阅额度和 API 余额是不同资源，放在同一操作视图中，有助于避免因装有订阅产品，就误认为可调用的模型无需额外费用。

自动化与内部仪表盘更能发挥 CLI 的价值。JSON 输出可供 shell 脚本、状态栏、仪表盘或 CI 检查使用，即使不以图形界面为主，也能使用 CodexBar。

排查服务商访问问题也是用途之一。CodexBar 区分数据来源和过期状态，有助于判断数字缺失是认证过期、服务商故障还是本地集成问题，而非仅显示原因不明的空值。

同类工具对比

CodexBar 的主要特色是覆盖广。专注 Claude Code、Codex 或少量服务商的额度工具通常更易理解；CodexBar 则以更多配置项换取对广泛混合服务的支持。

这影响工具选择。只想在菜单栏看一个 Claude 或 Codex 百分比，专用小工具可能更简单；若在多个智能体、API 网关、模型服务商和预付余额间切换，统一视图与通用 CLI 更有价值。

OpenUsage、AI Usage、UsageBar、QuotaBar 及终端用量仪表盘是主要比较对象，都希望减少打开服务商后台的次数，让额度和支出更直观。可比较服务商覆盖、系统支持、认证方式、历史深度、数据可靠性及是否提供适合自动化的输出。

配置建议

不必启用所有可用服务商。只启用日常开发实际使用的服务，按重要性排序，并突出最有参考价值的限制，可减少后台请求，也让界面更易浏览。

macOS 中多个服务商同时启用、菜单栏空间有限时，合并图标很实用。主要通过程序读取数据的用户，可将 CLI 作为操作入口，将图形应用作为辅助。

更改服务商、凭证或配置文件后，应验证实际生效的配置，避免间接排查格式错误：

codexbar config validate --format json --pretty

排查异常时，可直接查看规范化配置，无需手动还原默认值：

codexbar config dump --pretty

CodexBar 支持许多服务商专属设置和认证策略，配置越复杂，这些命令越有用。

迁移建议

新版安装使用 ~/.config/codexbar/config.json，仍兼容旧版 ~/.codexbar/config.json。换电脑迁移时，两种文件都应视为敏感文件，因为可能包含 token、手动 Cookie 请求头、账号选择及其他认证设置。

项目迭代较快。服务商实现可在原生代码和捆绑插件间迁移，而不改变主要使用流程。因此，支持数量并不保证每项集成的深度和稳定性相同。更应确认实际需要的服务商与认证方式是否有文档且持续维护。

Linux 支持已从无界面 CLI 扩展到 Qt 桌面集成，但 macOS 仍是原生体验的主要参考。混合操作系统团队应先测试实际依赖的服务商，不要默认所有平台的界面和认证完全一致。