估算一段文本在 GPT-4o、Claude、DeepSeek、Qwen、GLM 下的 token 消耗与上下文占比，同时给出字符数、字节数与中英文占比。给区间而不是假装精确，价格可改，文本不上传。
token 不是统一的单位。每个厂商用自己训练出来的 BPE 词表把文本切成子词，同一段中文在 GPT 的词表里可能是 1.4 个字一个 token，在 Claude 的词表里可能是 1.5 个字一个，在 DeepSeek 这种中文语料占比高的模型上又会更省。
要给出精确值，就得把各家几 MB 到十几 MB 的词表全部打包进页面——那是几十兆的下载量，为了一个数字不值得。所以本工具用按字符类别加权的经验模型估算，并**总是给一个 ±15% 的区间**。
这个区间的用法是：判断「这段文案会不会超上下文」「一次批量调用大概多少成本」。如果要在代码里做硬性截断，请用厂商官方 tokenizer 或接口返回的 usage 字段，不要用这里的估算值去卡边界。
英文常见词在词表里是完整的一个 token，所以「4 个字符 ≈ 1 token」大体成立。中文没有空格分词，词表里既有单字也有双字词，实测下来常见区间是每 1–1.7 个汉字消耗 1 个 token。
这直接决定了中文 prompt 的成本感知：同样「意思差不多」的一段话，中文的字符数少，但 token 数不一定少。做多语言 prompt 对比时，按字符数估成本会低估中文那一边。
标点和空格的消耗容易被忽略：连续的标点、换行、Markdown 符号都会各自占 token。一份排版精致的 prompt 常比纯文本多出 10%–20% 的 token，这部分的钱花在了格式上。
每个模型有一个上下文窗口（例如 128k、200k token），输入加输出都要塞进这个窗口。本工具按你选中的模型算出「这段文本占窗口的百分之几」，超过 100% 会明确标红，而不是给你一个看起来很正常的数字。
要注意输入与输出是共享窗口的：如果你的文本已经占了 90%，那留给模型回答的空间只剩 10%。真要跑长文摘要这类任务，把输入控制在窗口的 60% 以内比较稳。
成本 = token 数 ÷ 1,000,000 × 单价。这里只算**输入价**，因为输出价通常是输入价的 2–4 倍，且输出长度无法预估——猜一个数字出来只会误导。
单价可以改。厂商调价很频繁，把价格写死在代码里，过几个月就变成一份没人知道已经过期的成本表。你自己填当前公示价，比任何内置表格都准。
还有一个常被忽略的成本来源：如果每次调用都重复发送同一段长系统提示，那部分钱按次数线性叠加。把系统提示的 token 数乘以预计调用次数，才是真实支出。
文本只在浏览器里参与计算：不发送请求、不写 localStorage、刷新即消失。这一点对粘贴内部文档、客户资料尤其重要。
硬上限 2MB（约 70 万字），超过会提示分段统计。这个量级下浏览器处理仍是毫秒级，但再大就没意义了——没有哪个模型的上下文能装下。
不能。本工具给的是 ±15% 的估算区间，用的是按字符类别加权的经验模型，不是厂商真实词表。要卡接口限制，请用厂商官方 tokenizer，或以接口返回的 usage.total_tokens 为准。这里的数字适合判断量级与估成本，不适合做边界判定。
因为各家词表不同。词表决定了哪些字符串被当成一个整体：如果某个中文双字词在词表里是独立单元，它就占 1 个 token；如果只能拆成两个字，就占 2 个。中文语料占比高的模型（如 DeepSeek、Qwen）通常会为常见中文词单独留位置，所以更省。
没有固定答案，常见区间是每 1–1.7 个汉字 1 个 token。粗略记「一个汉字约 0.7 个 token」够用了。原文书或新闻这类规范中文大约 1.3–1.5 字/token，代码与表格里的中文因为夹杂符号会更费。
输出长度无法预知，凭感觉填一个平均值会得到一个看起来精确、实际无意义的数字。想知道输出成本，用接口返回的 completion_tokens 乘输出单价自己算。本工具只负责把输入这部分算准。
2MB（约 70 万字）以内是毫秒级，做了防抖。超过 2MB 会明确拒绝并建议分段——继续处理下去浏览器会卡，而那个量级早已超过所有模型的上下文窗口，算出来也没用。
都不会。全部计算在本地完成，不发请求、不写 localStorage、不记录历史。关掉页面内容就没了，这是刻意的。