人要独立生活，学习有用的技艺。——凯德

https://github.com/steipete/CodexBar

CodexBar：把 AI 编码额度请进 macOS 菜单栏

有些工具擅长生成代码，有些工具擅长改代码，而 CodexBar 做的事情很直接：它把你每天最容易忽略、却又最影响节奏的那件事，搬到了眼前。

它是一个面向 macOS 14+ 的轻量级菜单栏应用，专门用来显示 AI 编码服务的使用额度，并告诉你每个额度窗口会在什么时候重置。项目 description 里用一句很朴素的话概括了它的初衷：**显示 OpenAI Codex 和 Claude Code 的使用统计，而且不必反复登录。**而 README 则把这个思路进一步铺开：它希望把“每一个 AI 编码限制”都变成菜单栏里一眼可见的信息。

项目地址：https://github.com/steipete/CodexBar

这类工具为什么会让人一眼记住

很多人使用 AI 编码工具时，最容易遇到的不是“不会用”，而是“看不清”。
看不清自己还有多少额度，看不清这次会话什么时候重置，看不清某个平台是按周计算、按月计算，还是按某个会话窗口计算。于是每次准备开始一段稍重的任务时，心里总会打鼓：现在开工，会不会刚跑到一半就撞上限制？

CodexBar 试图解决的，正是这种反复猜测的疲惫感。

README 里对它的价值描述得很明确：

  • 围绕重置时间来安排工作
  • 观察不同提供方的会话、每周、每月窗口
  • 看到额度、花费和成本扫描信息
  • 观察服务状态
  • 尽量以隐私优先的方式复用已有登录来源，而不是保存密码

它不像一个喧闹的大型平台，更像菜单栏里一个安静但非常清醒的小助手。你不必每次打开多个后台页面检查状态，也不必反复切换不同工具确认配额。它把这些零碎、烦人、又极其现实的信息收拢起来，变成一块随时可见的仪表盘。

它到底是什么样子

从 README 的介绍来看，CodexBar 是一个 macOS 菜单栏应用。它会在菜单栏中展示提供方相关的使用信息，点开后则可以看到更完整的 provider 视图、使用条、重置倒计时等内容。

它最核心的表达方式有几种：

  • 可见的使用额度
  • 每个窗口的重置时间
  • 不同提供方的状态
  • 菜单栏图标中的小型用量指示

README 甚至专门提到，菜单栏图标本身就是一个很小的使用量计。不同提供方下，条形含义会有所不同；如果出现错误或数据过期，图标也可能变暗，或者显示事件指示。

这意味着 CodexBar 的设计并不是把一堆信息粗暴塞进界面里，而是努力把“状态感”浓缩进一个你每天都会看见的位置。菜单栏本来就是最适合“轻量提醒”的地方，而 CodexBar 正是顺着这个位置的天性在工作。

它关注的不只是一个服务，而是一整个使用现场

如果只看项目 description，你会以为它主要围绕 OpenAI Codex 和 Claude Code。
但 README 展示出来的野心要更完整：CodexBar 已经把支持范围扩展到了大量 provider。

文档中的 Providers 列表非常长，涵盖了诸多不同来源和接入方式的服务，包括但不限于：

  • Codex
  • OpenAI
  • Claude
  • Cursor
  • Gemini
  • Copilot
  • Grok
  • GroqCloud
  • ElevenLabs
  • Deepgram
  • OpenRouter
  • LiteLLM
  • AWS Bedrock
  • Vertex AI
  • Mistral
  • DeepSeek
  • Poe
  • Warp
  • Zed
  • Windsurf

以及 README 中列出的更多提供方。

这种“多提供方并列”的能力，让 CodexBar 的定位变得很清晰：它不是某一个模型或某一个平台的附属面板，而是一个横跨多个 AI 编码与相关服务的统一观察层。

当你同时使用多种工具时，这个统一视角就会变得很重要。不同平台有不同的认证方式、不同的计费形式、不同的重置窗口，而 CodexBar 尝试把这些分散的信息重新组织成一个更适合日常操作的界面。

它真正打动人的地方，是“把时间感也可视化了”

单纯显示“还剩多少”并不稀奇。
CodexBar 更有意思的一点，是它强调 reset countdowns，也就是重置倒计时。

这件事看起来像一个小功能，实际却非常影响真实体验。

因为对于很多带额度窗口的服务来说，“现在还剩多少”只是半个答案，另外半个答案是：“多久恢复？”
README 中反复提到按会话、每周、每月计算的窗口，以及对应的下一次重置时间。换句话说，CodexBar 不是只告诉你“余额”，它还在努力告诉你“节奏”。

这会改变使用方式。

你不再只是被动地看到一条快见底的进度条，而是能更有把握地决定：
现在适不适合开启一个长任务？
要不要等下一个窗口重置后再继续？
哪些 provider 现在更从容，哪些已经接近边界？

这类信息一旦足够直观，工具就不只是“显示数据”，而是在帮助你做决策。

README 里提到的核心特性，很有一套自己的组合逻辑

CodexBar 的 Features 一节信息量很大，能看出这个项目并不是只做“展示”这么简单。

1. 多提供方菜单栏管理

它支持在菜单栏中管理多个 provider，并且可以通过 Settings → Providers 进行逐项开关。

这意味着它不是固定绑定单一来源，而是允许用户按自己的工具组合来搭建实际可用的观察面板。

2. 每个提供方都有自己的用量与重置表达

README 明确写到：

  • provider-specific usage meters
  • reset countdowns

这说明 CodexBar 并不是试图用一种完全统一的模型去强行解释所有服务，而是承认不同 provider 有不同规则，再把这些规则转换成各自合适的显示方式。

3. 花费、额度与图表能力

项目提到了多种与使用成本相关的信息：

  • credit balances
  • spend dashboards
  • billing summaries
  • local cost scans
  • inline spend and usage charts

尤其在 Features 里，README 明确写到它支持面向 API-backed providers 的内联花费与用量图表，并且还支持针对 Codex 与 Claude 的可配置成本使用扫描。

这让它的角色进一步从“额度提示器”延伸到了“用量观察器”。

4. 服务状态轮询

CodexBar 支持 provider status polling，并在菜单中显示 incident badges，还会在图标上加覆盖指示。

这类设计很务实。因为很多时候你以为是自己配额异常、登录异常、接口异常，最后发现其实只是服务端状态波动。如果状态信息能在同一处被看到，排查会更顺手。

5. 合并图标模式

README 提到 Merge Icons mode，可以把多个 provider 合并成一个状态项和切换器。

这很像是给“工具很多，但菜单栏空间有限”的现实妥协。你既可以保留多 provider 视角，又不用把菜单栏挤成一条信息长廊。

6. 更细的显示控制

它支持：

  • provider icons
  • labels
  • bars
  • reset-time style
  • highest-usage auto-selection

这部分很能体现菜单栏工具的气质。真正好用的菜单栏应用，通常不是功能堆得多，而是允许用户把显示密度调到适合自己的状态。

7. 刷新频率可调

README 给出了几种刷新节奏：

  • manual
  • 1m
  • 2m
  • 5m
  • 15m

这说明 CodexBar 在“即时感”和“克制感”之间做了平衡。它不是默认一切都疯狂刷新，而是让用户决定信息更新的节奏。

8. 附带 CLI

项目带有一个名为 codexbar 的 CLI，README 说明它可以用于脚本和 CI，也提到了 codexbar cost --provider codex、claude 或 both 这样的使用方式。

这很关键。因为一旦 CLI 存在，CodexBar 就不只是一个 GUI 菜单栏应用，它同时也具备进入自动化链路的可能。对于喜欢脚本化工作流的人来说，这样的设计会很自然。

9. WidgetKit 小组件

README 提到项目支持 WidgetKit widgets for supported providers。

这意味着它并不把展示范围死锁在菜单栏里，而是进一步延伸到了系统级组件位置，让用户可以在不同的 macOS 界面层次里接触这些信息。

10. 本地化能力

README 写到它有：

  • localized app and website
  • shared 21-language catalog
  • automatic website detection
  • persistent pickers
  • RTL support

这部分很容易被忽略，但其实很说明项目成熟度。一个菜单栏工具如果愿意认真处理多语言、持久化选择和 RTL 支持，说明它并不只是作者自用的小脚本，而是在努力变成一个真正可被不同用户稳定使用的产品。

11. 通知与一点轻松感

在 Features 的最后，README 还提到：

  • optional session quota notifications
  • weekly-reset confetti

这行字很有意思。前者是严肃的可用性功能，后者则带着一点轻微的庆祝意味。一个跟额度、限制、重置打交道的工具，愿意在“周重置”这种时刻撒一点彩带，说明它不想让自己只是冷冰冰的统计器。

它对“隐私优先”的理解，很具体

很多产品都会说自己重视隐私，但 README 里这部分写得相对落地。

CodexBar 强调：

  • 复用已有 provider 会话
  • 来源可能包括 OAuth、device flow、API keys、browser cookies、local files、provider apps
  • 不存储密码
  • 默认优先本地解析
  • 浏览器 cookies 是 opt-in

这种描述很重要，因为它没有把“隐私优先”写成一个空口号，而是给出了操作层面的路径：尽量利用已有认证状态，而不是要求用户重新把敏感信息交给它统一保管。

README 的 Privacy note 还专门回应了一个很多人会自然担心的问题：它会不会扫描整块磁盘。文档明确表示，它不会爬整个文件系统，而是读取一小组已知位置，例如浏览器 cookies、本地存储、provider 配置文件、JSONL 日志等，而且是在对应功能启用时才会去使用这些来源。

这种边界感，会让人更容易放心。

权限说明写得非常“实用主义”

如果一个 macOS 工具要碰到浏览器 cookies、Keychain、CLI、本地文件这些东西，权限问题几乎绕不开。CodexBar 在 README 里没有回避这件事，反而把“为什么需要这些权限”讲得相当细。

它提到了几类典型权限：

Full Disk Access

这是可选的，主要与读取 Safari cookies 或 local storage 有关。README 也给出了替代思路：如果不授予，就使用其他支持的浏览器、手动 cookies、API keys、OAuth 等方式。

Keychain access

README 对这部分解释得尤其详细，包括：

  • Chromium cookie 导入为何需要浏览器 Safe Storage key
  • Claude OAuth bootstrap 在某些情况下为何会读取 Claude CLI 的 Keychain 项
  • CodexBar 可能如何使用 Keychain 来处理 cookie 解密、缓存的 cookie header、OAuth/device-flow 凭据
  • 如何在 Keychain Access 里为 CodexBar 添加访问控制
  • 如何对浏览器的 Safe Storage key 做同样设置
  • 如何在最后手段下完全停止 Keychain 读取
  • 卸载后如果进程仍在运行，为什么还可能继续弹 Keychain 提示

这种写法非常像一个经历过真实用户反馈之后整理出来的答案集合。它不是只说“我们需要权限”，而是尽量把你会遇到的问题、你会烦躁的弹窗、以及你可能想关闭的路径，都提前写在前面。

Files & Folders prompts

README 还提到，CodexBar 会为某些 provider 启动 CLI 和本地 probe；如果这些 helper 读取项目目录或外部卷，macOS 可能会弹出文件夹或卷访问权限提示。

不会在后台索取的权限

README 也明确列出不会在后台请求的东西，比如 Screen Recording、Accessibility；如果有用户主动触发的 helper 行为，可能会让 macOS 申请 Automation 权限去打开 Terminal。

这类说明非常有助于建立信任：不是只告诉你“要什么”，也告诉你“不要什么”。

安装路径不止一种，思路也很清楚

CodexBar 的安装方式在 README 里给得很完整。

图形界面安装

可以通过 GitHub Releases 获取。

Homebrew 安装

1
brew install --cask codexbar

CLI Tarballs 与 Linux CLI 方式

README 还列出了 CLI tarballs，以及 Linux 下可用的 Homebrew formula 和 Arch Linux AUR 包。

例如：

1
brew install steipete/tap/codexbar
1
yay -S codexbar-cli

从这里可以看出，虽然 CodexBar 本体是一个 macOS 14+ 菜单栏应用，但作者也把 CLI 能力打包成了可在 macOS/Linux 使用的形式。这种拆分很聪明：GUI 做系统交互，CLI 负责脚本和集成，两者互相补位。

第一次运行时，它希望你怎么开始

README 的 First run 写得很直接，没有故作复杂：

  • 打开 Settings → Providers，启用你要用的 provider
  • 安装或登录你依赖的 provider 来源
  • 来源可能是 CLI、浏览器会话、OAuth/device flow、API key、本地应用文件等
  • 对 Codex provider，还可以可选配置 OpenAI cookies，以获得 dashboard extras

这种开始方式很符合它整体的产品逻辑：
先选你真的在用的 provider，再把已有登录或数据来源连接起来，然后菜单栏就开始为你工作。

它没有要求你重新建立一套身份系统，也没有要求你接受某种唯一标准接入方式。它更像是在说：你原本怎么使用这些服务，就尽量沿着那个路径接过来。

CLI 配置部分，能看出它并不排斥自动化用户

README 给出了通过 CLI 管理 provider 开关与 API key 的方式。

例如：

1
2
3
codexbar config providers
codexbar config enable --provider grok
codexbar config disable --provider cursor

对于 API-key provider，也可以直接从命令行写入：

1
printf '%s' "$ELEVENLABS_API_KEY" | codexbar config set-api-key --provider elevenlabs --stdin

README 还说明：

  • provider toggles 与 API keys 存在解析后的 CodexBar 配置文件里
  • 新安装默认使用 ~/.config/codexbar/config.json
  • 旧安装仍兼容 ~/.codexbar/config.json
  • set-api-key 会修剪管道传入的值
  • 会以限制性配置文件权限存储
  • 默认会启用对应 provider
  • 可以通过 --no-enable 只保存 key

这一段信息虽然是配置细节，但非常能说明 CodexBar 的实用取向：它没有把一切都关进图形界面，而是认真考虑了脚本化、自动化和已有安装路径兼容。

开发者如果想从源码构建，也有现成路径

README 也照顾到了希望从源码运行项目的人。

它给出的条件很明确：

  • macOS 14+
  • Swift 6.2+

构建方式如下：

1
2
./Scripts/package_app.sh        # builds CodexBar.app in-place with ad-hoc signing
open CodexBar.app

开发循环则包括：

1
2
3
4
./Scripts/compile_and_run.sh
./Scripts/compile_and_run.sh --test  # also run the sharded test suite before packaging/relaunching
make check                           # SwiftFormat + SwiftLint
make docs-list                       # list docs with frontmatter summaries

CLI 安装方式也给出了示例：

1
2
# after installing CodexBar.app in /Applications
./bin/install-codexbar-cli.sh

从这些命令可以看出，这个项目的开发体验至少在 README 层面已经整理得相当顺畅：打包、运行、测试、格式检查、文档列表，都有对应入口。

这不是一个“只给自己用”的仓库，它有很完整的文档意识

CodexBar 的 README 后半段列出了一整套文档入口，包括：

  • Providers overview
  • Provider authoring
  • UI & icon notes
  • CLI reference
  • Configuration
  • Keychain prompts
  • CLI configuration
  • Widgets
  • Architecture
  • Refresh loop
  • Status polling
  • Sparkle updates
  • Packaging
  • Development
  • Release checklist
  • Changelog

这种文档结构本身就很说明问题。
一个项目如果只满足“作者自己能用”，通常不会把 provider、配置、刷新循环、状态轮询、打包、发布流程都分别写清楚。CodexBar 看起来更像是在主动构建一个可维护、可扩展、可协作的系统。

尤其 README 里还写到一句：Open to new providers: provider authoring guide.

这句话背后的意思很简单：CodexBar 并不把 provider 支持当成封闭列表，它已经为“继续长大”预留了位置。

它甚至已经有了不少外部延展形态

README 末尾列出了一些外围生态入口，虽然文章不能把它们夸成某种宏大生态，但至少能看出一个事实：CodexBar 的能力已经被不同桌面和状态栏环境接住了。

例如：

  • Windows 版本方向的项目
  • Linux desktop integration
  • Waybar 模块
  • GNOME Shell 扩展
  • Quickshell 插件
  • KDE Plasma 小组件
  • 面向 SketchyBar、tmux、Zellij 的状态条与终端集成方案

这些内容至少说明，CodexBar 的“显示使用信息”这件事，不只适合停留在一个独立的 macOS 菜单栏应用里。它也具备被其他桌面外壳或状态系统消费的可能。

从语言构成和仓库信息看，它有很鲜明的技术气质

根据仓库信息，这个项目的主要语言是 Swift。
这和它作为 macOS 菜单栏应用的定位非常一致。README 中也明确要求 Swift 6.2+，并且开发方式围绕 Xcode 与脚本构建展开。

仓库 metadata 还显示：

  • 仓库名为 steipete/CodexBar
  • 默认分支是 main
  • License 为 MIT

这让项目形象更加明确：一个公开仓库、面向 macOS、以 Swift 为核心、同时又提供 CLI 路径的工具型项目。

如果用一句更贴近使用者的话来形容它

CodexBar 像是把那些原本散落在网页、CLI、控制台、账单页和本地配置里的碎片，轻轻拢到菜单栏的一小块空间里。
它不替你写代码，不替你思考架构，也不替你决定该用哪一个 provider。它做的是更朴素、却也更容易每天受益的事情：让你知道自己现在处在什么位置。

还有多少额度，什么时候重置，某个服务现在稳不稳定，哪些地方能看到花费，哪些地方可以复用已有会话，哪些权限是可选的，哪些配置可以脚本化——这些问题，平时看起来零碎，一旦集中起来，就会组成一种非常具体的掌控感。

而 CodexBar 最有意思的地方，也许正是在这里：
它不是在制造新的复杂度，而是在替你收拾复杂度。

结语

CodexBar 是一个很有目标感的项目。它把“AI 编码服务的额度与状态可视化”这件事做成了菜单栏体验，并围绕重置时间、花费、状态、认证来源、CLI、Widget、配置和权限说明，搭建出一套相当完整的使用路径。

如果说很多开发工具是在帮你“更快地产出”，那 CodexBar 更像是在帮你“更清楚地行动”。它不抢主角位置，却非常知道自己该站在哪：就在菜单栏里，安静地提醒你，下一次重置还有多久，而你的节奏，最好别再靠猜。