비용과 지능의 최적화

워크로드가 프로토타입에서 프로덕션으로 이동하면 비용은 최우선 설계 제약 조건이 됩니다. 가장 유능한 모델은 대규모에서 너무 비쌀 수 있고, 가장 저렴한 모델은 품질이 부족할 수 있습니다. 비용을 잘 관리한다는 것은 각 비용 레버가 출력 품질에 어떤 영향을 미치는지 이해하는 것을 의미합니다. 어떤 레버는 품질과 맞바꾸고 어떤 레버는 그렇지 않기 때문입니다. Claude Platform은 그 트레이드오프를 직접 제어할 수 있게 해 줍니다. 각 요청에 대해 모델, effort 수준, 아키텍처를 선택할 수 있으므로 워크로드를 비용-지능 프런티어의 거의 어느 지점에나 배치할 수 있습니다.

레버는 두 종류로 나뉩니다:

• 무료 이득(Free wins)은 품질을 건드리지 않고 지출을 줄입니다: "prompt caching"(프롬프트 캐싱), 토큰 위생, 실행 중인 모델에 대한 프롬프트 감사, 최대 24시간까지 기다릴 수 있는 작업에 대한 50% 할인 배치 처리, 그리고 최후의 안전장치로서의 워크스페이스 지출 한도.
• 트레이드오프(Tradeoffs)는 비용과 지능을 교환합니다: 모델 선택, effort, 출력 상한 및 작업 예산, 멀티 모델 아키텍처.

각 레버에는 측정 결과와 언제 효과가 있는지에 대한 규칙이 함께 제공됩니다. Anthropic의 측정에서 프롬프트 캐싱은 큰 차이로 가장 큰 레버였습니다. 이 가이드의 벤치마크에서 에이전트 루프 비용을 2.5배에서 3.7배까지 줄였고, 소규모 트리아지 에이전트의 청구액을 83%, 입력 트리밍을 추가하면 88% 줄였습니다. 멀티 모델 레버는 범위가 더 좁습니다. 두 번째 모델은 어드바이저와 오케스트레이터라는 두 가지 형태에서 효과가 있었습니다.



여기서 시작하세요

자신의 상황을 행에 맞춰 보세요.

이 결과는 Anthropic 내부 결과(참조된 벤치마크)이며 방향성을 제시할 뿐 보장이 아니므로, 4단계 방법으로 자신의 워크로드에서 측정하세요.



품질 손실 없이 지출 줄이기

프롬프트 캐싱, 토큰 위생, 배치 처리, 현재 모델에 대한 프롬프트 감사는 모두 출력 품질을 낮추지 않고 지불 금액을 낮춥니다. 두 가지 주의 사항이 있습니다. 배치 처리는 할인을 위해 지연 시간을 맞바꾸며, 토큰 위생 레버인 컨텍스트 편집은 이 섹션에서 측정된 실행에서 절약한 것보다 더 많은 비용이 들었습니다.



반복되는 컨텍스트 캐싱

다른 어떤 레버보다 먼저 프롬프트 캐싱을 켜세요. 에이전트 작업의 모든 턴은 점점 커지는 전체 대화, 즉 시스템 프롬프트, 도구 정의, 모든 이전 턴을 다시 전송하기 때문입니다. 40턴 작업은 첫 번째 턴을 40번 전송하므로 작업 비용은 대략 턴 수의 제곱에 비례하여 증가합니다. 캐싱은 재전송을 막지는 않지만 각 재전송 비용이 약 10분의 1이 되고 더 빠르게 처리됩니다. 접두사는 입력 가격의 10분의 1인 캐시 읽기 요율로 청구되고, 각 턴은 새로운 부분에 대해서만 1.25배의 캐시 쓰기 요율을 지불합니다.

Anthropic의 측정된 실행 전반에서 캐시 읽기는 일상적으로 작업 비용의 가장 큰 단일 구성 요소이며, 이는 캐싱이 대부분의 모델 선택 결정보다 더 가치 있게 만듭니다. Anthropic은 WideSearch¹ 및 DeepResearch Bench II⁷ 실행을 캐싱 유무에 따라 가격을 매겼습니다:

캐시의 기본 수명은 5분이고 에이전트 루프의 턴은 몇 초 간격이므로 할인은 모든 턴에서 대부분의 토큰에 적용됩니다. 차트의 실행은 81%에서 90%의 적중률을 달성했습니다. 짧은 루프는 덜 다시 읽기 때문에 절약은 에피소드 깊이에 따라 달라지지만, 캐싱은 측정된 모든 모델과 벤치마크에서 가장 큰 단일 레버로 유지되었습니다.

루프가 턴 사이에 사람을 기다린다면 1시간 캐시 지속 시간을 사용하세요. 쓰기 비용이 더 들지만(입력 가격의 1.25배 대신 2배) 첫 번째로 방지된 미스에서 그 값을 합니다. 미스는 전체 접두사를 정가로 재전송하고 다시 쓰기 때문입니다.

설정에는 작업이 거의 필요하지 않습니다. 자동 캐싱이 중단점을 대신 배치해 줍니다. 그렇지 않으면 Claude Code와 함께 제공되는 Claude API 스킬이 하나의 프롬프트로 기존 통합에 캐싱을 추가할 수 있습니다. 다음 발췌문은 스킬이 이 측정을 생성한 하네스에 캐싱을 추가하는 것을 보여 줍니다:

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

이러한 중단점 배치는 명시적 캐시 중단점의 표준 패턴을 따릅니다.

세 가지 설정이 작업 중에 캐시를 깨뜨릴 수 있습니다. 요청 사이에 effort를 변경하면 캐시된 접두사가 무효화되므로, 컴팩션 경계와 같이 어차피 다시 캐시할 곳에서만 변경하세요. 작업 예산을 중간에 변경하는 것도 마찬가지이므로 첫 번째 요청에서 한 번만 설정하세요. 모든 컨텍스트 편집 패스는 지우는 지점부터 접두사를 무효화하고 다음 요청은 그 이후의 모든 것을 다시 캐시하는 비용을 지불하므로, 작은 배치를 여러 번 지우기보다 큰 배치를 몇 번 지우세요. 세 가지 변경 모두 자연스러운 중단 지점에서 수행한 다음 캐시 읽기가 떨어지지 않았는지 확인하세요. 떨어졌다면 캐시 진단이 접두사가 어디서 갈라졌는지 보여 줍니다.



입력 및 컨텍스트 토큰 트리밍

대부분의 에이전트 요청은 답변에 전혀 영향을 미치지 않는 토큰을 담고 있습니다. 이를 트리밍하는 것은 출력 품질에 아무런 비용이 들지 않지만, 여기의 모든 레버가 측정 시 비용을 절약한 것은 아닙니다. 살펴볼 두 곳:

• 입력 트리밍. 웹 페치 도구의 동적 필터링은 가져온 페이지에서 상용구를 제외하고, 이미지 크기 조정은 비전 입력의 크기를 적절히 맞추며, 지연 로딩을 사용한 도구 검색은 필요할 때만 도구 정의를 로드합니다. 프로그래매틱 도구 호출은 Claude가 코드에서 여러 도구 호출을 실행하여 필터링된 결과만 컨텍스트에 들어가게 합니다. 해당 문서는 에이전트 검색 벤치마크에서 입력 토큰이 24% 줄고 점수는 더 높았다고 보고합니다. 도구 컨텍스트 관리는 도구 검색, 프로그래매틱 도구 호출, 프롬프트 캐싱, 컨텍스트 편집을 비교합니다.
• 컨텍스트 수명 주기. 컨텍스트 편집은 오래된 도구 결과를 지우고, 임계값이 있는 자동 컴팩션은 긴 루프가 전체 기록을 계속 끌고 가는 것을 막습니다.

레버들은 캐시 및 서로와 상호작용하므로 순효과로 판단하고, 캐시 진단을 사용하여 캐시된 접두사가 각 변경 후에도 살아남는지 확인하세요. Anthropic은 공개 저장소의 스크린샷이 포함된 실제 버그 리포트 20개를 처리하는 이슈 트리아지 에이전트에 대해 레버를 하나씩 켰습니다(두 번째 패널의 경우 같은 작업의 더 긴 변형):

캐싱이 거의 모든 일을 했고 트리밍이 총계를 88%로 끌어올렸습니다. 각 막대는 하나의 실행이므로 $0.10의 차이는 노이즈입니다. 여기에 표시된 것은 그렇지 않습니다. 컴팩션은 이를 트리거할 만큼 충분히 긴 세션이 필요합니다. 20개 이슈 실행은 입력이 트리밍된 후 50,000토큰 하한에 도달하지 못했지만, 두 번째 패널의 더 긴 변형에서는 한 번 발동하여 청구액을 추가로 38% 줄였습니다.

컨텍스트 편집은 여기서 무료가 아닌 유일한 레버입니다. 모든 지우기 패스는 캐시된 대화를 다시 쓰며, 이는 프롬프트 캐싱에 역행합니다. 이 실행에서 컨텍스트 편집은 절약한 것보다 더 많은 비용이 들었습니다. 컨텍스트 윈도우에 공간을 만들기 위해 사용하고, 큰 배치로 몇 번만 지우세요.



기다릴 수 있는 작업 배치 처리

Batch API는 결과가 24시간 이내 언제든 도착하는 대신 캐시된 토큰을 포함한 요청의 모든 토큰에서 50%를 할인합니다. 아무도 기다리지 않는 모든 요청을 배치로 라우팅하고 나머지는 대화형 경로를 유지하세요. 배치 처리는 무인 에이전트 작업, 즉 평가 실행, 백필, 토큰 트리밍 측정의 이슈 트리아지 에이전트를 반복 실행하는 것과 같은 예약 작업에 대해 캐싱 다음으로 두 번째로 큰 무료 레버입니다. 이 페이지의 대화형성을 제외한 모든 것과 결합되지만, 설계상 대화형인 Claude Managed Agents 세션에서는 사용할 수 없습니다(Claude Managed Agents 가격 참조).



현재 모델에 대한 프롬프트 감사

각 모델 세대는 프롬프트에 다르게 반응하므로 프롬프트에는 더 이상 사용하지 않는 모델을 위해 작성된 텍스트가 쌓입니다. 일반적인 경우는 이전 모델을 보완하기 위해 추가된 지나치게 구체적인 지시입니다. "두 번 검증하라", "최대한 철저하게", 필수 단계별 절차, 또는 직접 만든 추론 스크래치패드 등입니다. 최신 모델은 이를 문자 그대로 따라 추가 도구 라운드와 추가 작성을 생성하므로 정확도 향상 없이 청구액이 올라갑니다. 지금 실행하는 모델에 대해 프롬프트를 감사하고, 모델을 변경할 때마다 다시 감사하는 것은 무료 이득입니다.

감사는 하나의 명령입니다. Claude Code와 함께 제공되는 Claude API 스킬에는 프로젝트의 프롬프트와 요청 코드를 읽고 다른 모델을 위해 작성된 것을 보고하는 prompt-audit 명령이 있습니다. 이 축약된 발췌문은 해당 패턴이 포함된 지원 데스크 프롬프트와 요청 코드에 대해 실행한 것을 보여 줍니다:

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

그런 다음 명령은 편집 내용을 diff로 제안하고(하나의 헝크 표시) 의도적으로 그대로 둔 것, 즉 환불 기간, 어조 요구 사항, 품질 기준을 나열합니다. 재작성이 아닌 패치를 검토하게 됩니다.

효과는 측정 가능합니다. 지원 데스크 평가¹⁴에서 Claude Opus 4.8을 위해 작성된 프롬프트는 Claude Opus 5에서 정확도 변화 없이 티켓당 36% 더 많은 비용이 들었습니다. 같은 프롬프트에 감사를 실행하자 Opus 5는 감사하지 않은 버전보다 더 저렴해졌고(14%) 더 정확해졌습니다(티켓의 97%, 92%에서 상승, 노이즈 범위 밖의 향상). Claude Sonnet 4.6에서 Claude Sonnet 5로의 마이그레이션에서 감사는 같은 정확도에서 14%를 절감했습니다:

두 종류의 오래된 텍스트는 비용이 다릅니다. 새 모델이 너무 문자 그대로 따르는 지시는 돈이 듭니다. "두 번 검증하라"를 제거하자 Opus 5의 티켓당 비용이 3분의 1 줄었고, "최대한 철저하게"를 제거하자 거의 그만큼 줄었습니다. 더 이상 모델에 맞지 않는 텍스트는 대신 정확도를 희생시킵니다. 종료된 사고 설정, 모순되는 규칙, 모델 자체의 사고와 충돌하는 직접 만든 스크래치패드는 각각 제거했을 때 Opus 5에서 7~11포인트를 회복시켰습니다:

같은 패턴이 도구 설명과 스킬에도 나타나며, 거기서도 제거할 가치가 있습니다.



비용과 지능 맞바꾸기

이 레버들은 단일 모델이 비용과 지능 사이 어디에 위치할지를 설정합니다. 모델 선택, effort, 더 높은 설정에서 실패 재실행, 그리고 그 안에서 작동하는 예산과 상한입니다. 현재 모델에서 effort 스윕으로 시작하세요(effort 조정). 비용과 능력이 가장 낮은 것부터 가장 높은 것까지 현재 모델은 Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5, Claude Fable 5(프런티어 모델)입니다. 모델 개요에 전체 라인업과 가격이 있습니다.



작업당 비용으로 모델 비교

가격표는 토큰당으로 작성되며, 토큰당으로 보면 프런티어 모델은 비싸 보입니다. Claude Fable 5의 토큰당 가격은 Claude Sonnet 5의 몇 배입니다. 하지만 지불하는 것은 완료된 작업이므로 완료된 작업당 비용으로 모델을 비교하세요. 더 유능한 모델은 더 적은 작업으로 작업을 끝냅니다. 더 적은 턴, 더 적은 검색, 자체 컨텍스트의 더 적은 재읽기, 더 적은 되돌아가기입니다. 토큰당 프리미엄은 모든 것을 덜 함으로써 일상적으로 압도됩니다.

Anthropic은 모델을 구분할 만큼 충분히 어려운 연구 보고서 벤치마크인 DeepResearch Bench II⁷에서 이를 직접 측정했습니다:

low effort의 프런티어 모델은 토큰당 격차에도 불구하고 중간 티어 모델보다 더 정확하고 작업당 약 10% 더 저렴했습니다. 하지만 항상 이기는 것은 아닙니다. 두 모델이 대부분 포화시키고 점수가 공개 리더보드와 비교할 수 없는 이 페이지의 SWE-bench Pro³ 하위 집합에서 Claude Opus 5 단독은 약 60%의 비용으로 Claude Fable 5 단독과 일치했습니다(91.7% 대 91.3%, 실행 간 노이즈 범위 내). DeepResearch Bench II 작업과 같은 더 어려운 작업에서는 Fable의 우위가 다시 나타납니다.

대부분의 에이전트 워크로드에서는 Claude Opus 5로 시작하세요. 토큰당 비용이 Fable 5의 절반이고 Sonnet 5의 2.5배이며, 해당 코딩 하위 집합에서 Fable의 정확도와 일치했습니다. 반대쪽 끝에서 Claude Haiku 4.5는 GPQA Diamond⁹ 질문에 Opus 5의 질문당 비용의 약 10분의 1로 답했으며, 정확도는 Opus의 92%에 비해 63%였고, 긴 코딩 작업에서는 훨씬 더 뒤처졌습니다. 긴 에이전트 루프가 아닌 확인 가능한 출력이 있는 대량 작업에 적합합니다.

순위는 워크로드에 따라 뒤집히며, 어떤 가격표도 어느 쪽인지 알려 주지 않습니다. Claude Opus 5와 낮춘 effort의 프런티어 모델을 포함하여 모든 후보를 자신의 트래픽에서 완료된 작업당 비용으로 가격을 매기세요.

중앙값이 아닌 워크로드의 꼬리에 가격을 매기세요. 일반적인 작업이 아닌 가장 어려운 10분의 1 작업에서 모델을 비교하세요. 일반적인 작업에서는 모든 모델이 비슷해 보이고 가장 저렴한 것이 가장 좋아 보이지만, 청구액은 더 저렴한 모델이 실패하는 작업에 의해 결정됩니다. 실패한 작업도 여전히 토큰을 청구하고, 그다음 재시도, 그다음 실패가 다운스트림에서 초래하는 비용이 청구되기 때문입니다. 꼬리는 아무것도 실패하지 않을 때에도 돈이 가는 곳입니다. 20문제 WideSearch¹ 실행에서 두 문제가 지출의 43%를 차지했습니다:

멀티 모델 전략은 나머지에 프런티어 요율을 지불하지 않고 그 꼬리에 프런티어 지능을 쓰기 위해 존재합니다.



effort 조정

effort는 모델을 작업에 맞게 조정하는 가장 직접적인 방법입니다. effort 매개변수는 모델이 얼마나 많은 사고, 도구 호출, 자체 검증을 하는지를 제어하며, 기본값(high)은 까다로운 작업에 적합합니다. 비용은 그 모든 활동에 따라 증가하고, 정확도는 작업에 필요한 부분에 따라서만 증가합니다. 모델의 한계 아래에서 가장 높은 effort 수준은 작업이 결코 사용하지 않는 깊이에 대해 지불합니다.

연구 및 지식 작업 벤치마크(WideSearch¹, DeepWideSearch⁶, BrowseComp⁴, GDPval², 모두 Claude Fable 5 사용)에서 비용 대비 정확도 곡선은 거의 평평합니다. low는 작업당 비용의 3분의 1에서 절반을 절감하면서 1~3포인트를 포기했고, medium은 기본값 비용의 70%~85%로 기본값의 정확도와 일치했으며, 기본값은 네 가지 중 어느 것에서도 medium보다 측정 가능한 것을 사지 못했습니다. DeepWideSearch에서 low는 Claude Sonnet 5 워커가 있는 오케스트레이터와도 20% 낮은 비용으로 일치했습니다. effort를 낮추는 것이 아키텍처 변경을 이겼습니다.

낮은 설정은 더 빠르기도 하며, 이는 지연 시간이 제약일 때 중요합니다. 이 실행에서 low는 DeepWideSearch에서 문제당 4.5분이 걸렸고, 기본값에서는 7.9분이 걸렸습니다. 입력이 어떤 단일 컨텍스트 윈도우에도 맞지 않는 코퍼스 벤치마크에서 Fable 5는 low, medium, 기본값에서 에피소드당 7.9, 9.1, 11.4시간이 걸렸습니다.

장기 코딩은 다른 형태입니다. SWE-bench Pro³에서 Claude Opus 5는 medium에서 절반의 비용으로 약 2포인트를, low에서 4분의 1의 비용으로 약 8포인트를 포기했습니다. 실제 트레이드오프이며, 더 높은 effort에서 실패 재실행이 이를 다시 절약으로 바꿉니다. 이 차트는 연구 및 지식 작업 벤치마크와 SWE-bench Pro에 대해 비용 대비 정확도를 표시합니다:

두 가지 결과가 따릅니다. 첫째, 두 번째 모델을 추가하기 전에 자신의 워크로드에 대해 이 곡선을 그리세요. 이 내부 측정에서 기본 단일 모델보다 저렴해 보였던 멀티 모델 구성은 같은 모델을 낮은 effort로 실행한 것보다 비용이 더 들었습니다. 둘째, 이 곡선은 모든 멀티 모델 전략이 이겨야 하는 단일 모델 기준선이므로, 자신의 워크로드에서 측정하기의 2단계는 effort 수준 전반에 걸쳐 기준선을 잡습니다.

낮은 effort는 정확도가 진정으로 추론 깊이에 따라 증가하는, 모델의 한계에 도달하는 워크로드에서는 정확도를 희생시킵니다. 각 보고서가 하위 주제별 깊은 추론에 보상을 주는 DeepResearch Bench II⁷에서 모든 effort 단계는 약 2.4포인트의 루브릭 점수를 샀습니다. 그 곡선에는 무료 비용 절감이 없습니다:

작업 설명만으로는 어떤 종류의 워크로드인지 드러나지 않으므로, 자신의 트래픽 샘플에서 두세 가지 effort 수준을 스윕하고 곡선에서 답을 읽으세요. 각 수준을 별도의 세션에서 테스트하세요. 세션 중간에 effort를 변경하면 캐시가 무효화되고(반복되는 컨텍스트 캐싱 참조) 비교가 왜곡됩니다. 매개변수 세부 사항은 Effort를 참조하세요.



더 높은 effort에서 실패 재실행

작업의 결과를 확인할 수 있을 때 effort 곡선에서 가장 저렴한 정책은 고정 설정이 아닙니다. 모든 작업을 낮은 설정으로 실행하고 실패한 것만 더 높은 설정으로 재실행하세요.

Anthropic은 effort 조정의 SWE-bench Pro³ 하위 집합에 대한 effort 실행에서 이 정책을 작업별로 계산했습니다. low의 Claude Opus 5에서 작업의 16%가 실패했습니다. 이를 기본값으로 재실행하자 약 93%가 각각 약 $0.70에 통과했으며, 모든 것을 기본값으로 실행하면 $1.39에 91.7%였습니다. 실패한 저렴한 시도를 포함해도 절반의 비용으로 같은 통과율입니다. 대신 medium에서 시작하면 약 $0.95에 약 94%를 해결했습니다. 작은 향상의 대부분은 두 번째 시도입니다(기본값 자체의 실패를 기본값으로 재실행하면 더 많은 돈으로 거의 같은 점수를 냅니다). 따라서 이 정책은 향상이 아닌 절약을 위해 사용하세요:

두 가지 조건이 적용됩니다. 첫째, 실패 신호가 필요합니다(여기서는 벤치마크 자체의 테스트). 나쁜 작업을 통과시키는 검사기는 그 실패를 통과시킵니다. 둘째, 모든 첫 번째 패스 실패는 두 번의 실행에 해당하는 실제 시간이 걸리므로 절약은 실패에 대한 지연 시간으로 지불됩니다.



예산 및 출력 상한 설정

대부분의 에이전트 작업 실행은 저렴하지만, 소수는 검색, 재검증, 과도한 테스트에 중앙값 비용의 몇 배를 씁니다. 작업 예산은 그 꼬리를 겨냥합니다. 모델은 전체 작업에 대한 실시간 토큰 카운트다운을 보고 스스로 조절하여 가치가 낮은 검색을 줄이고, 중복 검증을 건너뛰고, 소용돌이치는 대신 마무리합니다.

Anthropic은 예산이 조여짐에 따라 Claude Fable 5로 SWE-bench Pro³에서 통과율과 작업당 비용을 측정했습니다:

넉넉한 예산은 18% 비용 절감을 위해 약 2.7포인트의 통과율을 포기했고, 허용된 가장 빡빡한 예산은 47% 절감을 위해 4.4포인트를 포기했습니다. 여기서 예산은 정확도가 아닌 효율성을 샀습니다.

세 가지 제어는 세 가지 다른 일을 합니다. 작업 예산은 모델이 보기 때문에 돈을 절약합니다. max_tokens는 아무것도 절약하지 않는 안전 상한입니다. Claude Managed Agents에서 세션 예산은 둘 뒤에 있는 하드 달러 정지입니다. 세 가지 모두 설정하세요. 작업 예산, 높은 max_tokens, 청구서에 절대 올리고 싶지 않은 실행을 위한 세션 상한, 그리고 최후의 안전장치로 워크스페이스 지출 한도입니다.

• 작업 예산은 Claude Opus 5, Claude Fable 5, Claude Opus 4.8, Claude Opus 4.7에서 베타(베타 헤더 task-budgets-2026-03-13)이지만 Claude Sonnet 5에서는 아닙니다. 먼저 지원 표를 확인하세요. 루프의 90번째 백분위수 토큰 사용량 근처에서 시작한 다음 조이세요(예산 선택에서 그 분포를 수집하는 방법을 보여 줍니다). 현재 20,000토큰 하한 미만의 예산은 거부되며, 매우 빡빡한 예산은 거부와 유사한 동작을 생성할 수 있습니다. 작업 중간 변경은 캐시를 무효화하므로 첫 번째 요청에서 한 번만 예산을 설정하세요. 예산은 권고적이며 모델을 멈추는 것이 아니라 조종하므로 자신의 워크로드에서 준수 여부를 확인하세요.
• max_tokens는 모델에게 보이지 않게 단일 응답을 제한하므로 낮춰도 모델이 절약하게 만들지 않습니다. 공간이 필요했던 턴은 버려지고 여전히 청구됩니다. 내부 저장소 작업 벤치마크¹²에서 16,384토큰 상한은 Claude Opus 5 시도의 15%와 Claude Fable 5 시도의 3분의 1을 끝냈으며, 그중 해결된 것은 없었습니다. 상한이 있는 실행은 시도당 덜 썼지만 비례적으로 더 적은 해결을 샀으므로 해결된 작업당 비용은 64,000에서와 같았습니다. 그 설정에서는 아무것도 잘리지 않았고, Fable은 두 실행 모두 채점한 문제에서 36.6% 대신 54.6%의 작업을 해결했습니다(참조 12에 설명된 SWE-bench Pro³ 하위 집합의 별도 컷에서는 90% 대신 92%). 상한에 걸린 시도를 재시도하는 것은 비용만 추가합니다. 같은 상한에서는 결코 성공하지 못했고, 더 높은 상한에서는 낭비된 시도에 대해서도 지불합니다. 에이전트 작업에는 max_tokens를 64,000으로 설정하고(xhigh 또는 max effort에서는 최대값인 128,000), 그렇게 큰 응답은 스트리밍하고, stop_reason: max_tokens를 실패로 취급하고, 모델이 볼 수 있는 effort와 작업 예산으로 돈을 절약하세요.
• Claude Managed Agents의 세션 예산은 하드 정지입니다. 세션 예산은 토큰, 검색, 세션 시간에 대한 정가 기준으로 한 세션에 대한 달러 상한입니다. 상한에서 세션은 stop_reason: budget_reached로 일시 중지되며, 예산을 올리면 재개됩니다. 플랫폼에서 강제되며, 정가가 있는 모든 모델(Claude Sonnet 5 포함)에서 작동하고, 권고적 작업 예산과 결합됩니다. 배포는 같은 필드를 모든 실행에 적용합니다.

두 개의 max_tokens 차트 중 첫 번째는 각 상한에서 시도당 및 해결된 작업당 비용을 표시합니다:

두 번째는 상한 대비 턴당 출력 길이를 표시합니다:



모델 결합

멀티 모델 아키텍처는 작업 복잡도가 충분히 다양하여 서로 다른 단계가 서로 다른 모델로 가장 잘 처리되는 워크로드에 적합합니다. 트래픽이 더 작은 모델이 안정적으로 처리하는 일상적인 작업과 프런티어 능력이 필요한 더 어려운 단계를 섞고 있을 때, 작업을 분할하면 대부분의 토큰이 더 작은 모델 요율로 청구되면서 중요한 곳에 프런티어 지능을 유지합니다. 난이도가 균일하거나 하나의 종속 체인이어서 워크로드에 그런 혼합이 없을 때는 잘 조정된 단일 모델이 보통 더 나은 선택입니다. 각 전략 섹션은 두 경우를 구분하는 규칙을 제공합니다.

두 가지 전략이 대부분의 워크로드를 커버하며, 어떤 모델이 메인 루프를 잡는지에서 다릅니다:



어드바이저 전략: 어려운 결정을 상위로 넘기기

"advisor strategy"(어드바이저 전략)에서는 비용이 낮은 실행자(executor) 모델이 에이전트 루프를 실행하고 대부분의 턴을 수행합니다. 접근 방식을 선택하거나 실패에서 복구하는 것처럼 더 깊은 판단이 필요한 결정에 부딪히면, 더 높은 지능의 어드바이저(advisor) 모델을 호출해 전략적 지침을 받은 뒤 계속 진행합니다. 대부분의 토큰은 실행자 요금으로 청구되고, 가끔 있는 자문만 어드바이저 요금으로 청구됩니다.

이를 사용하려면 요청에 어드바이저 도구를 추가하세요. 이 베타 기능은 전체 전략을 하나의 /v1/messages 요청 안에서 서버 측으로 실행합니다. 실행자가 도구 호출을 내보내면 Anthropic이 어드바이저 추론을 실행하고, 실행자는 그 조언을 받아 계속 진행합니다. 오케스트레이션 코드를 작성할 필요가 없습니다. Claude Managed Agents에서는 에이전트의 multiagent 명단에 advisor 항목을 추가하여 세션에 어드바이저를 부여하세요. 세션의 기본 스레드가 같은 방식으로 어드바이저에게 자문합니다. Claude Code도 이를 지원합니다. 어드바이저 도구로 어려운 결정을 상위로 넘기기를 참조하세요.

성과를 결정하는 요소. 어드바이저는 실행자의 호출을 통해서만 작업을 보므로, 두 가지가 어드바이저가 얼마나 도움이 되는지를 결정합니다.

첫 번째는 모델 간의 격차입니다. 어드바이저는 실행자에게 없는 역량만 넘겨줄 수 있습니다. GPQA Diamond⁹에서 Claude Haiku 4.5 실행자는 Claude Opus 5 어드바이저로부터 큰 이득을 얻었고, Claude Sonnet 5 실행자는 몇 점을 얻었으며, 프런티어 실행자는 거의 아무것도 얻지 못했습니다.

두 번째이자 취약한 요소는 실행자가 실제로 묻는지 여부(자문율, consult rate)입니다. 낮은 effort의 실행자는 자신이 막혔다는 것을 알아차리지 못하게 될 수 있습니다. 기본 effort에서 대부분의 작업에 대해 자문하던 조합이 effort를 낮추면 거의 자문하지 않게 될 수 있고, 그러면 실행자 단독보다 낮은 점수를 받습니다. 자문율은 작업에 따라서도 달라집니다. DeepSWE¹⁰에서 낮은 effort의 Sonnet 5 실행자는 계속 물었고 23점을 얻었지만, SWE-bench Pro³에서는 같은 실행자가 묻기를 멈췄습니다. 실행자가 실제로 물을 때는 대부분의 격차를 따라잡습니다. 다음 차트의 조합들 전반에서 어드바이저는 더 강한 모델과의 격차 중 60%에서 90%를 메웠고, 그 모델에 대한 비용은 자문에 대해서만 지불되었습니다. 이것이 비용 측면의 사례를 가능하게 합니다.

자문율은 프롬프트에 반응합니다. 도구의 내장 설명만으로는 실행자가 특히 코딩 작업에서 호출을 덜 하므로, 어드바이저 도구 문서는 본격적인 작업 전에 한 번, 마무리 전에 한 번 호출하도록 요청하는 시스템 프롬프트를 제공하며, 이는 작업당 약 두세 번의 호출에 해당합니다. 다음에 측정된 코딩 조합은 그 빈도로, 모든 작업에서 약 두 번의 자문으로 실행되었습니다. 해당 페이지는 호출을 덜 하는 실행자를 유도하는 방법과 비용을 제한하기 위해 클라이언트 측에서 호출 수를 제한하는 방법도 다룹니다. 따라서 자문율을 주시하세요. 프롬프트로 유도하고, 측정하고, 자문율이 무너지면 실행자의 effort를 복원하세요.

비용 면에서 이득이 되는 경우. 어드바이저 요금으로 청구되는 몇 번의 짧은 자문이 작업 전체에 어드바이저의 모델을 실행하는 것을 대체할 때 어드바이저는 비용을 절감합니다. 이는 어드바이저의 모델 가격이 실행자보다 훨씬 높을 때 가장 잘 작동하므로, 가장 비용 효율적인 구성은 중간 티어 실행자 위에 프런티어 어드바이저를 두는 것입니다. 조언이 실행자 토큰도 절약하기 때문에 조합은 범위의 최상단에서도 제 몫을 할 수 있습니다. 올바른 접근 방식을 전달받은 실행자는 막다른 길을 덜 탐색하며, 이것이 자문 비용을 상쇄할 수 있습니다.

일반 API 에이전트로 실행한 내부 에이전틱 코딩 벤치마크¹¹에서, Claude Fable 5 어드바이저를 둔 Claude Opus 5 실행자는 측정된 구성 중 가장 정확했습니다. 시도당 $8.40에 시도의 85.7%를 해결했습니다. 이는 각 모델 자체의 effort 설정을 잇는 선 위에 있지만, 그중 최고치(기본 설정의 Opus 단독, $8.50에 84.4%, 그리고 medium의 Fable 단독, $8.20에 83.4%)보다 1~2점 높을 뿐이며, 단일 실행으로는 이를 노이즈와 구분할 수 없습니다. medium effort의 Fable 단독은 거의 같은 비용(시도당 $8.20 대 $8.40)으로 조합과 거의 같은 정확도(83.4% 대 85.7%)에 도달합니다.

Claude Code의 어드바이저 모드를 통한 이전 측정도 같은 순서를 보였습니다. 이 결과를 절감이 아니라 여러분의 워크로드에서 테스트할 형태로 읽으세요. 범위의 최상단에서 어드바이저는 프런티어 가격으로 약간의 정확도를 사며, 비용 측면의 사례는 다음의 차트 읽기 사례처럼 역량 격차가 더 넓은 조합에 해당합니다. 지연 시간 비용은 자문 자체입니다. 이 벤치마크에서는 작업당 약 두 번의 추가 프런티어 모델 호출이며, 각각 작업의 임계 경로에 있습니다.

effort를 올리는 대신 이득이 되는 경우. 역량 격차가 더 넓고 워크로드의 정확도가 effort에 반응하는 경우, 어드바이저에게 자문하는 낮은 effort의 실행자는 실행자 자체의 effort를 올리는 것보다 더 저렴한 상향 단계가 될 수 있습니다. 어드바이저는 필요한 작업에 대해서만 비용이 지불되기 때문입니다.

Claude Managed Agents에서 그 어드바이저와 함께 실행한 공개 차트 읽기 벤치마크인 Chartography¹³에서, Claude Fable 5 어드바이저를 둔 low effort의 Claude Opus 5 실행자는 작업당 $0.60에 67.5점을 기록했습니다. 이는 어느 모델 자체의 effort 설정을 잇는 선보다도 위에 있습니다(Opus 단독은 low와 medium 사이에서 $0.38에서 $0.94로 49점에서 75점으로 올랐습니다). 다만 실행자 자체의 medium 및 기본 설정이 여전히 최고 점수를 보유하며, 가격은 1.6배와 3.3배입니다.

낮은 effort의 실행자는 작업의 86%에서 어드바이저에게 자문했으며, 이는 SWE-bench Pro 조합이 충족하지 못한 조건입니다. 이 구성에 의존하기 전에 여러분의 에이전트 루프에서 자문율을 측정하세요.

어떤 조합이든, 먼저 낮은 effort에서 어드바이저의 모델 단독 가격을 산정하세요. 그것이 넘어야 할 기준선입니다. 모델 릴리스마다 다시 확인하세요. 릴리스는 역량 격차와 가격 비율을 모두 움직이기 때문입니다.

적합한 경우. 어드바이저 전략은 턴이 대부분 기계적이지만 훌륭한 계획이 중요한 워크로드에 적합합니다. 코딩 에이전트, 컴퓨터 사용, 다단계 리서치 파이프라인 등입니다. 모든 턴이 진정으로 프런티어 역량을 필요로 할 때, 계획할 것이 없을 때(단일 턴 Q&A), 또는 실행자가 이미 어드바이저의 역량에 가까울 때는 잘 맞지 않습니다.



오케스트레이터 전략: 대량 작업 위임하기

"orchestrator strategy"(오케스트레이터 전략)에서는 프런티어 모델이 루프를 쥡니다. 작업을 분해하고, 하위 작업을 비용이 낮은 워커(worker) 모델에 배분하고, 그 결과를 병합합니다. 토큰이 많이 드는 탐색을 워커가 흡수하므로 오케스트레이터 자체의 트랜스크립트는 짧게 유지되며, 따라서 대부분의 토큰은 워커 요금으로 청구되면서도 계획과 종합은 여전히 프런티어 모델에서 나옵니다.

이를 구축하려면 Claude Managed Agents의 멀티에이전트 오케스트레이션을 사용하세요. 코디네이터 에이전트(오케스트레이터)와 각자 고유한 모델을 가진 워커 에이전트 명단을 구성합니다. Claude Fable 5 코디네이터와 Claude Sonnet 5 워커를 사용한 완전한 작동 예제는 Claude Cookbook 레시피 코디네이터 패턴: 계획에는 큰 모델, 실행에는 작은 모델을 참조하세요.

이 패턴은 워커가 병렬로 실행될 수 있을 때 실제 경과 시간을 절약합니다. 코퍼스 벤치마크⁸에서 코디네이터가 플랫폼의 문서화된 한도인 동시 워커 25개를 실행했을 때 한 에피소드는 2시간 조금 넘게 걸렸고, 단독 실행은 11.4시간이었습니다. 비용을 절감한 것은 측정된 두 가지 상황에서뿐이었습니다. 단일 모델이 혼자 처리할 수 있는 작업에서는 같은 모델을 더 낮은 effort로 쓰는 것이 매번 더 저렴했습니다.

사례 1: 일상적 작업의 비용 꼬리에 대한 보험. 단독으로 실행되는 프런티어 모델은 평소라면 해결할 일상적 문제에서 가끔 헛돌기도 합니다. 어떤 것이 그럴지 미리 알 수 없기 때문에, 그런 몇 번의 실행이 청구서를 지배합니다. 일상적 작업을 비용이 낮은 워커에게 넘기는 코디네이터는 그 꼬리를 제한합니다. 이제 헛도는 일이 있어도 워커 요금으로 발생하기 때문입니다.

Anthropic은 이를 BrowseComp⁴의 의도적으로 쉬운 부분(단독 모델이 안정적으로 해결하는 10개 문제, 위임 실행 50회와 단독 실행 70회)에서 측정했습니다. Claude Sonnet 5 워커 하나를 둔 Claude Fable 5 코디네이터는 평균적으로 Fable 단독의 절반 조금 못 미치는 비용이 들었고, 90번째 백분위수에서는 약 3분의 1($12 대 $33)이었으며, 단독 모델의 가장 비싼 단일 실행은 $84였고 답도 틀렸습니다.

위임은 작업 중 일상적이고 평소 해결 가능한 부분에서 이득이 되었으며, 이는 워커가 어려운 문제를 위한 것이라는 직관과 반대입니다. 전체의 더 어려운 BrowseComp 세트에서는 경제성이 역전되었습니다. 여러분의 트래픽이 일상적 작업에서 긴 비용 꼬리를 가진다면, 이것이 가장 먼저 측정할 오케스트레이터 사례입니다.

사례 2: 하나의 컨텍스트 윈도우보다 큰 작업. 단독 모델은 그렇게 큰 입력을 한 번에 하나의 "context window"(컨텍스트 윈도우)씩 순차적으로 처리해야 하며, 매 패스마다 자신의 상태를 다시 읽는 비용을 지불합니다. 워커는 각자 자신의 파티션을 병렬로, 워커 요금으로 읽습니다. 읽기가 많지만 여전히 하나의 컨텍스트 윈도우에 들어가는 작업은 위임 문제가 아니라 모델 선택 문제입니다. 읽기 비용만 놓고 보면, 오케스트레이터는 어떤 단일 컨텍스트도 작업을 담을 수 없을 때만 앞섭니다.

Anthropic은 이 사례를 위한 벤치마크를 구축했습니다⁸. 130개의 심어진 결함이 있는 14개 공개 Python 패키지로 이루어진 2,160만 토큰 코퍼스로, 어떤 컨텍스트 윈도우에도 너무 큽니다. 청구서가 코퍼스 읽기 자체이기 때문에 effort를 낮추는 것은 도움이 되지 않습니다. Claude Fable 5 단독은 모든 effort 설정에서 에피소드당 $720에서 $764가 들었고, 정확도만 움직였습니다. 코디네이터 구성은 그 어떤 설정보다도 60% 이상 적게 들었고 medium 또는 기본 설정의 Fable보다 2~6점 낮았으며, Claude Sonnet 5 단독 기준선은 확실히 이겼습니다.

토큰 회계가 그 이유를 보여줍니다. 두 청구서 모두 대부분 캐시에서 제공된 코퍼스 읽기입니다. 코디네이터 구성은 에피소드당 약 5억 7천만 개의 캐시된 토큰을 읽었는데, 이는 단독 모델의 약 2억 개의 거의 세 배이면서도 비용은 절반 미만이었습니다. 그 읽기가 Claude Fable 5가 아닌 Claude Sonnet 5의 캐시 읽기 요금으로 청구되었기 때문입니다. 기본 effort의 Fable 5는 코디네이터 구성 비용의 2.8배로 여전히 최고 정확도를 보유하므로, 여기서 위임은 정확도의 전부가 아니라 대부분을 삽니다.

위임이 이득이 되지 않는 경우. 오케스트레이터는 넘길 대량 작업이 있을 때만 무언가를 삽니다. 많은 독립적인 조각, 이상적으로는 하나의 컨텍스트 윈도우에 담기에 너무 많은 조각입니다. 작업이 하나의 종속적 사슬이거나 단일 컨텍스트에 들어갈 때, 오케스트레이터는 단일 모델이 공짜로 얻는 계획, 인계, 병합에 비용을 지불합니다. 측정된 그런 모든 사례에서 코디네이터의 모델을 더 낮은 effort로 단독 사용하는 것이 앞섰습니다.

BrowseComp⁴는 하나의 벤치마크 안에서 그 경계를 보여줍니다. 위임은 일상적 부분에서 이득이 되었고 전체의 더 어려운 세트에서는 졌는데, 거기서는 프런티어 모델 단독이 22%에서 30% 낮은 비용으로 코디네이터 구성의 정확도에 도달했습니다. 독립적인 외부 연구도 같은 패턴을 보고합니다⁵. 작업이 하나의 사슬이거나, 긴 비용 꼬리 없이 하나의 컨텍스트에 들어가거나, 더 낮은 effort의 단일 모델이 이미 여러분의 기준을 충족한다면, 오케스트레이터를 구축하지 마세요.



전략 간 선택하기

대부분의 경우는 하나의 질문으로 귀결됩니다. 작업이 독립적인 조각으로 나뉘는가, 아니면 종속적 단계의 사슬을 통해 도달하는 하나의 답인가? 전략 표는 두 가지 답을 두 가지 전략에 매핑합니다.

확신이 없다면 아직 아무것도 구축하지 마세요.

1. 먼저 현재 모델에서 effort를 스윕하세요. 이 페이지에서 가장 저렴한 실험이며, 대부분의 워크로드는 거기서 끝납니다.
2. 스윕이 격차를 보여준다면, 더 강한 모델 단독을 낮은 effort에서 가격 산정하세요. 그것이 어드바이저 조합이 넘어야 할 숫자이며, 이 페이지에서 그것을 넘은 조합은 실행자가 실제로 자문한 조합이었습니다.

이 페이지의 멀티 모델 결과는 더 낮은 effort의 같은 모델, 그리고 단독으로 실행되는 한 단계 아래 모델과 비교하여 판단되었습니다. 그것이 여러분 자신의 워크로드에서 실행할 비교이며, 첫 단계가 effort 스윕인 이유입니다.

어드바이저를 추가할 때, 그것은 재설계가 아니라 도구 정의입니다.



자신의 워크로드에서 측정하기

이 페이지의 숫자는 2026년 7월과 8월의 것으로 당시 정가 기준이며, 모델과 가격이 바뀌면서 변동할 것입니다. 여러분의 상위 이관율, 작업이 얼마나 깔끔하게 나뉘는지, 트랜스크립트 길이도 이를 움직입니다. 방법은 동일하게 유지됩니다.

1. 프로덕션 로그에서 실제 트래픽처럼 가중치를 둔 몇 개의 작업을 뽑고, 각각에 대해 결과 검사를 작성하세요. 테스트 통과, 티켓 종료, 행 수 정확 등입니다. 점수 옆에 작업당 비용을 기록하세요. 각 응답의 usage에 있는 네 가지 토큰 수를 각자의 요금으로 가격 산정하고 작업의 요청 전체에 걸쳐 합산합니다(Usage and Cost API가 집계를 보고합니다).
2. 기본값만이 아니라 effort 수준 전반에 걸쳐 모델 티어의 기준선을 잡고, 지출 대비 점수를 그리세요. 멀티 모델 구성은 단일 모델의 전체 곡선을 이겨야 합니다.
3. 곡선이 effort로 메울 수 없는 격차를 보여준다면, 맞는 멀티 모델 전략을 추가하고 스위트를 다시 실행하세요.
4. 전환 전에 트래픽 일부에서 승자를 섀도로 실행한 다음, 스위트를 계속 실행하세요.

다음 예제는 Claude Opus 5의 정가로 한 요청의 1단계 비용을 계산합니다.

# 가격 페이지의 백만 토큰당 가격입니다. 다른 모델을 사용하려면 이 두 값을 변경하세요.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # 캐시 쓰기는 입력 가격의 1.25배(5분 캐시), 캐시 읽기는 0.1배로 청구됩니다.
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

에이전트 루프에서는 캐시 읽기 항이 보통 네 가지 중 가장 큽니다. 그렇지 않다면 캐싱이 작동하고 있는지 확인하세요. 어드바이저 도구 또는 컴팩션이 활성화되어 있으면 일부 토큰은 최상위 합계가 아닌 usage.iterations에만 보고되므로, 대신 usage.iterations에 걸쳐 합산하고 advisor_message 항목은 어드바이저 모델의 요금으로 가격 산정하세요.

다음 표는 시도할 순서대로 레버를 나열합니다.



참조된 벤치마크

모든 측정은 이 벤치마크들에 대한 Anthropic 내부 실행입니다. 별도 언급이 없으면 비용은 2026년 8월 정가 기준 USD이며, Claude Sonnet 5 수치는 입력 및 출력 토큰 백만 개당 $2와 $10을 사용합니다. "notional USD"로 표시된 차트는 청구서를 보고하는 대신 각 요청의 토큰 수를 해당 요금으로 가격 산정합니다.

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. 여러 행으로 된 표의 완전성과 정확성으로 채점되는 광범위한 웹 리서치 작업, 200개 문제, 구성당 3회 실행. 캐싱 차트와 effort 차트는 별도 실행에서 나왔으므로 문제당 비용이 약간 다릅니다. 비용 집중 차트는 별도의 20개 문제 실행으로, 문제당 3회 실행, 요청별 청구 기록에서 비용 산정.
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. 작업 루브릭에 따라 채점되는 지식 작업 산출물, 공개된 골드 세트의 210개 작업 실행, 작업당 1회 시도. Claude 모델이 채점하므로 절대 점수는 발표된 결과와 다를 수 있습니다.
3. SWE-bench Pro: Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025. Anthropic의 평가 하네스와의 호환성을 위해 선택된 482개 문제 하위 집합, 점수는 공개 리더보드와 비교할 수 없습니다. 기본 effort의 Claude Opus 5는 두 번 실행의 평균이며, 감소된 effort 설정은 단일 실행입니다. 상위 이관 수치는 그 실행들에서 작업별로 나옵니다. low 먼저, 그다음 그 실패에 대해 기본 설정은 실행 조합 전반에서 약 $0.70에 92.5%~93.6% 해결, medium 먼저는 약 $0.95에 93.8%~94.2%, 기본 설정을 자체 실패에 재실행은 $1.58에 94.0%, 모두 기본 설정은 $1.39에 90.9%~92.5%. 어드바이저 차트의 Claude Sonnet 5 실행자 조합은 이 하위 집합에 대한 같은 2026년 8월 시리즈에서 나옵니다. Sonnet+Opus 조합은 두 번(한 번의 실행과 정확한 복제) 실행되었고 낮은 effort 조합은 한 번, 작업 예산 수치는 같은 하위 집합에서 예산당 한 번 실행입니다. 모델 비교의 Claude Fable 5 수치는 단일 2026년 7월 실행이며, 작업 예산 차트의 예산 없는 기준선이기도 합니다. 모든 예산 실행은 하네스 오류 없이 482개 문제를 모두 완료했습니다.
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. effort 수치는 500개 문제 컷을 사용하며, 설정당 1~3회 실행. 비용 보험 차트는 26개 문제 부분에서 안정적으로 해결되는 10개 문제를 사용하며, 위임 실행 50회와 단독 실행 70회(기대값으로 실행당 $6.45 대 $11.99), 위임 수치는 약 20%의 측정 대역을 가집니다.
5. 에이전트 아키텍처 스케일링: Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025. 독립적인 외부 연구로, 위임이 이득이 되지 않는 경우에 대한 발견의 방향에 대해서만 인용되며 어떤 수치에 대해서도 인용되지 않습니다.
6. DeepWideSearch: "DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025. 220개 질문이 15개 도메인에 걸쳐 있으며, 각각 여러 행 수집과 멀티홉 검색을 결합합니다. 벤치마크의 상설 행 세트에서 측정, 구성당 3회 실행.
7. DeepResearch Bench II: Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026. 22개 도메인에 걸친 132개 리서치 작업이 전문가 유래 이진 루브릭에 따라 채점됩니다. 모든 테마에 걸쳐 층화된 50개 작업 하위 집합에서 측정, 작업당 1회 시도, 3회 실행, 어떤 구성도 거부하지 않은 작업에서 채점. Claude Opus 4.6이 벤치마크의 루브릭 프로토콜에 따라 판정하며, 원본은 다른 판정자를 사용하고 Anthropic 판정자는 자사 스타일을 선호할 수 있습니다. 실행은 Claude Opus 5 이전이므로 모델 비교 차트에 없습니다. Sonnet 5 비용은 캐싱 차트(추론 비용, 캐싱 유무)와 그 차트(총 비용, 캐싱 켬) 사이에서 약간 다르며, 둘 다 같은 실행에서 나옵니다.
8. 코퍼스 결함 스윕: Anthropic 내부, 하나의 컨텍스트 윈도우보다 큰 작업용: 130개의 심어진 결함과 결정론적 채점이 있는 14개 공개 Python 패키지 소스의 2,160만 토큰 코퍼스, 실행 전에 프로토콜을 고정하고 내부 검토, 구성당 3회 실행. 모든 구성은 Claude Managed Agents에서 실행되었습니다. 차트에 표시된 팀 구성은 Claude Fable 5 코디네이터가 문서화된 한도인 동시 Claude Sonnet 5 워커 25개로 플랫폼 내부에서 전체 스윕을 실행한 2026년 8월 실행이며, 세 에피소드는 $263, $299, $261에 F1 0.842, 0.805, 0.810을 기록했습니다. 단독 구성은 같은 코퍼스 빌드에 대한 2026년 7월 실행입니다. 절대 F1은 이 코퍼스 빌드에 특정되며 벤치마크 간 비교할 수 없고, 구성 비교는 동일 조건입니다.
9. GPQA Diamond: Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023. 198개 질문의 Diamond 하위 집합, 2026년 8월 측정, 구성당 2회 실행, 참조 답안에 대해 모델 채점, 어드바이저 토큰은 요청별로 계량. 플랫폼 안전 검사가 Sonnet 및 Opus 실행자에서 생물학 질문 두 개를 거부했으며, 이를 제외해도 어떤 비교도 1점 이상 바뀌지 않습니다.
10. DeepSWE: Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026. 2026년 8월 측정: 프로그램 기반 검증기가 있는 5개 언어에 걸친 113개 원본 작업. 조합은 각각 2회 실행으로 어드바이저 토큰을 요청별로 계량했으며, 어드바이저 도구 대신 클라이언트 측 어드바이저 루프를 사용했고 회계는 동일합니다. 단일 모델 effort 스윕은 토큰 수에서 가격 산정한 단일 실행으로, 캐시 인식 근사치입니다. 작업당 비용은 실행 합계를 113으로 나눈 것입니다.
11. 내부 에이전틱 코딩 벤치마크: Anthropic 내부: 리포지토리 자체 테스트로 채점되는 370개 리포지토리 작업. API 수치(Opus 5 단독, Fable 5 단독, 조합)는 2026년 8월 기본 effort에서 128,000 토큰 출력 상한으로 측정, 구성당 1회 실행: 기본 설정과 조합에서는 작업당 5회 시도, low와 medium에서는 1회, 조합은 시도당 평균 약 두 번의 어드바이저 자문, 비용은 시도당입니다. Claude Code 수치는 같은 작업의 2026년 7월 실행으로, 구성당 1회 실행, 비용은 근사치입니다.
12. 내부 리포지토리 작업 벤치마크(상한 측정): 약 130개 리포지토리 작업의 별도 Anthropic 내부 세트, 2026년 8월 일반 API 에이전트 루프로 실행, 작업당 1회 시도. 16,384 토큰 수치는 모델당 2회 실행의 평균이며, 64,000 토큰 수치는 단일 실행입니다(Opus 5는 124개 작업 채점, Claude Fable 5는 108개, 나머지는 모델이 실행되기 전에 환경이 건너뜀). 16,384 상한이 종료시킨 Fable 시도의 약 절반은 64,000에서 해결되었고, 128,000에서의 추가 Fable 실행은 56.1%를 기록하여 64,000 실행과 노이즈 범위 내였습니다. SWE-bench Pro 상한 수치는 참조 3의 482개 문제 세트에서 층화된 100개 문제 하위 집합에 대해 기본 effort에서 상한당 Claude Fable 5 1회 실행이며, 그 점수와 비교할 수 없습니다. 차트의 턴별 분포는 64,000에서의 Opus 실행과 128,000에서의 Fable 실행에서 나오므로, 어느 쪽도 자체 상한에 의해 잘리지 않습니다.
13. Chartography: Surge AI, "Chartography," 2026. 공개된 전체 100개 질문 세트, 2026년 8월 Claude Managed Agents에서 Anthropic의 구현으로 측정(표준 클라우드 샌드박스, 어드바이저 구성은 Managed Agents 어드바이저 사용). 참조 판정자 대신 Claude Sonnet 4.6이 채점하고 벤치마크가 도구와 함께 실행되므로, 점수는 여기서 구성 간에는 비교되지만 발표된 리더보드와는 비교되지 않습니다. 구성당 2회 실행, 풀링, 실행 간 편차는 4~10점이었습니다. 비용은 샌드박스 시간을 제외하며, 이는 1% 미만을 추가했습니다. 자문율 비교는 같은 구성을 컨테이너 도구 세트와 함께 Messages API에서 재실행한 것에서 나옵니다.
14. 지원 데스크 프롬프트 감사 평가: 결정론적 채점이 있는 44개 지원 티켓의 Anthropic 구성 세트, 2026년 8월 여섯 개의 시스템 프롬프트로 실행, 각각 같은 깨끗한 프롬프트에 Claude Opus 4.8 및 Claude Sonnet 4.6용으로 작성된 프롬프트에서 흔한 패턴 하나를 추가. 각 차트 점은 세 가지 경우(이전 모델, 같은 프롬프트의 새 모델, 감사 후의 새 모델) 중 하나를 여섯 개 프롬프트와 44개 티켓에 걸쳐 평균한 것입니다. Opus 5 정확도 이득은 3~8점의 95% 신뢰 구간을 가지며, Sonnet 정확도 차이는 노이즈 범위 내입니다.



다음 단계