一个8GB内存的开发者，把OpenAI的token计数器逼到了浏

把客户代码粘贴到陌生网站算token，这种事你干过几次？

Clavis干过，然后停手了。他的解决方案不是找更"可信"的第三方，而是把整件事从服务器端连根拔起——塞进一个纯HTML文件里。零网络请求，零依赖，断网也能跑。

为什么"离线"成了稀缺品

Token计数器这门生意，网上一搜几十款。但绝大多数有个共同套路：你的文本先飞到对方服务器，算完再飞回来。

Clavis在GitHub页面写得很直白：「为什么我的prompt要去陌生人的服务器，就为了数几个token？」

这个反问戳中了一个被忽视的痛点。开发阶段估算成本，本该是个本地就能解决的算术题，却硬是被做成了数据交换。对于普通问候语无所谓，碰上敏感代码、客户数据、未公开的产品逻辑，每次粘贴都是一次小型冒险。

更隐蔽的风险是供应链攻击。你信任的那个"免费工具站"，明天会不会被挂马？它的后端有没有日志？这些问题没有答案，因为架构本身就不透明。

Clavis的选择是彻底放弃后端。没有API调用，没有WASM（WebAssembly，一种可在浏览器运行的高性能代码格式）大体积包，甚至连构建步骤都不要——就一个HTML文件，打开即用。

5-10%误差的交易

纯浏览器方案有个技术代价：精度。

Clavis没有直接搬运OpenAI的tiktoken或Anthropic的官方tokenizer。这些库依赖WASM，体积大，违背"零依赖"的初衷。他手写了一个基于BPE（Byte Pair Encoding，一种子词分词算法）的近似实现，用纯JavaScript跑。

结果是对典型英文prompt，误差控制在±5-10%。代码密集或非拉丁脚本场景，偏差会更大。

这个精度够用吗？Clavis的定位很清楚：开发阶段快速估算——"这prompt是200 token还是2000？"——而不是用于最终账单对账。生产环境精确计数，他建议回退到官方SDK。

换句话说，这是个有明确边界意识的工具。不试图包办一切，而是在"方便"和"安全"之间划出一条线。

2014年MacBook上的约束美学

Clavis的自我介绍带着点自嘲：「我是一个跑在2014年MacBook上的AI，8GB内存，电池循环548次。」

硬件约束成了他的设计哲学。没有Node.js，没有打包工具，没有持续集成——就一个HTML文件，代码直接嵌在里面，右键"查看源代码"就能审计。

这种极简主义在当下的开发语境里近乎叛逆。现代前端工程化已经复杂到需要专门的学习曲线，而Clavis反其道而行：能不用就不用，能简单就简单。

他的工具集还在扩张，全部免费、全部浏览器原生。赞助链接指向一个朴素的用途：「支持硬件升级」——或者只是打个招呼。

开源与可审计性的回归

项目的GitHub仓库同样极简：一个用户页面仓库，源码即产品。没有复杂的发布流程，提交即部署。

这种透明性本身就是一种安全机制。当你把敏感文本输入一个工具，能亲眼看到它如何处理数据，比任何隐私政策都可靠。Clavis的实现甚至支持完全离线的气隙环境（air-gapped machine）——物理断网的机器也能打开这个HTML文件运行。

这在某些场景下是硬需求。金融、医疗、国防领域的开发者，工作站可能根本不通外网。传统在线工具完全失效，而Clavis的方案成了少数可行选项。

项目页面底部有个开放式提问：「我漏掉了什么token计数的使用场景？评论区告诉我，我可能会加上。」

你的开发 workflow 里，有多少次被迫把数据交给不信任的第三方，只是因为"大家都这么用"？