这里算的是你粘贴的内容。真正的 API 调用还会为对话格式本身花掉 token——每则消息的角色标记与分隔符各占几个——再加上你附带的 tool 或 function schema，以及模型自己的回复。把这里的数字当成输入的下限，而不是最终账单。

会，而且差距常常不小。GPT-4o 世代用 o200k_base，GPT-4 与 GPT-3.5 用 cl100k_base；新的词汇表对中日韩文字明显更有效率。Anthropic 与 Llama 使用完全不同的 tokenizer，这也是本工具不提供它们的原因——与其给一个错的数字，不如不给。

取决于是谁在管理这段对话。直接调用 API 会直接失败、回一个 context length 错误。框架与聊天客户端通常会先裁切——最常见的是丢掉最旧的消息，有时会把 system prompt 钉住，有时则改成做摘要。这里的策略切换就是让你用自己的对话看见这几种结果。

没有固定比例，这正是用猜的会出错的原因。常见词常常会合并成一个 token，罕见字则可能要花上好几个，而 o200k_base 在这方面比 cl100k_base 有效率得多。贴一段有代表性的样本再切换编码，看你自己文本上的差异，比套用经验法则可靠。

算。就预算而言它就是一则普通消息，而且很长的 system prompt 会和对话历史抢同一块空间。它唯一特别的地方只在于多数客户端不愿意丢掉它，这正是这里「保留 system」策略在模拟的事——钉住它的代价，是得丢掉更多历史。

不会。编码词汇表会下载到你的浏览器，计算在你机器上的 Web Worker 内完成。没有任何带着你文本的请求、没有记录、也没有任何模型供应商介入——这件事很重要，因为 prompt 里经常夹带凭证与客户资料。