BrimDeck：给 Windows 11 装一个"灵动岛"，把 AI 额度、音乐和系统监控全收进去

如果你同时在用 Claude Code、Codex 和 Cursor，一定经历过这样的场景：写完一段代码，想知道 Claude 的 5 小时窗口还剩多少，于是切到终端敲一条命令；想知道今天烧了多少 token，再打开另一个网页；想看 GPU 到底跑到多少度，回到任务管理器。每查一次，注意力就被拽走一次。

BrimDeck 想解决的正是这个"注意力碎片化"问题。它把 Windows 11 顶部那个本来只用来放摄像头的凹槽区域，改造成了一个可以呼出面板的"灵动岛"（Dynamic Island），折叠时是一条细窄的胶囊，鼠标移上去就展开成完整仪表盘，里面同时装着 AI 工具额度环、正在播放的歌曲封面与歌词、以及 CPU/GPU/内存/网络等系统读数。

它是怎么诞生的：一个 2026 年 9 月才建库的项目

BrimDeck 由 MoFeng2223 在 2026 年 9 月 3 日创建，截至目前累计约 315 个 Star、19 个 Fork，贡献者仅 4 人，主力是作者本人。项目虽然年轻，但已经是 Apache-2.0 协议下的完整商业级桌面软件：有 Inno Setup 安装包、有便携版、有自动更新、有托盘图标、有一整套主题系统，还有中英双语的 README。

有意思的是它的技术选型。项目没有用 Electron，也没有用 Avalonia 这类跨平台框架，而是老老实实用 C# + .NET 10 + WPF 写原生 Windows 应用。作者在 csproj 里写下了原因：这个面板绝大部分时间是"闲置"的，所以刻意关闭了并发 GC、把 TieredCompilation 关掉、开启 PublishReadyToRun，避免运行时在启动几分钟后重新编译热方法造成 CPU 突刺。这种抠细节的做法，在个人项目里并不常见。

用生活化的比喻理解它的四块功能

把 BrimDeck 想象成汽车仪表盘上的一排小圆表：

额度环是油表。每一圈代表一个 AI 工具——Claude 是左一，Codex 是左二，Antigravity、Cursor 依次排开。环被填满的百分比就是额度消耗比例，用到 70% 会亮起警告色，90% 则是危险色，凹槽处还会弹 5 秒提示。最多支持 7 个工具并排显示。

音乐模块是车机多媒体。封面、进度条、播放模式切换、同步歌词都在里面，可以直接控制播放。多播放器同时运行时可以切换或置顶某一个——支持的是走 Windows 媒体会话（Global System Media Controls）的那一类播放器，网易云、QQ 音乐等部分客户端有额外适配。

系统监控是水温表和油量表。CPU 各核心占用、GPU、内存、网络上下行速率、各物理硬盘分区占用、最耗资源的进程排行，还能读 CPU/GPU/固态硬盘温度与整机功耗瓦数。温度读取不需要管理员权限和额外驱动，读不到的传感器会被直接略过而不是编造数值——这个"宁可空着也不瞎填"的处理方式，和它在 AI 额度上的做法一脉相承。

主题系统是换内饰。内置暗黑、亮色、One Dark Pro、GitHub Dark/Dracula/Night Owl、赛博朋克：雾雨观测者等多套，可自定义背景、前景、强调色，也能按主题指南文件手工导入。

硬核之处：它是怎么读到各家私有用量的

这才是 BrimDeck 真正有技术含量的部分。Claude、Codex、Antigravity 这些工具都不提供统一的配额查询接口，开发者只能各自摸索。

从源码可以看到三条路子：

一、读本地缓存。 代码里直接开了 SQLite 读 Antigravity 的会话库（~/.gemini/antigravity/conversations），字段编号是从 agy.exe 内嵌的 protobuf 描述符里扒出来的——steps.metadata 的第 1 个字段是 created_at、第 9 个是 model_usage，gen_metadata.data 里第 4 个是 usage、第 19 个是可读的模型名。Claude 桌面版的 5 小时与周额度来自本地记录，但逐模型额度（Fable 之类）和重置时间只有账户 API 才报，所以两者结合。

二、读日志。 Codex CLI 的会话记录、Kimi Code 的会话文件、OpenCode 的本地数据，都是直接解析本地 JSON/日志文件。

三、调账户 API。 用户自己填 API Key，程序按 provider 轮询余额与限额。

其中 ClaudeQuotaCache.cs 的设计相当讲究：它把最近一次读到的额度缓存到磁盘，但只存额度和套餐，绝不存 token；账户 ID 只以 SHA-256 单向哈希形式落盘，用于"换号后不串号"的校验；缓存有效期 7 天，但窗口已重置的额度会被剔除。作者在注释里写明：读不到数据时"永远不编造数字"。这一点在展示型工具里很关键——一个显示 91% 的环，如果底层是猜的，那就是有害的。

顺带一提，作者还给 DeepSeek、Kimi、OpenCode、OpenRouter、NewApi、Sub2Api、Grok Bot、ZCode 等十余个来源做了适配，"最多同时 7 个工具并排"是 UI 层的限制，底层 provider 远不止七个。

上手门槛：零门槛，但有平台限制

好消息是安装门槛几乎为零。下载 BrimDeck-<version>-Setup.exe 或便携版 zip，双击运行。官方强调"开箱即用"——程序会自动发现本机已登录的 Claude、Codex、Cursor，不需要你再填一次 API Key 或重新登录。

坏消息是平台锁死：这是纯 Windows 原生应用，macOS 和 Linux 用不了。WPF 与 System.Management、媒体会话 API 都是 Windows 专属。系统监控页面的很多能力（GPU 温度、整机功耗、电池健康）依赖 Windows 的 ACPI 和硬件计数器，不同笔记本表现差异很大——作者自己就注明，CPU 温度读的是主板固件的 ACPI 热区而非 CPU 自带传感器，"很多电脑根本提供不了"。

另外 Antigravity 的额度只能从桌面版读，且桌面版必须正在运行，CLI 的服务是查不到的。

争议与局限

有几个地方值得泼点冷水。

第一，数据准确性依赖各厂商不主动破坏自己的内部格式。 一旦 Claude 或 Antigravity 改了本地日志结构、字段编号或 SQLite schema，读取就会失效。项目没有版本协商机制，只有一个 UsageSynchronization.cs 做兜底——这在实践中意味着：某个工具升级后，可能突然读不到数了。

第二，成本数字是估算。 README 里明确写了："显示的成本不是你的实际账单。"它基于各家上报的用量或公开模型价格表推算，而你的订阅实际扣费以厂商账单为准。想拿它做财务核算是不现实的。

第三，项目高度依赖单一作者。 4 个贡献者、1 个主力开发者，代码总量在 29 万行 C# 量级，MainWindow.Music.cs 一个文件就 8.5 万字符，SettingsWindow.cs 8.9 万字符。虽说是 WPF 事件驱动风格导致文件偏大，但这种体量对单人维护者来说是个不小的负担。作者自己维护着 roadmap 和 release 分支规范，说明他清楚这个风险。

第四，Windows 隐私设置的兼容问题。 由于要读各家客户端的本地目录，Windows Defender 的实时扫描会明显拖慢文件读取，社区已有相关讨论。这意味着用户可能需要在 Defender 里给 ~/.claude 之类目录加排除项——这是把系统级安全便利换读取效率，代价需要用户自己权衡。

行业意义：AI 编程工具链的"仪表盘层"

BrimDeck 代表的其实是一个正在浮现的新品类：AI 编程工具链的状态可视化层。

Stack Overflow 2026 年 10 月的开发者调查显示，Claude Code 在使用 AI 智能体的受访者中渗透率已达 65.5%，Codex、Copilot 紧随其后。工具越多，"我到底用了多少、还剩多少"这个问题就越频繁，而各家都不愿意统一口径。于是社区自发出现了 macOS 上的 CodexIsland 等同类项目，BrimDeck 是 Windows 侧做得比较完整的一个，还上了 Microsoft Store。

作者在 README 里致谢了 macOS 上的 ftop——系统监控页面直接改编自它（MIT 协议）。这种"取长补短"的社区拼装风格，正是开源小工具生态的典型样貌。

它也提示了一件事：当 AI 工具的计费模式从"按次调用"转向"订阅制配额"，用户就需要一套新的仪表盘。Linux 上的 tmux 状态栏、macOS 上的 Notch 类工具、batteries 这类电量管理小工具，都在解决同一个问题——把散落在各处的机器状态，收拢到视线边缘的一个角落。BrimDeck 不过是把这个思路带到了 AI 配额这个新维度上。

有意思的是，一个纯桌面小工具在 2026 年 9 月建库、不到两个月做到 315 Star，说明开发者的痛点足够普遍。而它对"宁可留空也不编造""不写 token 到磁盘""不采集使用数据"这几条原则的坚持，或许比它的功能列表本身更值得借鉴。

---

项目地址：https://github.com/MoFeng2223/BrimDeck ｜ 协议：Apache-2.0 ｜ 语言：C#/.NET 10/WPF ｜ 数据采集时间：2026-10-29