macOS菜单栏实时显示Claude订阅用量：额度窗口与重置时间一眼可见

今天这个项目来自 Hacker News 的 Show HN，定位非常小、非常准：在 macOS 菜单栏常驻显示 Claude 订阅使用量。一句话版本就是，你订阅了 Claude 之后，不用再反复打开网页去看这个 5 小时窗口还剩多少额度、什么时候重置，菜单栏直接给你一个实时数字。

这类工具的价值往往被低估。Claude 订阅用户最难受的不是“额度不够”，而是“不知道额度什么时候恢复”。对话写到一半，模型突然提示当前会话窗口已经到上限，这时候你手头的工作流就断了。如果菜单栏能直接告诉你“还剩 20% 左右，预计 1 小时后重置”，你至少可以合理安排什么时候继续写、什么时候切去干别的，而不是干等。

这篇文章不打算只报一个“有新应用上线”的新闻，而是把它当作一个典型项目来拆：核心能力怎么设计、菜单栏应用通常怎么实现、订阅用量数据从哪里来、拿到项目后怎么验证、最容易踩哪些坑。如果你平时重度使用 Claude，又希望把订阅状态变成系统级可见信息，这篇文章可以直接收藏。

1. 核心能力速览

从目前公开的标题信息看，这是一个很明确的 macOS 菜单栏应用，目标用户是 Claude 订阅用户。先按现有信息整理一份能力速览。

这里特别注意一点：菜单栏应用安装门槛虽然低，但“能否真正拿到订阅用量”才是决定项目长期可用的关键。如果作者只是抓网页某个内部接口，那 Anthropic 前端结构一改，应用可能就失效；如果作者用了更稳定的方式，比如官方客户端本地数据或用户手动复制状态，那可靠性会高一些。

实际场景中，你需要的不是一个展示静态数字的工具，而是一个能稳定反映“当前 5 小时窗口用量”和“重置时间”的常驻状态组件。下面先把需求背景补齐。

2. 这个需求从哪来：Claude 订阅的用量窗口机制

Claude 的订阅模式和传统 API 按 Token 计费不完全一样。日常对话中，大家感知最明显的是限流窗口设计。

• Claude 订阅不是给你一整月额度随便均匀消耗，而是按滑动时间窗口来控制用量。
• 最常见的体验是“当前 5 小时窗口”概念：你在网页版或桌面客户端持续对话，额度会随着模型调用被消耗，窗口时间过后会重置一部分可用额度。
• 界面上通常会有类似“限制将在 XX:XX 重置”的提示，或者对话输入框附近显示可用状态。

这个机制造成了几个实际问题：

第一个问题，用户对额度的感知是片段化的。你正在写代码、改文章、整理资料，不会每过 10 分钟就去网页里翻剩余额度，更多时候是等到模型突然开始拒绝回复，才发现已经撞到上限。

第二个问题，不同时间段用量的波动很大。某个时段连续长对话，额度消耗会非常快；中间休息一段时间，又觉得好像恢复了一些。这种波动让人很难估计“接下来到底还能聊多久”。

第三个问题，Claude 的重置时间不是一个固定的每天零点，而是与时间窗口绑定。用户如果不盯着界面，很难搞清楚具体几点能恢复。

菜单栏应用的价值就在这里：把原本需要打开网页、盯着会话页面才能看到的订阅状态，变成常驻的系统级信息。让用户不用每次主动查询，菜单栏文字就是当前状态。这和看天气、看日历、看系统 CPU 占用是一个逻辑——真正有用的效率插件，不是把信息变多，而是把高频查询变成低注意力查看。

3. 一个体验合格的菜单栏额度提醒应该做什么

只看“显示订阅使用量”这个描述，可能觉得功能很简单。但要把体验做好，至少要覆盖下面几个维度。

3.1 当前窗口用量状态

菜单栏最直接显示的内容应该是“当前用量百分比”或“剩余可用比例”。对用户来说，最关心的不是具体 Token 数值，而是“现在还能不能继续用”。

例如图标直接显示“80%”，表示这个时间窗口已经消耗了八成；或者显示“剩余 20%”，再配合一个变色逻辑，用量越高颜色越接近红色。这样扫一眼就能判断是否要收敛对话长度。

3.2 重置时间预判

比当前用量更重要的是什么时候重置。如果菜单栏能显示“09:40 重置”，用户就不需要在模型回复被限流前反复试探。

这部分数据如果应用能拿到，需要设计两种状态：

• 窗口已用完：明确显示何时恢复。
• 窗口未用完：显示当前窗口终点，供用户判断是否要等窗口过后再执行大任务。

3.3 订阅档位区分

Claude 有不同订阅级别，不同档位的可用额度和限流策略不一样。菜单栏应用最好读取到当前账号对应的档位，并按该档位的规则做提示。否则应用把 Pro 用户的数据当成 Max 用户的数据来展示，数字就没有参考价值。

3.4 交互菜单

点击菜单栏图标后，除了显示当前使用情况，还应该提供一个下拉菜单，包含：

• 当前订阅账号名称或说明；
• 手动刷新按钮；
• 打开 Claude 官方网站或客户端；
• 应用设置项；
• 退出。

这个菜单不需要复杂，但必须让用户能快速手动刷新。因为菜单栏上的数据可能是定时轮询的，如果轮询间隔较长，手动刷新就能在关键时刻提供即时状态。

3.5 后台资源占用

macOS 菜单栏应用最容易被吐槽的就是常驻内存占用和耗电。用户装一个额度提醒应用，并不希望它占用几百 MB 内存或者持续做高频率网络请求。

合理设计应该是：

• 定时轮询间隔不要过短，例如 1 到 5 分钟一次即可；
• 无网络请求时，应用处于空闲状态；
• 菜单栏更新只改文字，不做高开销动画；
• 支持开机自启但默认不开启。

4. 菜单栏应用的技术选型与实现思路

如果你不想直接使用打包好的二进制，而是希望自己编译或者改功能，那么需要了解 macOS 菜单栏应用的基本实现方式。下面给一套通用的技术路线，具体代码需要按项目实际情况调整。

4.1 Swift + AppKit 是原生方案

macOS 菜单栏应用最核心的类就是NSStatusItem，通过NSStatusBar.system.statusItem创建。配合NSMenu构建下拉菜单，配合Timer做定时刷新。

下面是一个最小可用模板，展示如何创建一个带文字的菜单栏应用：

import AppKit class StatusBarController: NSObject { private var statusItem: NSStatusItem? private var timer: Timer? private var usageText = "Claude: --" override func awakeFromNib() { // 创建可变宽度的菜单栏 item statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) if let button = statusItem?.button { button.title = usageText button.action = #selector(statusBarClicked) button.target = self } buildMenu() startTimer() } private func buildMenu() { let menu = NSMenu() let usageItem = NSMenuItem(title: "当前用量: 未知", action: nil, keyEquivalent: "") menu.addItem(usageItem) menu.addItem(NSMenuItem.separator()) let refreshItem = NSMenuItem(title: "手动刷新", action: #selector(refreshUsage), keyEquivalent: "r") refreshItem.target = self menu.addItem(refreshItem) let quitItem = NSMenuItem(title: "退出", action: #selector(quitApp), keyEquivalent: "q") quitItem.target = self menu.addItem(quitItem) statusItem?.menu = menu } @objc private func refreshUsage() { // 在这里执行真正的用量读取逻辑 usageText = "Claude: 更新中..." statusItem?.button?.title = usageText } private func startTimer() { timer = Timer.scheduledTimer(timeInterval: 60.0, target: self, selector: #selector(refreshUsage), userInfo: nil, repeats: true) } @objc private func statusBarClicked() { // 可选：点击时打开主面板或执行刷新 } @objc private func quitApp() { NSApp.terminate(nil) } }

这段代码不是某个完整开源项目的完整源代码，而是 macOS 菜单栏应用的基础骨架。实际项目中，refreshUsage()里要调用真正的数据获取逻辑，再把返回结果解析成可读文本。

4.2 LSUIElement：隐藏 Dock 图标

普通 macOS App 启动后会在 Dock 栏出现图标，但菜单栏小工具通常不希望这样。实现方式是修改 Info.plist，加入一个键：

<key>LSUIElement</key> <true/>

设置为true后，应用启动后不会出现在 Dock 中，只保留菜单栏图标，也不会在 Cmd+Tab 切换列表里出现。

这个配置对菜单栏工具类应用几乎是标配。如果你发现应用编译后运行会弹出一个普通窗口，大概率就是没有配置LSUIElement。

4.3 轮询与通知的取舍

菜单栏显示订阅用量，最简单的是定时轮询。但考虑到订阅窗口状态变化不会非常频繁，1 分钟到 5 分钟刷新一次足够。

还有一种更好的体验：当系统检测到用户正在活跃使用 Claude 桌面客户端时，再主动触发一次查询。但这样会增加实现复杂度，需要监听 App 激活事件或进程状态。对第一版应用来说，建议先做固定间隔轮询，后续再根据反馈优化。

4.4 打包和签名问题

macOS 应用分发有两个常见坑：

• 不签名或 ad-hoc 签名的应用，在别的 macOS 设备上首次运行时可能被 Gatekeeper 拦截。
• 用户如果下载一个未签名应用，需要右键打开或到“系统设置 -> 隐私与安全性”里允许运行。

从安全角度讲，建议选择开源项目并自己编译，或者选择带有开发者签名的发布版本。不要轻易运行来路不明的二进制菜单栏工具，因为菜单栏应用一旦带恶意逻辑，它就能一直读取你本机状态。

5. 订阅用量数据从哪里来：关键实现难点

这是整个项目最核心的难点。菜单栏 UI 很容易写，困难的是获取真实、稳定的订阅用量数据。

5.1 官方页面与桌面客户端显示

Claude 网页版和桌面客户端通常会在会话区域显示当前窗口的用量状态。问题是，这类信息往往不提供公开稳定的第三方读取接口。

如果项目采用“自动读取官方页面数据”的方式，通常会涉及：

• 用户登录态；
• 页面内部接口；
• 会话 Cookie 或令牌；
• 前端接口字段变动风险。

这里需要非常明确：任何读取订阅用量的操作必须以用户本人主动授权为前提，只用于显示自己的用量状态，不能以绕过限流、批量注册、自动操作账号为目标。

5.2 浏览器扩展方案的利弊

另一种做法是做一个浏览器扩展或用户脚本，让用户在 Claude 页面登录状态下，由扩展自动读取页面已显示的额度信息，再传递给菜单栏应用。

这种方式优点是不直接解密或绕过服务端限制，只是把用户已经能看到的 UI 数据同步到菜单栏；缺点是 Claude 页面 DOM 结构一变，扩展需要跟着更新，仍然有维护成本。

5.3 手动导入状态

也可以做纯手动模式：用户在官方页面看到重置时间后，手动填入菜单栏应用，或者复制一段文本让应用解析。这种方式最安全，不涉及账号授权，但用户体验打折，更适合作为补充功能。

5.4 隐私边界与账号安全

无论采用哪种数据获取方式，都要遵守几条底线：

• 不要把账号密码直接交给第三方应用；
• 不要在代理工具或脚本中保存完整 Cookie 明文；
• 不要让应用自动执行非用户主动触发的账号敏感操作；
• 不要尝试绕过 Claude 的限流机制；
• 不要在公开日志里输出账号信息或订阅详情。

如果这个菜单栏应用是开源项目，你需要仔细看它请求了哪些地址、本地保存了什么数据。如果应用闭源但又要求登录 Cookie，风险就要更高一些。建议的稳妥路径是只读取本地显示状态，使用用户自己已有的登录会话，而不是让应用去模拟登录。

6. 拿到 Show HN 项目后的验证流程

虽然目前公开信息主要是标题，但如果你已经下载到源码或二进制包，建议按下面流程验证，避免直接拿常用账号去测试。

6.1 先审阅源码和权限

如果项目提供源码，先看三个地方：

• 网络请求部分：它请求了哪些域名，是否只请求 Claude 官方域名。
• 本地存储部分：是否存在明文保存 Cookie、Token 的行为。
• 更新机制：是否有自动下载远程代码或二进制替换行为。

如果项目是一个闭源二进制，建议放在虚拟机或临时用户环境里先跑，或者干脆放弃，优先寻找开源替代方案。

6.2 使用低风险账号做登录测试

不要第一步就用主账号或包含重要资料的账号。可以先用一个不重要的账号或临时订阅账号测试。

测试时重点观察：

1. 菜单栏是否正常出现图标和文字；
2. 是否能显示当前用量百分比；
3. 点击菜单栏后能否打开下拉菜单；
4. 手动刷新是否能更新数据；
5. 应用启动后内存占用是否正常；
6. 退出应用后相关进程是否一并退出。

判断成功的标准很简单：

• 菜单栏出现且文字更新；
• 数据与你手动打开 Claude 页面看到的状态一致；
• 应用退出后没有残留进程；
• 没有异常网络请求。

6.3 观察网络请求与日志

如果是在本机调试开发，可以通过 macOS 的Console.app或 Xcode 控制台查看应用日志。如果只是想看应用发出什么请求，可以用系统级抓包工具观察，但需要注意你只应分析自己设备上主动授权的流量，不要分析第三方未授权数据。

实际开发中，推荐的观察流程是：

• 启动应用；
• 手动触发刷新；
• 看是否有请求发出；
• 看请求返回的状态码；
• 看本地是否有敏感数据被写入。

6.4 验证在不同订阅档位下是否正常

如果你能切换到不同档位的订阅账号，可以顺带验证应用是否区分订阅档位。同一个 5 小时窗口，Pro 和 Max 的限额不同，应用展示的剩余比例也可能不一样。如果应用对所有账号都显示同一逻辑，那可能没有做档位适配。

7. 常见问题与排查方法

下面结合 macOS 菜单栏工具类应用常见问题，给一份排查表。

最容易忽略的问题有两个。一个是网络请求频率：菜单栏小工具如果每分钟请求一次官方接口，不仅费电，还可能在多次请求后触发账号风控；另一个是应用退出逻辑：菜单栏应用不做事后清理，容易留下残留进程。

建议第一次跑通后，先把刷新间隔调成 300 秒左右，确认不影响使用再缩短。

8. 最佳实践与使用建议

订阅使用量查看器这类工具，核心在于“有用”和“不添乱”。

8.1 保持只读边界

应用应当是只读状态查看器，不应该具备任何主动绕过限流、批量提交任务或修改账号状态的能力。如果某天你发现某个菜单栏工具声称能“解除 Claude 限额”或“让订阅额度无限使用”，这基本可以判断为高风险工具，不要使用。

正确的使用方式是把限制当作工作流约束的一部分：看到剩余量不足，就主动降低对话复杂度或切到非高峰期继续。

8.2 账号安全优先

不要在第三方工具里输入 Claude 账号密码。最理想的情况是，应用通过你已有的官方客户端登录态展示用量，不额外采集凭据。如果你拿不准应用的数据采集方式，就不要把它接入主账号环境。

8.3 与 Claude Code / CLI 场景配合使用

现在很多用户不仅用 Claude 网页版，还会在开发场景中使用 Claude Code 等 CLI 工具或桌面客户端。不同入口的额度计算方式是否一致，要以官方页面显示为准。菜单栏应用如果能成为全局用量展示层，就能帮你在开发终端和聊天界面之间做统一判断：

• 写代码前看一眼菜单栏，剩余量充足就放心跑复杂重构；
• 剩余量偏低，就先做代码审查和文档整理，把大 Token 消耗任务延后到窗口重置；
• 多账号场景下，标记出当前使用的是哪个账号，避免任务跑到一半才发现账号不对。

8.4 用目录和配置隔离环境

如果你是开发者，想基于这个 Show HN 项目做二次开发，建议把项目目录、模型配置、日志目录分开管理。不要把所有东西堆在用户目录下，也不要让应用把日志写到系统目录。

推荐的本地目录结构：

~/claude-status-app/ ├── Config/ │ └── app.json ├── Logs/ ├── Sources/ └── Build/

这个结构能保证后续调试、更新时不会污染正式环境。

8.5 降低刷新频率，延长账号稳定性

订阅用量查询和普通 API 调用不同，官方页面的接口并不是专门给第三方高频轮询准备的。以下是几条工程建议：

• 刚启动时刷新一次；
• 用户手动点击时刷新一次；
• 后台定时刷新间隔不小于 60 秒；
• 应用在菜单栏进入空闲状态时，减少无谓请求；
• 如果返回异常，不要立即连续重试，应退避。

8.6 关注 macOS 系统兼容性

macOS 的菜单栏在系统更新后可能出现两类变化：一类是菜单栏图标挤出或显示异常，另一类是网络权限提示。如果你在较新的 macOS 版本上遇到菜单栏图标不显示，先去“系统设置 -> 隐私与安全性”里看是否有网络权限或辅助功能权限请求被拒绝。

9. 这个项目还有哪些扩展方向

如果你觉得只显示订阅额度太单薄，可以基于同一套数据继续扩展。当然，扩展的前提是遵守数据来源的合规边界。

9.1 用量历史记录

应用每小时记录一次当前剩余额度，形成一张趋势表。这样你就能看到自己通常什么时间段消耗最快、哪些操作最容易触发窗口上限。数据只保存在本地，不主动上报。

9.2 超出提醒

菜单栏应用可以在后台检测到当前窗口剩余量低于某个阈值时，发送系统通知。这个功能价值比较高，因为用户只有在不主动盯数据时，才更需要系统级提醒。

9.3 多账号状态汇总

如果一个人有多个 Claude 订阅账号，并且使用是合规的，那么菜单栏可以切换显示不同账号的用量状态。但要注意账号隔离和隐私，不要在配置文件中明文保存太多登录信息。

9.4 手动任务估算

结合当前剩余量和普通对话的平均消耗，给用户一个粗略的估算：“当前额度还能继续约 X 轮高质量长对话”。这个数字不必非常精确，能帮助用户做决策即可。

9.5 接入定时提醒

比如每到一个整点或者每 30 分钟，菜单栏短暂闪烁一次，提醒用户检查当前窗口剩余量。如果是长时间写代码的用户，这个功能可以避免在连续对话中忽视限流状态。

10. 总结

这个 Show HN 项目的切入点选得很好，它把 Claude 订阅用户最常遇到的一个痛感很强的场景，做成了一个 macOS 原生菜单栏工具。核心价值不是创造新的 AI 能力，而是把已有的订阅用量信息以更低注意力的方式呈现出来。

对普通用户来说，拿到应用后第一件事不是追求复杂配置，而是先确认三点：应用是否开源或可信、数据获取是否只读、显示结果是否和官方页面一致。只要这三点没大问题，就可以把它放进登录项里常驻使用。

对开发者来说，这个项目的难点不在菜单栏 UI，而在“数据来源的稳定性”和“账号授权安全边界”。如果你正好也在维护类似的 Claude 订阅状态查询工具，建议优先处理异常退避和刷新频率控制，避免一个显示工具变成账户安全风险点。

先跑通最小显示路径，再逐步加历史记录和通知提醒，这个方向比较稳妥。