Claude Haiku 5.5：当「便宜那一档」不再等于妥协

Anthropic 发布了 Claude Haiku 5.5，称其为迄今最便宜、最快、能力最强的小模型。它的目标负载既不性感也不小：摘要、压缩、数据库查询、分类请求。Anthropic 还把它定位为编码工作里与 Opus 5.5、Sonnet 5.5 搭配的子 Agent，并指出它是目前最快的模型，这对实时客服与浏览器操作很重要。定价从每百万输入 token 0.10 美元、每百万输出 token 0.50 美元起，配 100 万 token 上下文窗口与最高 12.8 万输出 token。

按任务路由，而不是按习惯路由

发布了什么

Haiku 5.5 保留了 100 万 token 的上下文窗口——相比 Haiku 4.5 的 20 万上限翻了五倍——并且支持最高 12.8 万输出 token。Anthropic 表示其平均运行成本比 Haiku 4.5 低约 75%。它是首个带可调 effort 设置的 Haiku 级模型，也就是说你可以按「每次调用」而不是按「每个部署」来权衡成本与智力。随同发布，Anthropic 把 Sonnet 5.5 的缓存读取价格减半，称这使 Sonnet 5.5 在大多数 Agent 工作负载上便宜约 20%，并为 Claude Max 与 Team 订阅者推出了每月 API 额度。

# Price the pipeline, not the model. Published list prices for
# Haiku 5.5: $0.10 per 1M input and $0.50 per 1M output for prompts
# up to 100K tokens; long-prompt tier above that; cache reads $0.01.
def monthly_cost(mix, price_in=0.10, price_out=0.50):
    total = 0.0
    for job in mix:
        total += (job['in_tokens'] * price_in + job['out_tokens'] * price_out) / 1e6
    return round(total, 2)

# The number that decides anything is the delta against whatever
# model those jobs run on today, not the sticker price.
def delta(before_usd, after_usd, retries_before=1, retries_after=1):
    return {'before': before_usd, 'after': after_usd, 'saving_pct':
            round((1 - after_usd / before_usd) * 100, 1),
            'retry_penalty': round(retries_after / retries_before, 2)}

像工程师一样读那张基准表

Anthropic 自己的表格对「仍然存在的差距」相当坦白。在评测 Agent 编码能力的 Terminal-Bench 4.0 上，Haiku 5.5 得 39.2%，Sonnet 5.5 是 70.6%。在 OSWorld 2.1 的离线子集（电脑操作）上，它是 72.4%，Sonnet 5.5 是 83.9%。在 Humanity's Last Exam 上它无工具 45.9%、带工具 57.4%，Sonnet 5.5 分别是 56.9% 与 64.5%。知识工作方面，GDPval-AA v2.1 得 1620，AA-Briefcase v1.1 得 1578。规律是一致的：Haiku 5.5 在高并发工作上很强，在最难的 Agent 循环上明显落后。

# The 1M window is the real unlock: it removes the reason to upgrade
# mid-pipeline just to fit the document.
MAX_OUTPUT = 128_000

def route(doc_tokens: int, task: str) -> str:
    if doc_tokens > 1_000_000:
        raise ValueError('chunk it - no model will silently absorb this')
    if task in {'classify', 'summarise', 'compact', 'db_query'}:
        return 'claude-haiku-5-5'          # cheap tier, long context
    if task in {'synthesise', 'judge', 'plan'}:
        return 'claude-opus-5-5'           # pay for judgement
    raise ValueError(f'unclassified task: {task}')

# An unclassified task is a bug in your router, not a reason to
# default to the expensive model. Defaults are where budgets die.

一个重试三次的便宜模型，并不便宜

100 万上下文才是真正的解锁点

降价更上头条，但改变架构的是上下文。团队通常在流水线中途从便宜模型升级到更贵的模型，原因就是文档放不下。100 万 token 加 12.8 万输出，意味着相当大一部分「先检索再推理」的模式可以整条留在便宜档上。这消掉了一次「档位切换」，而档位切换正是延迟、提示词漂移与成本意外出现的地方。不过仍要把 100 万当有限资源：监控截断情况，因为长上下文模型照样会撞墙，而你要在用户发现之前先在图表里看到它。

# Caching changes the arithmetic more than a list-price cut does.
# Cache reads are an order of magnitude cheaper than fresh input.
def effective_input_rate(cache_read_tokens, fresh_tokens,
                         read_rate=0.01, fresh_rate=0.10):
    blended = (cache_read_tokens * read_rate + fresh_tokens * fresh_rate) / 1e6
    return {'blended_input_usd': round(blended, 6),
            'cache_hit_rate': round(cache_read_tokens / max(cache_read_tokens + fresh_tokens, 1), 3)}

# If cache_hit_rate is flat while traffic grows, you have a stable
# prefix problem, not a model problem. Fix the prompt layout first.

该量的是「每个完成任务的成本」

任何止步于「每百万 token 多少钱」的对比，量的都是错的东西。真正重要的是一个「真的完成了」的任务花了多少钱。一个失败后重试三次的模型，可能比一次成功的贵模型更贵，而且它还烧掉了用户能感知到的等待时间。拿你自己仓库里的十个真实任务、在同一套 harness 里做对比，把通过率、p95 延迟、重试率和花销一起记下来。Anthropic 的客户就是用这些口径描述的：Asana 称任务完成的延迟降低超过 30%、每个 Agent 回合的推理速度最多快 2.5 倍；Box 称在约一半延迟下比 Haiku 4.5 高 11 分。

# Benchmark on your own tasks. Anthropic publishes benchmark numbers;
# you need numbers for YOUR distribution.
import statistics, time

def run_suite(model, tasks, call, retries=3):
    lat, ok, attempts = [], 0, 0
    for t in tasks:
        for _ in range(retries):
            attempts += 1
            t0 = time.perf_counter()
            r = call(model, t)
            lat.append(time.perf_counter() - t0)
            if r.ok:
                ok += 1
                break
    lat.sort()
    return {'pass_rate': round(ok / len(tasks), 3),
            'p50_s': round(statistics.median(lat), 2),
            'p95_s': round(lat[int(len(lat) * 0.95) - 1], 2),
            'retry_rate': round((attempts - ok) / attempts, 3)}

# p95, not the mean. Averages hide the calls your users complain about.

量「每个完成任务的成本」，而不是每个 token 的单价

可调 effort 是一个路由维度

在这次发布之前，effort 实际上是你通过「选模型」来间接选定的东西。Haiku 5.5 的可调 effort 把它变成一个「每次调用」的参数，也就是说你的路由器多了一个轴。分类与抽取可以跑低 effort，摘要与查询用中等，真正困难的推理用高。陷阱在于：一次评测翻车之后就把全局调高——这正是「75% 的节省」悄悄变成「20% 的节省」的方式，而且通常没人会注意到，直到账单来了。应该按任务类型、对着你自己的通过率去调 effort，并且在任务分布变化时重新校准。

# Adjustable effort is the new dial. Treat it as a routing dimension
# you tune per task, not as a global setting you set once.
def effort_for(task, budget_ms, observed_ms):
    if task in {'classify', 'extract'}:
        return 'low'        # cheapest, still accurate on short work
    if task in {'summarise', 'db_query'}:
        return 'medium'
    return 'high' if observed_ms > budget_ms else 'medium'

# Tune effort against YOUR pass rate. Turning it up everywhere is
# how a 75% saving quietly becomes a 20% saving.

真正该怎么迁移

先做一份带成本的清单：今天跑了哪些流水线、量有多大、其中高并发重复性工作占多少。挑一条流水线先动，迁移前后都测通过率和 p95，然后再决定。在怪模型之前先修提示词结构，因为缓存命中率主要取决于你的「稳定前缀」是否真的稳定——而现在，悄悄搞错它的成本比以前更低。从第一天起就把回退到旧模型的路铺好，记录每个请求由哪个模型服务，并把 effort 设置放进配置而不是代码里，这样你不用发版就能改。