Claude Haiku 5.5 定价暗藏玄机：超 10 万 token 费用暴涨 5 倍

一次对 Claude Haiku 5.5 的 100,000-token 提示词发送 2,000 token 输出的请求费用是 $0.011。只要往提示词里多加一个 token，相同请求的费用就变成 $0.055。什么都没变，只是跨过了一条定价分界线。

Anthropic 于 2026 年 10 月 7 日发布了 Haiku 5.5，截至 10 月 8 日已在 Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundry 和 AWS 上的 Claude Platform 上线，模型 ID 为 claude-haiku-5-5（Bedrock 上为 anthropic.claude-haiku-5-5）。核心看点是价格：每百万输入 token $0.10，而 Haiku 4.5 是 $1。陷阱在于这个低价档位仅限"100,000 token 以内的提示词"，而该模型支持的上下文窗口是这个大小的十倍。Hacker News 上对该发布的讨论在 agent 工作负载能否保持在分界线以下这个问题上来回拉锯，没有定论。于是我们用一个小 Go 程序做了算术。这次运行没有 API key，所以下面没有任何请求发送到模型：价格来自 Anthropic 的文档，成本由其计算得出。

Claude Haiku 5.5 的定价是两套完整的价目表

定价页面给 Haiku 5.5 列了两行，一行"适用于 100,000 token 以内的提示词"，一行"适用于 100,000 token 以上的提示词"。每百万 token 的费率如下：

第二列的每个费率都是第一列的五倍。包括输出 token——这是人们容易忽略的部分：你发送内容的长度决定了返回内容的单价。

这不是所得税那种边际税级，只有超过的部分才按较高税率计征。每条请求选择一个行档，并适用于整个请求。这在当前模型阵容中也是独一份的。对于其他 1M 上下文模型，同一页面明确说明"90 万 token 的请求与 9 千 token 的请求每 token 费率相同"，并指出 Haiku 5.5 是例外。

文档中对"提示词"的定义以及未提及的部分

"提示词"在这张价目表中承载了大量语义，文档并没有将其定义为对用量字段的某种运算公式。以下是文档中明确说明的内容。

启用提示词缓存时，输入被拆分为 input_tokens、cache_creation_input_tokens 和 cache_read_input_tokens。上下文窗口页面对缓存 token 的说明很直白："提示词缓存改变的是你为这些 token 支付的费用，而不是它们是否计入。"所以我们将提示词视为三者之和，这就是那种 100,000 token 缓存前缀加 50 token 问题的组合会落入高价档位的解读方式。这是我们的解读，不是引用自文档的规则。如果你的账单取决于此，请用你知道大小的请求核对一份真实账单。

还有两件事会移动这条分界线。

Haiku 5.5 使用了更新版的 tokenizer，迁移指南称相同文本会"比 Haiku 4.5 多产生约 30% 的 token"。如果你的提示词大小是以 Haiku 4.5 token 计的，那分界线对你来说不是 100,000，而是约 76,900。

而且预检计数是近似值。token 计数端点是免费的，请求体与消息请求相同，但文档称其结果为估算值，"可能有少量差异"。不要用 <= 100000 做判断逻辑。留出余量。

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "claude-haiku-5-5", "messages": [{"role": "user", "content": "..."}]}'

这是文档中的示例请求，换入了模型；我们没有发送它。传入 claude-haiku-5-5 而不是旧模型，否则你会得到旧 tokenizer 的计数。

只差一个 token，用 Go 算价格

计算器是一个函数。它映射 usage 对象，从提示词长度选取一个档位，然后将那个档位应用到所有字段：

type Usage struct {
    InputTokens              int `json:"input_tokens"`
    CacheCreationInputTokens int `json:"cache_creation_input_tokens"`
    CacheReadInputTokens     int `json:"cache_read_input_tokens"`
    OutputTokens             int `json:"output_tokens"`
}

// Rates are US dollars per million tokens.
type Rates struct {
    Input, CacheWrite5m, CacheRead, Output float64
}

var (
    Haiku55Short = Rates{Input: 0.10, CacheWrite5m: 0.125, CacheRead: 0.01, Output: 0.50}
    Haiku55Long  = Rates{Input: 0.50, CacheWrite5m: 0.625, CacheRead: 0.05, Output: 2.50}
    Haiku45      = Rates{Input: 1.00, CacheWrite5m: 1.25, CacheRead: 0.10, Output: 5.00}
)

const Haiku55Threshold = 100_000

func (u Usage) PromptTokens() int {
    return u.InputTokens + u.CacheCreationInputTokens + u.CacheReadInputTokens
}

func (u Usage) at(r Rates) float64 {
    return (float64(u.InputTokens)*r.Input +
        float64(u.CacheCreationInputTokens)*r.CacheWrite5m +
        float64(u.CacheReadInputTokens)*r.CacheRead +
        float64(u.OutputTokens)*r.Output) / 1e6
}

func Haiku55Cost(u Usage) (dollars float64, long bool) {
    if u.PromptTokens() > Haiku55Threshold {
        return u.at(Haiku55Long), true
    }
    return u.at(Haiku55Short), false
}

用它计算两条仅差一个 token 的请求，再计算一条 150,000 token 提示词与相同内容拆成两半（各 1,000 输出 token）的对比：

prompt  100000 + 2000 out  $0.011000  long=false
prompt  100001 + 2000 out  $0.055001  long=true

one request  $0.0775
two requests $0.0160

第二组对比才是有实际意义的。将一份长文档分两次 75,000 token 调用进行摘要，费用是一次调用成本的五分之一，而且你还可以加第三次调用来合并两半，结果仍然远远划算。对于大输入上的提取和分类任务——这正是该模型的卖点——分块处理现在既是质量决策也是定价决策。

Agent 循环在第 17 轮跨过分界线

100,000 token 多吗？对于单次分类调用来说，这是巨大的。但对于一个将每次结果都追加到对话中的工具调用 agent，就不是了。

我们建模了一个启用提示词缓存的循环：8,000 token 的系统提示词和工具定义前缀，每轮追加一个 5,000 token 的工具结果和 500 token 的回复。这些大小是假设的合理值。这是账单模型，你的 agent 会有不同的数字。

turn 16: prompt  95500  $0.00184  long=false
turn 17: prompt 101000  $0.00946  long=true
append only          $0.3267  (first long-tier turn: 17)
compact before 100k  $0.0623  (first long-tier turn: 0, compactions: 2)

第 17 轮的成本是第 16 轮的五倍，而工作几乎相同，而且后续每一轮都保持在高价档位，因为历史记录只会增长。40 轮下来，仅追加的循环费用为 $0.33。第二行是在下一次提示词将跨过 100,000 时用 3,000 token 的摘要替换历史记录，并支付生成该摘要的费用，最终费用为 $0.06。摘要对你的任务来说是否足够好，这是一个价格表无法回答的独立问题。

明显的修复方案中有一个陷阱。API 的阈值压缩功能（处于 beta 阶段，列出支持 Haiku 5.5）会在输入达到触发条件时在服务器端对旧轮次进行摘要。默认触发条件是 150,000 输入 token。在其他所有模型上这是合理的默认值。但在 Haiku 5.5 上，这意味着压缩在价格上涨后 50,000 token 时才启动。自己去设置它；最小值是 50,000：

{
  "model": "claude-haiku-5-5",
  "max_tokens": 4096,
  "context_management": {
    "edits": [
      { "type": "compact_20260112", "trigger": { "type": "input_tokens", "value": 80000 } }
    ]
  },
  "messages": [{ "role": "user", "content": "..." }]
}

该请求体改编自文档示例，配合 anthropic-beta: compact-2026-01-12 请求头。我们也没有发送它。

不要在未先阅读迁移指南的情况下手动修剪历史记录。Haiku 5.5 默认会进行思考（thinking），而发送一个在先前消息改变之后才发回思考块的请求可能返回 400 错误（指南说明了哪些账户会受到该检查）。其指示是保持对话仅追加（append-only），而这恰恰是一个手写的"丢弃最旧的工具结果"的循环所不做的事情。

它在两侧仍然比 Haiku 4.5 便宜

这一切都不意味着 Haiku 5.5 不划算。长档位的每 token 单价是 Haiku 4.5 的一半，是 Sonnet 5.5 $2 输入费率的四分之一。

不过 tokenizer 会侵蚀这部分优势。以 Haiku 5.5 的计数（按文档说法膨胀 30%）对两个模型上的相同文本进行定价：

threshold in Haiku 4.5 tokens: 76923
4.5:  10000 in  $0.0150 | 5.5:  13000 in  $0.0019 long=false | saving 87%
4.5:  50000 in  $0.0550 | 5.5:  65000 in  $0.0072 long=false | saving 87%
4.5:  76000 in  $0.0810 | 5.5:  98800 in  $0.0105 long=false | saving 87%
4.5:  78000 in  $0.0830 | 5.5: 101400 in  $0.0539 long=true  | saving 35%
4.5: 150000 in  $0.1550 | 5.5: 195000 in  $0.1008 long=true  | saving 35%

所以：相同文本在分界线以下是 87% 的节省，在分界线以上是 35% 的节省。Anthropic 的公告称 100,000 token 以内的提示词"约占我们上一个 Haiku 模型请求量的 90%"。这是请求量的比例，而长请求携带的 token 更多，所以你的支出中落在长档位的比例可能远高于十分之一。

这次切换不仅仅是价格变动。手动 budget_tokens thinking、非默认 temperature 和 assistant prefill 在 Haiku 5.5 上都返回 400 错误，与我们对 Claude Sonnet 5.5 列出的变更类似。而且如果你的长提示词之所以长是因为工具定义，先测量那些；它们在每次请求中都会出现。

我们的建议很简短。给任何发送给 Haiku 5.5 的内容设置 90,000 计数 token 的预算，将压缩触发器设置在它以下，并记录每次请求的用量，这样你就能看到有多少次调用超过了。如果一个工作负载无法装入，就拆分它。如果无法拆分，就照常运行，并记住你获得的是那 35% 的折扣。