Mac 上的 LLM 用量显示扩展核心作用是把 API 请求里的 token 消耗、费用、请求次数和限流情况直接做成一个常驻在菜单栏的小药丸pill、悬浮在桌面边缘的小条nub或者点开才能看到完整信息的面板panel。对每天要反复调 OpenAI、Anthropic 或各类 OpenAI 兼容接口的开发者来说这东西解决的不是“炫酷显示”问题而是“用量可见性”问题不用每次都在心里估算今天跑了多少 token也不用打开网页控制台。我最近把日常实验从“跑完再看账单”改成“边跑边看顶栏”第一个明显收获是某次批量任务因为循环参数写错token 消耗速度肉眼可见地不对劲几分钟内就看到数字异常直接停下重来。就那一次省下的成本已经超过我搭这个工具花的时间。下面按实际落地顺序拆先讲它显示什么再讲安装前要确认什么然后是配置步骤、排查顺序最后说多账号和团队场景。1. 先搞清楚面板里显示的是“用量”而不是“性能”1.1 五个常见指标分别回答什么问题这类扩展最常见的显示项有五个token 用量、费用、请求频率、配额与限流、模型分布。token 用量不是只有一个数字。输入 token、输出 token、缓存 token、思考 token不同 provider 的统计口径不一样。比如有的模型会自动把历史消息压成缓存输入费用比普通输入低但面板如果只给你一个总 token 数你是看不出这部分的。所以一个合格的用量面板至少要分开显示“输入”和“输出”最好能把“缓存命中”单独标出来。费用是大多数人装这个工具的第一动力。费用计算不能只看 token 数还要看模型单价。现在主流 provider 的价格表基本都按每百万 token 计价输入和输出价格不同缓存命中和未命中又不同。面板要能配置模型单价否则它给你的“费用”就是估算值只能用来观察趋势不能直接当发票。请求频率看的是每分钟请求数、每小时请求数。这个指标主要用来判断你有没有逼近限流阈值。批量任务一旦开始并发数开太高很容易撞上 provider 的每分钟限制。面板能显示这一类数字比报错来得更早。配额与限流解决的是“我还有多少额度”的问题。有的 provider 是按预付款余额算有的是按免费额度算还有的是按项目配额算。面板读取的是查询接口返回的数值刷新有延迟所以它适合当提醒不适合当实时账本。模型分布适合多模型混跑的人。同一个项目里既用大模型做复杂推理又用小模型做文本抽取费用差异可能快到 10 倍。如果你的扩展支持按模型拆分显示就能快速定位“钱到底花在哪个模型上”。1.2 它解决不了的事提前知道能少踩坑第一它不是官方账单。provider 的 usage 接口返回的数据和你月底看到的账单可能对不上。计费系统有合并规则、折扣、区域差异面板显示的是“当时查询到的值”不是最终结算值。第二它不替代日志系统。面板只能告诉你“消耗了多少”不能告诉你“哪一条请求导致了消耗”。要定位具体请求还是得靠服务端日志、请求 ID 和调用链。第三它显示不了生成质量。一个任务消耗高可能是模型真的在处理复杂内容也可能是你的 prompt 写得啰嗦、上下文塞得太多。面板给出的是结果不是原因。第四大多数这类工具只显示、不拦截。它不会因为你超了阈值就自动停掉任务。你需要自己在代码里做判断或者依赖 provider 的限额设置。想清楚这几点后续配置的时候就不会对工具产生不切实际的期待。2. 安装之前先确认系统、数据来源和权限2.1 系统与 UI 形态的匹配menu bar pill 是最常见的形态常驻在顶栏占用空间小适合只显示一两个数字。panel 是点击之后展开的完整窗口适合放趋势图、模型列表、时间范围切换这些复杂信息。nub 是悬浮在桌面边缘的小长条适合双屏用户或者不想让顶栏变挤的人。在选形态之前先看你的 macOS 版本。老系统对菜单栏扩展的 API 权限限制和新系统不一样有些扩展作者只维护新版系统。如果你的机器比较旧先确认工具的最低系统要求不要装完才发现没法常驻。我一般会先看一下扩展在系统设置里有没有被授权特别是“辅助功能”和“通知”两类权限。菜单栏扩展常驻本身不难难的是悬浮置顶。如果你选 nub 形态大概率需要辅助功能权限。这个权限在 macOS 里不是默认开启的首次启动会弹窗没授权的话悬浮条要么不显示要么点了没反应。2.2 数据从哪来三种常见来源第一种是直接调 provider 的 usage 查询接口。这类接口一般返回账户或项目级别的 token 用量和费用优点是准确度高缺点是有延迟。很多 provider 的用量数据不是实时的慢的时候可能滞后几十分钟。面板轮询一次拿到的是“某个时间点之前”的数据。第二种是读本地网关服务的统计接口。很多人会用自建的网关服务统一转发各个模型请求网关会记录每次请求的 token 和费用。扩展读网关的统计接口就能拿到相对实时的数据还能顺便按标签、按项目拆分。缺点是你要先有一个能正确输出统计字段的网关如果网关自己记录不准面板再准也没用。第三种是解析请求日志。适合动手能力强的人扩展监听某个日志目录把每次请求的 usage 字段抓出来自己聚合。优点是灵活缺点是日志轮转、文件权限、格式变更都会导致统计中断。实际体验是自己解析日志只适合“确定没有更好办法”的场景。我的建议是先用第一种把单 provider 跑通再考虑第二种做多模型汇总。第三种只在你对现状实在不满意时再碰。2.3 权限和密钥这步最容易踩坑扩展要读你的用量数据就得拿到 API key。这里最危险的习惯是把 key 明文写在配置文件里。很多工具第一次运行会要求填写 key然后保存到一个 JSON 文件里。如果你把它放进 Git 仓库的配置文件等于把凭证发给了所有能看到仓库的人。优先选择支持系统钥匙串Keychain保存凭证的工具。如果工具不支持就自己确保配置文件不进入版本控制并且把目录权限收紧。权限方面除了辅助功能还要注意网络权限。macOS 首次启动一个需要联网的扩展系统会询问是否允许网络访问如果当时点了拒绝后面就只显示 0不报错也不更新。排查这个问题通常比想象的久因为你会先怀疑 key 不对再怀疑接口不对最后才想到是系统权限拦住了网络请求。提醒先看权限再改配置。任何网络相关的扩展第一次启动弹窗都别急着点拒绝。3. 配置一个最小可运行的面板先跑通一条请求3.1 五步走到第一个数字第一步下载并安装扩展。不同来源的安装方式不完全一样但从应用商店或官方渠道装的一般都能在系统设置里直接看到权限入口。第二步添加 provider 并填入 API key。首次配置宁可少填不要多填。先只配一个 provider一个账号一个模型分组避免后面数字对不上时不知道是哪一项影响了结果。第三步选择显示指标。我建议先只显示“今日费用”和“今日总 token”。这两个指标最容易验证发一条请求如果数字变了说明链路是通的。一上来就显示“近 30 天趋势”“模型分布占比”这类复杂指标反而不好判断。第四步设置轮询间隔。默认值如果没给就先用 60 秒。轮询太频繁容易触发 provider 的接口限流也增加本机耗电轮询太长比如 10 分钟那面板就只是个自欺欺人的装饰品。第五步发一条测试请求。直接用命令行或者你平时调模型的方式发一个很短的请求等几秒再看面板。正常情况下请求完成后下一次轮询就会把这次消耗加进面板。3.2 核心参数怎么定下面这张表是我自己常用的初始值和进阶值实际参数要以你用的工具为准但思路可以通用。参数含义初始建议进阶建议轮询间隔每隔多久查询一次用量60 秒10 到 30 秒仅当你有实时限额需求时间范围面板统计的是哪个时间段今天本自然月或自定义时段显示单位token 数还是费用token 和费用同时显示按团队要求优先展示费用模型单价用于估算费用的价格按官方默认单价填定期核对价格变动后手动更新多账号汇总是否合并多个账号关闭确认口径一致后再打开阈值提醒用量超过多少时变色或通知费用的 80%按你的预算设定多条阈值这里的核心原则是能跑通之后再调参。先一条请求再批量最后才考虑复杂统计。3.3 如何判断它真的在工作判断条件有三个请求完成之后面板数字比之前大历史记录里能看到这条请求对应的模型和 token 数日志没有报错。三者同时满足才算真正跑通。不要以为“不报错就是正常”。有的扩展在调用 usage 接口失败时会静默失败界面还停留在上一次成功的数值。你发一条请求数字不动如果只看界面不查日志很容易误判成“请求没被记录”。我更建议把第一次测试拆成三步先启动扩展观察它能不能正常显示 0 或者空状态再发一条最小请求确认数字变化最后连续发三条请求确认数字不是只加了一次就停了。三步都过了再挂后台。4. 数字不动、不准、刷新慢按这个顺序排查4.1 完全没数据先从日志入口看完全不显示数据大多数人第一反应是 API key 写错了但我见过的实际情况里权限没开、网络被拦、日志目录不对也占了不少比例。排查顺序我一般这样排先看扩展自己的日志确认它启动后有没有开始轮询再看 API key 是否有效可以手动用命令调一次 usage 接口然后看系统设置里的网络权限和辅助功能权限最后看是不是轮询间隔太短导致被限流。有一个很容易被忽略的点如果你用的是公司发的 Mac系统可能装了一些安全策略限制应用读取钥匙串或者访问外部网络。这种情况下扩展不会告诉你“被策略拦截”只会一直转圈或者显示空数据。4.2 数字一直停在某个值时间范围和计费延迟数字“动过但再也不动”优先查两件事时间范围和 provider 的计费延迟。很多 usage 接口统计的是“上一个小时”或者“前 5 分钟”的汇总不是实时增量。你发完请求马上看数字没变不代表没记录可能只是还没进入统计窗口。这种情况等 10 到 30 分钟再回来看数字就会补上。时间范围也是一个常见坑。面板默认显示“今天”但如果它用的时区是 UTC那你的下午两点在它那里是上午六点数字自然对不上。配置里如果有时区选项优先选你自己的本地时区。4.3 数值偏大或偏小统计口径对不上面板显示的数值和你在 provider 后台看到的对不上几乎都是口径问题。缓存 token 是最典型的一个。你的请求命中了 prompt 缓存计费会便宜很多但部分 usage 接口返回的总 token 数仍然包含缓存 token。如果面板直接拿总数算费用就会高估成本。要看清楚它有没有单独识别缓存字段。另一个口径问题是模型价格表过期。provider 调价之后面板如果还按旧价格算费用就会偏。这不是 bug是配置没更新。遇到费用明显不对先看价格表。还有一种是多账号重复计数。如果你在同一个面板里配了两个账号但这两个账号其实是同一个组织下的子账号个别接口会把父级总量和子级用量都返回一遍导致数字叠加。4.4 卡顿和耗电都是轮询和刷新频率问题面板卡顿、风扇狂转、电池掉得快九成是轮询间隔太短或者日志文件太大。轮询间隔建议从 60 秒起步。如果 60 秒不够先改成 30 秒观察一段时间再固定下来。不要一上来就 5 秒一次因为 provider 的 usage 接口本来就有延迟5 秒轮询拿到的数据几乎和 30 秒一样白白浪费资源。如果你的扩展还拿着趋势图日志文件会越来越大。一旦日志文件达到几百 MB启动和读取都会变慢。定期清理日志或者配置日志轮转是很多人忽略的维护项。注意用量显示工具是“辅助观察”不是“实时监控系统”。它不需要秒级刷新正常使用 30 到 60 秒刷新一次完全够用。5. 进阶用法多模型汇总、费用阈值、团队对账5.1 多 provider 汇总时别直接相加当你同时用两三个 provider 时想把费用放在一个面板里看第一个要解决的是口径统一问题。每个 provider 的时区、币种、计费字段都不一样。有的返回美元有的返回人民币。有的按自然月统计有的按账号创建日滚动统计。直接把两个数字相加看起来很方便实际上误差很大。正确做法是先把各个 provider 的原始数据分别记录下来再统一换算成同一种货币、同一个时间区段最后汇总。这一步最好在面板配置里用“多账号分组”功能做不要自己在 Excel 里手动拼。5.2 把面板当成“停止信号”而不是“账本”面板最适合扮演的角色是“停止信号”当费用超过预算的 80%它准时变色提醒你当某次任务每秒都在烧钱它让你第一时间发现异常。至于真正的账本还是要以 provider 官方的账单为准。面板的实时估算和账单之间存在时间差这是所有用量统计工具的通病不是哪家做得不够好。我的习惯是给每种模型、每个实践项目都设一个软阈值跑批量的同时瞥一眼面板。如果发现数字涨得比预期快就先暂停任务查一下是不是循环没退出、并发是不是开太高而不是等任务全部跑完。5.3 团队使用前先解决身份和日志如果是几个人共用同一个账户建议先用 provider 自带的子账号或项目维度拆分用量再让面板去读各自项目的数据。面板本身不解决权限隔离它只是把你给它的 key 能查到的数据展示出来。团队场景还有一个容易忽略的问题谁的日志出了问题谁该负责。如果每个人的 key 都在同一个面板里汇总出事之后很难定位。更稳妥的方式是每个人单独一个项目分组面板只做汇总展示日志留在各个子账号的上下文里。给团队用的时候API key 的权限要尽量收窄。能只读就不要给写权限能限定项目就不要给全网权限。这样即使 key 泄露影响面也可控。6. 实在建议什么情况下不值得装这类扩展6.1 你可能不需要它如果你一个月才调几次 API打开网页控制台看一次就够了装一个常驻菜单栏扩展反而添乱。如果你只看月度账单不在乎每天花了多少也不需要提醒那这个工具对你没有实际价值。如果你平时只是用现成的聊天客户端不写代码调 API那更用不上。因为它统计的是你自己的 API key 产生的那部分用量聊天客户端内部走的是官方订阅计费不会出现在你的 usage 接口里。反过来如果你每天要跑批量任务、做实验对比、或者给团队控制成本这类扩展就值得认真配一次。6.2 安全习惯必须比功能更早想清楚API key 一旦泄露可能带来的直接损失就是账号被刷费用。所以安全习惯要从第一次配置就开始。只使用只读 key。所有用量查询工具都应该配只读权限不需要有创建、修改、删除的权限。如果某个工具强制要求完整权限建议换一个。不要把 API key 截图发到聊天工具里。截图比命令行记录更容易被人随手转发而且几乎没办法批量撤回。定期轮换 key。建议每三个月或者每次怀疑泄露时更换同时把旧 key 在 provider 的后台禁掉。这个操作比任何面板设置都重要。如果配置文件里必须写 key确保它不在 Git 仓库里。你可以在仓库目录下加入忽略文件只保留示例配置模板。变量注入也是可选方案但前提是你熟悉当前的部署环境。6.3 最后说一句这类工具真正落地时最该盯住的不是界面好不好看而是三条输入数据来源是不是可靠、轮询会不会给自己造成额外负担、key 和日志是不是安全。踩过几次之后我发现很多问题不是工具能力不够而是前置权限和统计口径没有处理干净。先用单 provider、单指标跑稳再逐步叠加多账号和费用提醒。稳定运行一两周之后你会发现它真正的存在感不是每天让你眼花缭乱的数字而是在某一次异常任务里替你提前喊了一声“停”。