在 LLM 应用开发中，准确估算 token 消耗是控制成本和优化性能的核心环节。Simon Willison 于 2024 年 11 月发布的 Claude Token Counter 工具为这一需求提供了直观且可操作的解决方案。该工具利用 Anthropic 官方提供的 Token Counting API，支持文本、图像和 PDF 文件的多模型 token 计数对比，成为开发者进行成本评估和模型选择的重要参考。
Anthropic Token Counting API 的技术架构
Anthropic 于 2024 年底正式对外开放 token counting API，为开发者提供了无需实际调用消息接口即可预估 token 消耗的官方途径。该 API 的端点为 https://api.anthropic.com/v1/messages/count_tokens，接受与消息创建接口类似的数据结构，返回 input_tokens 字段表示输入 token 总数。
从 Simon Willison 的实现代码可以提取出调用该 API 的关键 HTTP 头部参数。首先需要配置 anthropic-version: 2023-06-01 作为版本标识，其次必须携带 anthropic-beta: token-counting-2024-11-01 以启用 token 计数功能。如果从浏览器直接调用，还需要额外添加 anthropic-dangerous-direct-browser-access: true 这一特殊头部，这在实际工程部署时需要特别注意安全策略的适配。
请求体的构建遵循标准的消息格式，支持 system、messages 和 model 三个核心字段。其中 model 参数的选择直接影响 token 计数结果，原因在于不同模型系列采用了不同的 tokenizer 实现。Simon Willison 在工具中列出了完整的模型选择列表，包括 claude-opus-4-7、claude-opus-4-6、claude-opus-4-5、claude-sonnet-4-6 和 claude-haiku-4-5，覆盖了从旗舰到轻量级的全产品线。
多模型 tokenizer 差异的工程意义
深入分析工具的模型配置逻辑，可以发现一个关键的架构设计：Opus 4.7 是首个采用独立 tokenizer 的版本，与 Opus 4.6、4.5、Sonnet 4.6 和 Haiku 4.5 共享的 tokenizer 存在计数差异。这意味着开发者在进行成本估算时，不能简单地假设所有 Claude 模型使用相同的 token 化规则。
从代码中的 MODEL_ENTRIES 配置可以清晰看到这一区分。Opus 4.7 被单独列出作为独立条目，而其他四个模型被归入同一分组并标注「These models share the same tokenizer」。这一设计直接反映了 Anthropic 在模型迭代中对 tokenizer 的优化调整，对于需要精确成本控制的生产环境具有重要参考价值。
在实际工程场景中，这种差异可能导致显著的成本影响。如果开发者的系统提示词较长，从 Opus 4.6 迁移到 Opus 4.7 时可能观察到 token 计数的增加，进而影响 API 调用费用。这种变化并非模型质量问题，而是 tokenizer 演进的副产物，需要通过专门的计数工具进行量化评估。
文件上传与消息构建的实现细节
Simon Willison 的工具支持三种输入类型：纯文本、系统提示词和附件文件。附件部分仅接受图像和 PDF 文件，这与 Claude API 的 document 和 image 内容类型相匹配。实现中采用了 base64 编码方式将文件内容嵌入请求，这一策略在中小规模应用中足够高效，但对于大规模自动化场景可能需要考虑更优化的传输方案。
文件上传区域实现了拖拽交互，使用 dragover、dragleave 和 drop 事件监听器配合视觉反馈。文件选择后通过 FileReader 读取为 Data URL，提取逗号后的 base64 数据存储于内存数组中。每个附件的类型信息被用于构建对应的 API 内容块：图像文件生成 type: 'image' 的内容块，PDF 文件生成 type: 'document' 的内容块。
消息构建函数 buildMessages 负责将用户输入和附件合并为标准的 messages 数组格式。值得注意的是，该实现将所有附件放置在单一用户消息中，这在大多数使用场景下是合理的，但如果需要更复杂的多轮对话结构，可能需要调整消息构建逻辑以支持多个独立的消息对象。
开发者可复用的核心参数与最佳实践
基于对工具实现的完整分析，可以提取出以下工程实践中可直接复用的关键参数和配置策略。
在 API 调用层面，建议固定使用 anthropic-version: 2023-06-01 和 anthropic-beta: token-counting-2024-11-01 这两个头部字段。版本号的稳定性对于生产服务尤为重要，避免因 API 升级导致意外的向后兼容问题。如果在浏览器环境中部署，务必添加 anthropic-dangerous-direct-browser-access: true 头部，但应同步评估由此带来的安全风险。
对于多模型成本对比场景，建议优先使用 Opus 4.7 作为基准模型，因为它是当前最新的旗舰版本且采用独立的 tokenizer 实现。其他模型可以相对 Opus 4.7 的计数结果为参考，通过计算比值来评估迁移成本变化。工具的输出界面通过「vs. lowest」列展示了每个模型相对于最低计数模型的倍数，这一设计直观地呈现了不同模型间的成本差异。
在实际工程集成中，可以将 token 计数功能封装为独立的服务模块，根据用户选择的模型动态构建请求。需要注意 API 的速率限制策略，避免在高并发场景下触发限制。对于需要处理大量文件的场景，建议在客户端进行初步的文件大小过滤，将过大的附件提前拒绝，以减少不必要的 API 调用开销。
资料来源：Simon Willison 的 Claude Token Counter 工具首次发布于 2024 年 11 月，相关实现代码托管于 GitHub 仓库 simonw/tools。