Opus 4.6 的 Effort 参数怎么用才省钱：low 到 max 实战分档

Opus 4.6 引入了一个不起眼但很实用的参数：effort。四个档位——low、medium、high、max——控制模型在回答时"用多大力气"。

这不是什么花哨的功能。它直接影响三个东西：输出 token 数量、思考 token 数量、工具调用次数。换句话说，它直接影响你的账单。

effort 到底控制什么

先说清楚：effort 不是一个硬性的 token 上限。它是一个行为信号，告诉模型"这个任务大概要花多少精力"。

设成 low，模型会尽量少说、少想、少调工具。设成 max，模型会不遗余力——更长的推理链、更多的工具调用、更详细的输出。

具体表现：

effort	思考行为	工具调用	输出长度	适合场景
low	简单问题跳过思考	尽量少调，合并操作	简短直接	分类、提取、子 Agent
medium	适度思考	按需调用	中等	平衡速度和质量的 Agent 任务
high（默认）	几乎总是深度思考	充分调用	详细	复杂编码、推理、分析
max	无上限深度思考	不限制	最详尽	最难的问题，只在 4.6 上可用

一个有意思的点：effort 会影响所有 token，不只是思考 token。low effort 下，模型连工具调用都会精简——比如本来要分三步查三个文件，low effort 下它可能合并成一步查，或者直接跳过不太关键的那次查询。

怎么用

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=4096,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "检查这段代码有没有安全漏洞"}]
)

effort 跟 adaptive thinking 配合使用效果最好。adaptive thinking 让模型自己决定"要不要想"，effort 在更高层面决定"总体花多大力气"。

如果你不设 effort，默认是 high。大部分开发者可能一直在用 high 而不自知。

真实的省钱效果

我拿一个场景做了粗略测试：给模型一段 Python 代码（约 200 行），让它做 code review。

effort	思考 token	输出 token	工具调用次数	回答质量
low	0（跳过思考）	~300	0	能指出明显 bug，漏掉细节
medium	~2000	~800	1	主要问题都覆盖，建议够用
high	~5000	~1500	2	详细分析，包含改进建议和代码示例
max	~12000	~2500	4	极度详尽，连命名风格都给你改

按 $5/$25 的输入/输出价格粗算：high effort 一次 review 约 $0.04，low effort 约 $0.008。差了 5 倍。

如果你每天跑 1000 次 review，high 是 $40/天，low 是 $8/天。一个月差 $960。

当然，质量也差了。关键是找到你的任务对应的"够用"档位。

几个实用的分档策略

策略一：按任务类型固定 effort

最简单的方式。提前按任务分好：

• 分类、路由、简单提取 → low
• 摘要、翻译、一般对话 → medium
• 代码生成、复杂分析、debug → high
• 关键决策、安全审查、考试题 → max

策略二：动态 effort

更精细的做法。先用 low 跑一遍，如果结果不满足质量标准（比如置信度低、输出太短、缺少关键信息），自动升级到 medium 或 high 重试。

def smart_query(prompt, messages):
    # 先试 low
    response = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=4096,
        thinking={"type": "adaptive"},
        output_config={"effort": "low"},
        messages=messages
    )
    
    # 检查输出质量（你自己定义）
    if needs_more_effort(response):
        response = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=8192,
            thinking={"type": "adaptive"},
            output_config={"effort": "high"},
            messages=messages
        )
    
    return response

重试会多花一次请求的钱，但如果 80% 的请求在 low 就能搞定，总成本还是会下降。

策略三：主 Agent + 子 Agent 分级

如果你的系统有多个 Agent 协作（比如一个规划 Agent + 多个执行 Agent），可以给不同角色设不同的 effort。

主 Agent 用 high 或 max，因为它负责规划和决策，错了代价大。子 Agent 用 low 或 medium，因为它们的任务通常更明确、更可验证。

Anthropic 在 effort 的文档里也提到了这一点：低 effort 特别适合 subagent 场景。

Overthinking 问题

CNET 的报道里提到一个有意思的细节：Opus 4.6 有时候会"想太多"。默认 high effort 下，模型对简单问题也可能花很长时间推理，产生大量思考 token。

Anthropic 的建议是：如果发现延迟太高或成本异常，先把 effort 从 high 降到 medium 试试。

从 API 响应的 usage 字段可以看到思考 token 的消耗。如果一个简单查询产生了上万的思考 token，说明 effort 设高了。

effort 与 budget_tokens 的关系

如果你之前用的是 thinking: {"type": "enabled", "budget_tokens": 32000}，现在建议换成 adaptive thinking + effort。

对应关系大致是：

• budget_tokens 小（8000 以下）≈ low/medium
• budget_tokens 中（8000-32000）≈ high
• budget_tokens 大（32000+）≈ max

但不完全等价。effort 影响的范围更广——它不只控制思考，还控制输出和工具调用。budget_tokens 只限制思考部分。

旧写法在 4.6 上还能用，但已经标记为弃用。下个模型可能就删了。

监控建议

上了 effort 之后，建议加两个监控：

按 effort 级别统计平均 token 消耗。如果 low effort 的平均输出 token 突然涨了，可能是某类请求的复杂度超过了 low 的能力范围，模型在"挣扎"。

监控 stop_reason: max_tokens 的比率。high 和 max effort 下，模型可能产生大量 token，导致撞到 max_tokens 上限。如果这个比率超过 5%，要么提高 max_tokens，要么降低 effort。