BUILD LOG · 2026-09-19
比快更快
为何要做一个本地的词元统计工具，TA有什么优势？
鄙人使用 CC-Switch时，觉得其统计功能十分好用，然而在日常使用大语言模型和智能体时，并非总需调用 CC-Switch 的核心功能，却仍希望能快速、准确地获取本地词元的使用数据，以此为契机开发了 tokrs 这一 CLI 程式。
关于适配
目前 tokrs 已基本稳定，支持：
- Claude
- Codex
- Gemini CLI（目前被官方弃用，准备适配反重力）
- Grok Build
- OpenCode（目前已适配 V2 版本）
- Pi
- Kimi Code CLI
- DeepSeek Harness
- VS Code Copilot Chat
可以称之为“群贤毕至”，诚然还有一些不足，例如未适配反重力等智能体工作环境，待时机成熟，鄙人也会第一时间适配。当然，也欢迎诸位为项目提出宝贵意见或做出贡献。
关于界面
--------------------------------------------------------------------------------------------------
Key Requests Input Output Cache Read Cache Write Total Cost
==================================================================================================
Today 128 18,432 96,510 1,204,881 88,000 1,407,823 $4.21
--------------------------------------------------------------------------------------------------
claude 3,412 1,204,553 2,891,004 88,312,440 6,501,220 98,909,217 $156.20
--------------------------------------------------------------------------------------------------
codex 1,208 601,220 1,100,322 40,122,884 0 41,824,426 $61.03
--------------------------------------------------------------------------------------------------
opencode 875 320,110 441,027 12,088,340 1,022,884 13,872,361 $21.55
--------------------------------------------------------------------------------------------------
copilot 642 220,481 310,224 0 0 530,705 $12.77*
--------------------------------------------------------------------------------------------------
Total 6,137 2,346,364 4,742,577 140,523,664 7,524,104 155,136,709 $251.55*
--------------------------------------------------------------------------------------------------
表格虽然简陋，也不“现代”，但愚以为这是符合项目轻量、快速要求的。CLI 应用应当自然、快速、随用随取，因此未设计美丽的 TUI 或 GUI 界面。
关于价目表
愚以为自定义 JSON 价目表是项目的“点睛之笔”。虽系自诩，却也并非全无道理。通过自定义价目表，使用者可以灵活、高效的定义自己使用的模型价格，而非绑定官方价格或是固定的优惠倍率。目前的价目表已基本涵盖大模型定价的几乎所有元素：
- 输入 / 输出词元
- 缓存创建 / 命中词元
- 定价起始日期
- 长上下文加价
- 峰谷调价
force强制覆盖自报价
使用者可以随心所欲的根据自身真实使用成本，定义自己的价目表，获得符合自身使用的花费预估。
当然，为方便诸位使用，仓库中也提供了 OpenCode Go 的价目表
JSON 配置， 更新可能不及时，可供参考
关于命令
目前的命令是相当复杂，且学习成本较高的，但因此也为使用者提供了大量的选项:
- 统计指定 App
- 统计指定日期 / 时间段 / 模型
- 输出
JSON - 指定统计时使用的线程数
希望这个工具，可以真正帮到诸位，为大家使用大语言模型、智能体提供参考。
Q&A
为什么要做流式读取，多线程？
鄙人发现，若智能体上下文中包含大量图片、文档、子智能体可能导致日志急剧膨胀。在测试中，面对动辄数十 GB 的日志文件，若 CLI 全量载入并解析，极大可能导致内存溢出或大量硬盘缓冲，使得解析速度极其缓慢，甚至崩溃。
为了解决超大日志的读取问题，程式采用：
- 流式读取，读取并即时解析日志文件；
- 文件级多线程读取与解析，最大程度加快速度。
目前，tokrs 在解析大量超大日志文件时，依然能够保证资源占用可控且速度尚可。