FEBIRDY BLOG
个人传送门 ↗
瞎折腾系列 更新于 2026-09-18

写了一个搭配 New API 使用的统计 Token 用量的 Chrome 插件

关于 New API AI 中转站的搭建

前段时间，我给自己搭了一套 New API 服务，用来统一管理平时使用的几个 AI 渠道。

这里说的 New API，是那个开源的 AI 接口管理和模型聚合项目，官网是 newapi.pro，源码放在 GitHub 上。我没有使用在线托管服务，而是按照项目提供的方式，用 Docker Compose 把它部署在自己的 Mac mini 2024 里，再通过管理后台配置渠道、分组和令牌。

自建以后，客户端不再需要保存一堆不同的地址和密钥。我的做法是让一个分组对应一个渠道，需要切换提供相同模型的不同上游时，就可以直接在 New API 后台调整令牌所属的分组。这样 Codex、OpenClaw 等客户端的地址、Key 和模型别名可以尽量保持不变。

关于统计维度的小需求

用了一段时间，感觉非常好用，统一管理 Token 也方便了很多。但是总觉得它官方的统计功能好像缺少点什么。我想统计不同的工具，也就是不同的 API 令牌的 Token 用了多少、主要消耗在哪个渠道和模型，以及今天、本周、本月分别用了多少。New API 原本没有提供按照 API 令牌这个维度的统计，另外还希望可以更醒目地看到 Codex 额度的使用情况。

于是，我开始给自己的 New API 搞一个更顺手的用量看板。当然，这次也还是让 Codex 帮我搞的。自从 AI 工具好用了之后，想干点事也变多了，很多之前懒得做的小需求都可以得到实现。

为什么先做了个 Chrome 插件

其实最直接的办法当然是修改 New API 自带的管理后台，把统计页面加到项目里面。

不过我一开始并没有这样做。New API 本身还在持续更新，如果为了一个尚未验证的自用需求，马上长期维护一套前后端修改，后面同步上游代码时就要一直处理额外差异，稍微有点麻烦。

相比之下，Chrome 扩展感觉耦合度更低：

  • 不需要改动正在运行的 New API；
  • 侧边栏可以在其他网页打开，刷新时再使用已经登录的管理后台标签页；
  • 不满意时可以快速调整，不影响核心服务；
  • 确认需求确实有价值以后，再决定是否修改服务端。

所以第一版采用了 Chrome Side Panel。它大致按下面的方式工作：

1
2
3
4
5
6
7
8
9
Chrome 侧边栏
    ↓
扩展后台脚本
    ↓
已登录的 New API 管理后台标签页
    ↓
同源调用 New API 接口
    ↓
整理并展示用量统计

插件不会保存管理员密码、Cookie 或 API Key。需要刷新数据时，它会找到已经登录的 New API 后台标签页，通过页面所属的同源环境请求接口，然后把整理后的统计结果交给侧边栏展示。

这套方式对我自己的使用场景比较合适：浏览器本来就经常开着管理后台，扩展只是在已有登录状态下增加一个更方便的查看入口。

第一版能用了，但分页很快成了问题

第一版直接读取 New API 原有的日志接口，然后在浏览器端完成统计。

它会逐页获取消费日志，再按照 API Token、渠道和模型进行汇总。日志量不大时，这个方案足够简单，也确实解决了最初的问题。

为了避免频繁请求，插件还增加了本地缓存。切换统计范围时先显示上一次成功的结果，刷新过程中继续保留旧数据；如果请求失败，也不会把原本正常的页面突然清空。

但随着使用日志增加，问题很快出现了。

查看今天和本周还比较轻松，切换到本月、上月或者季度时，就可能需要读取很多页日志。读取时间会变长，接口请求次数也明显增加。如果给分页设置最大读取数量，结果又可能不完整；如果不限制数量，就可能为了看一个统计页面向服务端连续发起大量请求。

我一度给大范围统计增加了手动全量刷新、读取上限和分页进度。这些功能能够缓解问题，却没有改变它的本质：浏览器为了得到几个汇总数字，仍然要把大量原始日志搬回来再计算。

这时候只在 Chrome 插件里努力就有点不太合适了。

从浏览器聚合改成服务端聚合

既然最终只需要汇总结果，更高效的方式就是让数据所在的服务端直接计算，再把结果一次返回给插件。

因此，我后来在自己维护的 New API 部署中增加了两个用量聚合接口。这不是 New API 官方原生接口，使用这套 Provider 需要先部署包含这部分改动的版本：

1
2
GET /api/log/usage-summary
GET /api/log/self/usage-summary

前者用于管理员查看整体统计，后者用于普通用户查看自己的统计。接口支持按时间、用户、API Token、渠道、分组和模型筛选，并返回请求次数、输入 Token、输出 Token、总 Token 和 quota 等汇总结果。

这一版没有新建统计表，也没有修改原始日志的写入流程，只是在查询时直接对现有消费日志进行聚合。这样改动范围比较小，也避免为了一个展示功能额外维护一套同步数据。

权限边界也需要单独考虑。管理员可以按用户筛选，普通用户接口则始终以当前登录身份作为范围，即使客户端额外传入其他用户名，也不能借此查看别人的数据。

改成服务端聚合以后，插件不再为了统计一个月的用量而逐页搬运原始记录。对浏览器来说，它只是发出一次查询，再把已经整理好的结果展示出来。

新旧方案需要同时保留

服务端聚合更合适，但这个接口属于我自己的 New API 扩展，并不是所有 New API 实例都自带。

因此插件最后保留了两种数据来源（放在了插件侧边栏的最下面进行切换）：

  • 服务端聚合：默认方案，调用新的聚合接口，一次返回完整结果；
  • 旧版分页：兼容尚未部署自定义接口的实例，继续读取原始日志。

两种模式各自使用独立缓存，避免切换以后把不同来源的数据混在一起。只有旧版分页模式才会显示全量读取上限、手动刷新和分页进度，服务端聚合模式下这些设置没有意义，就直接隐藏。

顺手加上的 Codex 额度卡

除了 New API 日志统计，我平时还需要观察 Codex 账号的使用额度，因此后来又在侧边栏顶部增加了额度卡。

它会分别展示短周期窗口和周周期窗口，包括剩余比例、下次重置时间和倒计时。周周期还会根据当前时间给出使用节奏的参考位置，方便我判断最近是用得太快，还是还有不少额度没有利用。

这部分看起来只是两根进度条，实际处理起来似乎还有点小坑，不过也都是一些小逻辑问题。

例如，7×24 小时的滚动窗口并不一定从某一天的零点开始，它可能横跨八个自然日。如果直接按照“七天平均”画一条计划线，显示出来的节奏就会产生偏差。因此页面同时区分了当前滚动窗口的位置和按自然日观察的参考位置。

额度卡每隔一小段时间在本地更新倒计时和计划线，但不会频繁请求服务端。真实额度查询有单独的缓存间隔，本地重绘只使用已经缓存的数据进行计算和展示。

我和 Codex 是怎样完成这次开发的

如果按照传统方式从头手写，这个插件涉及浏览器扩展、后台脚本、登录态、缓存、统计逻辑、页面交互以及 New API 后端接口。别的不说，光看 New API 的历史代码并按它的代码风格修改，就要花很多时间。想法很多，时间很少，还是节约时间吧。

这次的实际开发方式是，我先描述自己每天怎么使用 New API、希望看到什么，以及哪些行为不能接受，再让 Codex 根据现有项目完成实现。功能加载到浏览器以后，我用真实环境操作，发现问题后再继续调整。

整个过程大致经历了下面几步：

  1. 先做一块能够按 Token 查看消耗的侧边栏；
  2. 增加渠道、模型和不同时间范围；
  3. 为大范围日志增加缓存、上限和手动刷新；
  4. 发现分页方案的根本限制；
  5. 给 New API 增加服务端聚合接口；
  6. 让插件兼容服务端聚合和旧版分页；
  7. 补充 Codex 额度展示和各种异常状态；
  8. 用自动化测试和实际浏览器操作反复验证。

使用 AI 完成开发，不等于只需要说一句“帮我写个插件”。AI 可以大幅加快实现速度，但人仍然要定义问题、做方案取舍、判断风险并验收结果。即使没有逐行阅读所有代码，也至少要知道功能碰了哪些数据、拥有什么权限、失败时会发生什么，以及应该用什么方式验证。

2026 年 9 月 18 日更新

这段时间又把项目整理了一遍，现在已经开源到 GitHub：

https://github.com/sandy1108/newapi_analysis_chrome_ext

当前公开版本是 1.14.0。这次整理补充了 README、MIT License 和隐私政策，也移除了个人服务地址、本机路径等不适合放进公开仓库的内容。插件支持主动配置自己的 New API 管理后台 URL，不会把统计数据上传到我自己的服务器，也不会保存管理员密码、Cookie 或 API Key。

目前还没有发布到 Chrome Web Store。现阶段可以直接从 GitHub 下载后，以“加载已解压的扩展程序”的方式使用。