跑之前先把账算出来

公式

公式只有一条，对这里每一个文本模型都成立：消费者价 = 官方每 token 单价 × 该模型的 rateMultiplier，输入和输出分开算，此外不掺任何东西。

拿几个走一遍。Claude Sonnet 5 官方每百万输入 3 美元、输出 15 美元，倍率 0.1，你付 $0.30/M 和 $1.50/M；Claude Opus 5 官方 $5 和 $25，同样 0.1 倍，就是 $0.50/M 和 $2.50/M；GPT 5.6 Luna 官方 $0.2 和 $1.2，倍率 0.3，算下来 $0.06/M 和 $0.36/M。

要注意倍率是按模型定的，不是全站一个数：31 个模型里 18 个是 0.1 倍，Gemini 3.8 Flash 和 GPT 6 Astra Stable 是 0.2 倍，GPT 5.6 Luna 是 0.3 倍，所有 stable-* 的 Claude 通道是 0.4 倍，最低的 Grok Composer 2.5 Fast 是 0.05 倍，最高的两个 Grok Imagine 图像 id 是 1 倍。看你实际调用的那个。

export TOKEN_SHARE_KEY="<your-pool-api-key>"

# Estimate: requests x tokens x consumer rate per million.
# claude-sonnet-5: 0.1x of $3/M in and $15/M out => $0.30 and $1.50.
awk 'BEGIN {
  reqs = 5000; in_tok = 4000; out_tok = 600
  cin  = reqs * in_tok  / 1000000 * 0.30
  cout = reqs * out_tok / 1000000 * 1.50
  printf "input  $%.2f\noutput $%.2f\ntotal  $%.2f\n", cin, cout, cin + cout
}'

# Then measure one real request: the usage object is what you are billed on.
curl -sS https://token-share.app/v1/messages \
  -H "x-api-key: $TOKEN_SHARE_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "<one representative prompt>"}]
  }' | jq '.usage'

有两类根本不按 token 算

图像可以按张收费。grok-imagine-image 每张 $0.01，grok-imagine-image-quality 每张 $0.04，两者倍率都是 1——就是官方价，没有折扣。出 5000 张分别是 50 美元和 200 美元，任何请求参数都改不了。

gpt-image-2 是图像里的异类：它是 0.1 倍率，但按网关回报的 token 计费，输入 $0.50/M、输出 $3.00/M。因为 token 数随你要的尺寸和质量变化，它的「每张成本」只能在你自己的参数下量出来，查不到现成的。

视频按生成的秒数收费。grok-imagine-video-1.5 是 0.1 倍率，作用在每秒 480p $0.08、720p $0.14、1080p $0.25 上，你付的是每秒 $0.008、$0.014、$0.025。一条 8 秒 720p 是 8 × $0.014 = 0.112 美元，一百条就是 11.20 美元。

任务形状比价目表更要紧

把价目表变成预测，只需要两个数：每次请求的平均输入 token 和平均输出 token。只看单价就估，是差出一个数量级的常见原因——不同工作负载对输入和输出的权重完全不同。

在 Claude Sonnet 5（$0.30/M 和 $1.50/M）上比三种形状。摘要类：进 2 万、出 500，0.0060 + 0.00075 = 0.00675 美元。对话类：进 2000、出 800，0.0006 + 0.0012 = 0.0018 美元，输出主导。起草类：进 500、出 4000，0.00015 + 0.0060 = 0.00615 美元，几乎全是输出。

最容易掉的坑在多轮：agent 或者聊天循环每一轮都要把整段对话重发一次，输入 token 一次次重新计费。要估的是跨轮的累计量，不是最后那次请求有多大。

先估，再量

usage 是每个响应都会带的东西，那个数字才是计费依据，也是唯一权威。按字符数估算，用来量负载大小没问题，用来对账就是错的。

实操上是这样一个循环：先按公式估，跑二十个有代表性的请求，把回报的 token 和你的假设对一对，调整之后再放大到两万个。二十个请求时估错 40% 不痛不痒，同样的偏差放到生产量级，就是「预算」和「惊吓」的区别。

之后还有两件事会改变估算。提示词缓存会改变重复前缀的计价方式——那通常是输入密集型任务里最大的一项。换 id 则只是同一形态内改一个字段（Claude 走 /v1/messages，OpenAI 走 /v1/responses，Grok 和 Gemini 走 /v1/chat/completions），所以在第二个候选上重新量一遍，便宜到可以当成常规动作。

常见问题