Claude Code和Codex的用户有个共同的烦恼：想知道自己烧了多少token，得付出明显的性能代价。一位韩国开发者最近放出了一个叫Toki的替代方案——查询速度提升1742倍，几乎零开销。
故事从他所在团队的"token燃烧排行榜"说起。同事们半开玩笑地比拼谁每周用的token最多，直到他们把统计工具挂进自动钩子，每次会话都跑一遍。笔记本电脑开始明显变慢，风扇狂转，体验急转直下。
问题出在ccusage的设计上。每次调用都要重新遍历~/.claude和~/.codex目录，从头解析所有JSONL会话文件，而且是单线程。后来有人用Zig写了个多线程分支，但照样每次重读所有字节，内存占用随输入线性增长。
OpenTelemetry架构更干净，但需要中央收集器，看不到设置之前的历史数据，对"只想看自己token用量"这个需求来说太重了。
Toki的名字是Token Inspector的缩写，也是韩语"兔子"（토끼）的意思。它是一个Rust守护进程，增量索引会话，用嵌入式LSM存储（fjall）作为时序数据库来提供报表。
架构类似Docker：一个守护进程负责摄取，多个客户端读取。启动后通过FSEvents/inotify监听文件变化，report命令即时查询TSDB，trace提供实时事件流，还支持类PromQL的查询语法。
需要说明的是，Toki本身才是ccusage的替代品。toki-monitor（macOS菜单栏应用）和toki-sync（可自托管的同步服务器）是可选的上层组件，不是独立的竞品。
在2GB会话数据集上测试（M1 MacBook Air，每次运行前执行sudo purge），warm query达到1742倍加速。守护进程平时保持静默，只有实际查询时才会感知到它的存在，而查询返回足够快，几乎察觉不到往返延迟。
报表查询的时间复杂度与数据集大小无关——它命中的是TSDB索引，而非源文件。这意味着2GB数据能有1742倍提升，随着历史数据增长，加速比还会继续扩大。
工程精力主要花在JSONL管道上。冷启动用mmap配合Rayon并行遍历会话文件，没有token用量字段的行在serde解析前就被跳过——大部分JSONL行（思考块、纯文本内容）本来就不含用量数据，这一层过滤收益显著。
对于确实包含用量的行，serde解码器配置为跳过除token计数外的所有字符串字段。提示词、响应内容、思考块永远不会被分配内存。隐私保护来自解析器的设计，而非事后政策——这在处理大文件时也是实实在在的速度优势。
热门跟贴