비용과 지능 최적화

가장 성능이 뛰어난 모델은 대규모로 사용하기에는 너무 비쌀 수 있고, 가장 저렴한 모델은 품질이 부족할 수 있습니다. Claude Platform에서는 이 트레이드오프를 직접 제어할 수 있습니다. 각 요청마다 모델, effort 수준, 아키텍처를 선택할 수 있으므로, 워크로드를 비용 대비 지능 프런티어(frontier)의 거의 어느 지점에든 배치할 수 있습니다.

비용과 지능은 보통 한쪽을 얻으려면 다른 쪽을 내줘야 하는 프런티어로 그려집니다. 이 페이지의 첫 번째 레버 그룹은 품질에 손대지 않고 비용을 줄여 워크로드를 그 프런티어 쪽으로 이동시키며, 두 번째 그룹만이 프런티어를 따라 이동시킵니다:

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

• 무료 이득(free wins)은 품질에 손대지 않고 지출을 줄입니다: "prompt caching"(프롬프트 캐싱), "token hygiene"(토큰 위생), 실행 중인 모델에 대한 프롬프트 감사, 최대 24시간 기다릴 수 있는 작업에 50% 할인이 적용되는 배치 처리, 그리고 최후의 안전장치인 워크스페이스 지출 한도입니다.
• 트레이드오프(tradeoffs)는 비용과 지능을 맞바꿉니다. 모델 선택, effort, 출력 상한과 세션 예산, 경과 시간 시계, 다중 모델 아키텍처가 여기에 해당합니다.

각 레버에는 측정 결과와 그 레버가 효과를 내는 시점에 대한 규칙이 함께 제시됩니다. Anthropic의 측정에서는 프롬프트 캐싱이 대체로 가장 큰 레버였습니다. 다중 모델 레버는 적용 범위가 더 좁으며, 두 번째 모델은 어드바이저(advisor)와 오케스트레이터(orchestrator)라는 두 가지 형태로 측정되었습니다.

여기서 시작하세요

자신의 상황에 맞는 행을 찾으세요.

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

품질 저하 없이 지출 줄이기

프롬프트 캐싱, 토큰 위생, 배치 처리, 현재 모델에 맞춘 프롬프트 감사는 모두 출력 품질을 낮추지 않고 비용을 줄입니다. 다만 두 가지 주의 사항이 있습니다. 배치 처리는 할인을 받는 대신 "latency"(지연 시간)를 감수해야 합니다. 또한 토큰 위생 레버 중 하나인 "context editing"(컨텍스트 편집)은 이 섹션에서 측정한 실행에서 절약한 금액보다 더 많은 비용이 들었습니다.

반복되는 컨텍스트 캐싱

캐싱이 가장 먼저인 이유

에이전트 작업은 매 턴마다 시스템 프롬프트, 도구 정의, 이전의 모든 턴을 포함해 점점 길어지는 전체 대화를 다시 전송합니다. 따라서 다른 어떤 레버보다 먼저 프롬프트 캐싱을 켜세요.

• 40턴짜리 작업은 첫 번째 턴을 40번 전송하므로, 작업 비용은 턴 수의 제곱에 대략 비례하여 증가합니다.
• 캐싱을 해도 재전송 자체는 멈추지 않지만, 재전송할 때마다 비용이 약 10분의 1로 줄고(Claude Opus 5.5와 Claude Sonnet 5.5에서는 20분의 1, Claude Fable 5.1 및 Claude Mythos 5.1에서는 40분의 1) 처리 속도도 더 빨라집니다.
• 접두사는 입력 가격 대신 캐시 읽기 요율로 청구되며, 각 턴은 새로 추가된 부분에 대해서만 1.25배의 캐시 쓰기 요율을 지불합니다.

좋은 상태의 기준.

• 하루 동안의 실제 트래픽 전체에서 에이전트 루프는 입력의 중앙값 84%를 캐시에서 읽으며, 코딩 여부와 관계없이 상위 10%는 94% 이상을 읽습니다¹⁷.
• 작업 후반부에서 잘 구성된 루프는 입력의 1% 미만에 대해서만 정가를 지불합니다.
• 약 80% 미만이라면 캐시를 깨뜨리는 요인이 있는지 확인하세요(캐시를 깨뜨리는 요인 참조).

Anthropic이 측정한 실행 전반에서 캐시 읽기는 대개 작업 비용에서 가장 큰 단일 항목이었습니다. 그래서 캐싱은 대부분의 모델 선택 결정보다 더 큰 효과를 냅니다. Anthropic은 DeepResearch Bench II⁷ 실행의 비용을 캐싱을 사용한 경우와 사용하지 않은 경우로 나누어 산정했습니다:

캐시의 기본 수명은 5분이고 에이전트 루프의 턴 간격은 몇 초에 불과하므로, 할인은 매 턴의 대부분의 토큰에 적용됩니다. 캐싱 차트의 실행들은 입력 토큰의 84%~90%를 캐시에서 읽었습니다.

다른 실행에서 기록된 토큰 수를 같은 방식으로 산정하고 각 모델을 기본 effort로 설정하면, 캐싱이 없을 때의 작업당 평균 토큰 비용은 다음과 같습니다(이 실행들 중 캐싱을 끄고 수행된 것은 없습니다).

루프가 짧을수록 다시 읽는 양이 적기 때문에, 절감 효과는 작업에 필요한 턴 수에 따라 달라집니다.

캐시 지속 시간 선택

루프가 턴 사이에 사람의 응답을 기다린다면, 20턴 중 약 1턴이 5분에서 1시간 사이의 일시 중지 뒤에 이어지고 1시간을 넘는 간격이 드문 경우에 1시간 캐시 지속 시간을 사용하세요. Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5에서는 5분 캐시를 웜 상태로 유지하는 편이 비용이 더 적을 수 있습니다.

1시간 지속 시간은 쓰기 비용이 더 높습니다(입력 가격의 1.25배 대신 2배). 어느 지속 시간이든 캐시 미스가 발생하면 접두사 전체가 읽기 가격 대신 쓰기 가격으로 청구됩니다.

Anthropic은 버그 리포트를 분류하는 소규모 에이전트(입력 및 컨텍스트 토큰 줄이기)를 대상으로, 일부 턴 앞에 일시 중지를 삽입해 사람의 지연을 모사하여 측정했습니다¹⁶. 측정한 모든 설정에서 정확도는 실행 간 노이즈 범위 내에 머물렀습니다. 또한 Anthropic은 5분 캐시를 웜 상태로 유지하기 위한 추가 요청(keep-alive 요청)도 측정했습니다.

어떤 설정이 적합한지 판단하려면 대화에서 연속된 요청 사이의 간격을 세고, 다음 표에서 해당하는 행을 찾으세요.

Claude Haiku 5.5에서는 "모든 모델" 행을 사용하세요. Claude Haiku 5.5에서는 keep-alive 요청을 측정하지 않았습니다. 측정이 아닌 정가 기준으로, keep-alive 요청 하나의 비용은 입력 가격 대비 Claude Opus 5.5 및 Claude Sonnet 5.5의 두 배입니다. Claude Haiku 5.5는 캐시를 표준 0.1배로 읽고, 그 두 모델은 0.05배로 읽기 때문입니다.

행별 이유.

• 모든 모델.
  • 턴이 몇 초 간격으로 도착함. 일시 중지가 없는 경우 기본값이 1시간 설정보다 Claude Sonnet 5.5에서 약 19%, Claude Opus 5.5에서 약 15%~18% 저렴했습니다.
  • 20개 간격 중 약 1개 이상. 토큰 수로 계산한 손익분기점은 Claude Sonnet 5.5와 Claude Opus 5.5에서 약 30턴 중 1턴입니다.
  • 1시간을 넘는 간격이 흔함. 어떤 모델에서든 1시간을 넘는 간격은 두 지속 시간을 모두 만료시키며, 이 경우 1시간 설정은 더 높은 쓰기 가격으로 접두사를 다시 씁니다.
• Claude Opus 5.5 및 Claude Sonnet 5.5: 캐시 읽기 비용이 입력 가격의 0.05배입니다.
  • 20개 간격 중 1~2개만 해당. 기본 effort에서 keep-alive 요청은 1시간 지속 시간보다 Claude Opus 5.5에서 8%~13%, Claude Sonnet 5.5에서 8%~16% 저렴했습니다.
  • 모든 턴 앞에 일시 중지가 있음. Claude Opus 5.5와 Claude Sonnet 5.5에서 keep-alive 요청은 6분 일시 중지에서는 1시간 지속 시간보다 몇 퍼센트 더 비쌌고, 45분 일시 중지에서는 50% 넘게 더 비쌌습니다.
• Claude Fable 5.1: 캐시 읽기 비용이 입력 가격의 0.025배입니다.
  • 일시 중지가 수 분간 이어짐. Claude Fable 5.1에서 keep-alive 요청¹⁹은 턴의 10%가 일시 중지된 경우와 모든 턴 앞에 6분 일시 중지가 있는 경우 모두 1시간 캐시보다 13%~20% 저렴했습니다.
  • 일시 중지가 1시간에 가깝게 이어짐. Claude Fable 5.1에서는 모든 턴 앞에 45분 일시 중지가 있는 경우에만 1시간 캐시가 유리했으며, 버그 리포트 5건으로 구성된 세션에서 약 $0.12 USD 차이였습니다.

다음 차트는 Claude Sonnet 5.5에서 일시 중지된 턴의 비율에 따른 세션당 비용을 보여줍니다.

다음 차트는 Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5에서 keep-alive 요청을 통해 웜 상태로 유지한 5분 캐시를 추가로 보여줍니다.

알아 둘 점.

• 20턴 중 1턴 규칙은 약 30턴 중 1턴인 손익분기점보다 여유를 둔 기준입니다. 20턴 중 1턴에서는 Claude Sonnet 5.5에서 5분 설정과 1시간 설정의 비용이 실행 간 편차 범위 내에서 거의 같았고, 10턴 중 1턴에서는 5분 설정이 54% 더 비쌌습니다(참조 16).
• Claude Sonnet 5.5와 Claude Opus 5.5 이외의 모델에서도 가격상 손익분기점은 같은 범위에 있습니다. 현재 모든 모델이 동일한 캐시 쓰기 배수를 사용하며, Claude Fable 5.1, Claude Mythos 5.1, Claude Opus 5.5, Claude Sonnet 5.5를 제외한 모든 모델은 읽기 가격도 같습니다.
• Claude Opus 5.5와 Claude Sonnet 5.5의 keep-alive 수치는 max_tokens: 1로 전송한 요청에서 나온 것입니다. max_tokens: 0 요청이 기존 캐시 항목을 갱신하는지는 Claude Opus 5.5에서 측정하지 않았습니다(참조 16).

캐시를 웜 상태로 유지하려면 다음과 같이 하세요.

1. 이전 요청을 가져와 max_tokens를 0으로 설정하고, stream이 설정되어 있었다면 제거합니다. 접두사는 한 바이트도 변경하지 마세요.
2. 요청의 헤더를 본문과 함께 다시 전송합니다. 원래 요청의 anthropic-beta 헤더가 없으면 재전송하는 본문의 베타 전용 필드가 거부됩니다.
3. 이전 요청이 시작된 시점으로부터 4분 이내에 전송하고, 그 이후에도 4분마다 전송합니다. 캐시의 5분 수명은 요청이 시작된 시점부터 계산되므로, 요청의 시작 시점부터 세세요.

이것이 사전 워밍 요청입니다. 캐시의 수명을 갱신하고, 출력을 반환하지 않으며, 비용은 캐시 읽기보다 약간 더 많은 정도입니다. 캐시가 만료되면 keep-alive 요청이든 아니든 다음 요청이 캐시 쓰기 가격으로 접두사를 다시 씁니다¹⁶.

max_tokens: 0 요청은 다음과 같은 경우에 거부됩니다.

• 요청이 thinking.type: "enabled", 구조화된 출력, 또는 강제 도구 선택을 설정한 경우입니다(Claude Fable 5.1의 기본 적응형 사고는 문제없습니다). 자세한 내용은 제한 사항을 참조하세요. 이러한 워크로드에서는 대신 1시간 지속 시간을 구매하세요.
• 요청에 최상위 compaction 매개변수가 포함된 경우입니다. 따라서 온디맨드 압축의 압축 요청을 keep-alive 요청으로 다시 전송하지 마세요.

# 마지막 요청이 시작된 후 4분 이내에(생성에 소요된 시간도
# 캐시 수명에 포함됩니다), max_tokens 값을 0으로 설정하고
# stream 매개변수를 제거하여 해당 요청을 다시 보내세요(max_tokens: 0 요청은 스트리밍할 수 없습니다). 원래 요청과
# 동일한 헤더(anthropic-beta 헤더 포함)를 함께 보내세요.
jq '.max_tokens = 0 | del(.stream)' last_request.json | \
  curl https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    --data-binary @-

캐싱 켜기

설정에는 많은 작업이 필요하지 않습니다. 자동 캐싱은 중단점을 대신 배치해 주며, 그렇지 않은 경우 Claude Code와 함께 제공되는 Claude API 스킬이 프롬프트 하나(/claude-api add prompt caching to this integration)로 기존 통합에 캐싱을 추가할 수 있습니다. 이 측정 결과를 만든 코드에서는 시스템 블록에 중단점 하나, 가장 최근의 사용자 턴 두 개에 각각 하나씩을 배치했습니다. 중단점을 어디에 배치할지는 명시적 캐시 중단점에서 설명합니다.

캐시를 깨뜨리는 요인

요청마다 달라지는 텍스트는 마지막 캐시 중단점 뒤의 가장 최근 사용자 턴에 두고, 캐시를 무효화하는 모든 변경은 압축 이후 첫 번째 요청처럼 자연스러운 구분 지점에서 수행하세요. 캐시는 요청을 순서대로(도구, 시스템 프롬프트, 메시지 순) 바이트 단위로 정확히 일치시키는 접두사 매칭이므로, 어느 위치에서든 변경이 생기면 그 뒤의 모든 것이 무효화됩니다.

Claude Fable 5.1 및 Claude Mythos 5.1에서는 캐시가 깨지면 접두사를 입력 가격의 0.025배로 읽는 대신 1.25배로 다시 쓰게 되므로 손실이 가장 큽니다. 다음 표는 5분 캐시를 기준으로 100,000 토큰 접두사에서 캐시가 깨진 턴 하나의 비용을 정가로 계산한 값이며, 측정한 값은 아닙니다.

그 외 현재 모델에서는 읽기의 12.5배입니다.

해야 할 일.

• 타임스탬프나 대기열 위치처럼 요청마다 달라지는 내용은 안정적인 접두사 앞에 두지 마세요. 그렇게 하면 모든 요청이 전체 캐시 쓰기가 됩니다. 이전 모델에서 측정한 결과, 시스템 프롬프트 맨 앞에 25토큰짜리 상태 줄을 넣자 버그 리포트를 분류하는 소규모 에이전트(입력 및 컨텍스트 토큰 줄이기)의 실행 비용이 캐싱을 끄고 실행할 때보다 더 많이 들었습니다¹⁸.
• 프롬프트 캐싱 페이지에는 effort, 사고 구성, 시스템 프롬프트, 도구 정의의 변경처럼 캐시를 무효화하는 변경 사항이 나열되어 있습니다. 출력 형식을 변경하면 해당 대화의 캐시가 무효화됩니다(구조화된 출력 참조).
• 최신 모델에서는 최상위 system 필드를 수정하는 대신 messages에 추가하는 {"role": "system"} 메시지인 대화 중간 시스템 메시지로 지침을 변경하세요. 그러면 캐시된 접두사가 그대로 유지됩니다. 어떤 모델이 이를 지원하는지는 해당 페이지에서 확인하세요. 메시지별 effort 변경도 캐시된 접두사를 유지하지만 지원하는 모델이 더 적습니다. 지원 모델은 대화 중 effort 변경에 나와 있습니다.
• 캐시를 무효화하는 변경 후에는 캐시 읽기가 줄어들지 않았는지 확인하세요. 줄어들었다면 캐시 진단에서 접두사가 어디서 달라졌는지 확인할 수 있습니다.

Anthropic은 이전 모델에서 분류 에이전트의 긴 세션을 대상으로 변경 시점에 따른 영향을 측정했습니다¹⁸. 이 측정에서 effort 변경과 도구 추가를 세션 도중이나 압축을 유발한 요청에서 수행한 세션은, 같은 두 가지 변경을 압축 후 첫 번째 요청에서 수행한 세션보다 비용이 더 많이 들었습니다. 모든 경우에서 정확도는 실행 간 노이즈 범위 내였습니다.

변경이 없는 세션은 압축 후에 변경한 세션보다 비용이 더 많이 들었지만, 그 원인은 캐싱이 아닙니다. 이 세션들은 내내 기본 effort로 실행되었고 그중 두 개는 두 번째로 압축되었으며, 나머지는 낮은 effort로 시작했습니다(참조 18).

입력 및 컨텍스트 토큰 줄이기

대부분의 에이전트 요청에는 답변에 전혀 영향을 주지 않는 토큰이 포함되어 있습니다. 이런 토큰을 줄여도 출력 품질이 떨어지는 경우는 드뭅니다. 다만 여기서 소개하는 레버가 측정에서 모두 비용을 절감한 것은 아닙니다. 살펴볼 곳은 두 가지입니다:

• 입력 줄이기.
  • 웹 가져오기 도구의 동적 필터링은 가져온 페이지에서 불필요한 상용구를 제외합니다.
  • 이미지 크기 조정은 비전 입력의 크기를 적절하게 맞춥니다.
  • 지연 로딩을 사용하는 도구 검색은 필요할 때만 도구 정의를 로드합니다(이 섹션의 뒷부분에서 측정합니다).
  • 프로그래밍 방식 도구 호출은 Claude가 코드에서 여러 도구 호출을 실행하게 하여 필터링된 결과만 컨텍스트에 들어가도록 합니다. 해당 문서에 따르면 에이전트 검색 벤치마크에서 입력 토큰이 24% 줄었고 점수는 더 높았습니다.
  • 도구 컨텍스트 관리에서는 도구 검색, 프로그래밍 방식 도구 호출, 프롬프트 캐싱, 컨텍스트 편집을 비교합니다.
• 컨텍스트 수명 주기. 컨텍스트 편집은 오래된 도구 결과를 지웁니다. 임계값을 설정한 자동 압축은 긴 루프가 전체 기록을 계속 끌고 가지 않도록 합니다.

이 레버들은 캐시와도, 서로 간에도 영향을 주고받으므로 순효과를 기준으로 판단하고, 캐시 진단을 사용하여 변경할 때마다 캐시된 접두사가 유지되는지 확인하세요.

이전 모델에 대한 측정²⁸에서 Anthropic은 공개 저장소의 스크린샷이 포함된 실제 버그 리포트 20건을 처리하는 이슈 분류 에이전트와, 토큰 수가 2.6배인 같은 작업의 더 긴 버전에서 이 레버들을 실행했습니다. 캐싱을 켠 상태에서 입력 줄이기(이미지 크기 조정과 도구 검색)는 두 실행 모두의 비용을 추가로 낮췄습니다.

사용하지 않는 도구 정의 지연 로딩

요청에 첨부된 모든 도구 정의는 매 턴마다 입력이 되며, MCP 서버 몇 개만 있어도 수백 개가 쌓입니다.

이전 모델에 대한 측정²⁷에서 Anthropic은 이슈 분류 에이전트를 자체 도구 두 개와 공개 MCP 서버의 실제 도구 정의 카탈로그(총 최대 502개 도구)와 함께 실행했습니다. 이때 모든 도구를 로드하거나, 추가 도구를 defer_loading으로 표시해 도구 검색으로 불러오게 했습니다.

• 모든 정의를 로드했을 때는 카탈로그가 커질수록 실행 비용이 증가했으며, 이는 각 요청의 스키마 토큰 수를 그대로 따랐습니다.
• 도구 검색을 사용했을 때는 카탈로그 크기와 관계없이 실행 비용이 일정하게 유지되었습니다.
• 정확도는 두 경우 모두 비슷한 범위였고 모델이 잘못된 도구를 호출한 적도 없었으므로, 이 규모에서 카탈로그는 정확성이 아니라 비용을 늘립니다.
• 같은 이전 모델에서 MCP 커넥터를 통해 공개 GitHub MCP 서버를 연결하고 해당 도구 세트를 지연 로딩하자(default_config: {defer_loading: true}) 같은 정확도에서 실행 비용이 줄었습니다.

데이터 파일을 프롬프트에서 제외하기

모델이 표 데이터로 계산해야 할 때는 표를 프롬프트에 붙여 넣지 마세요. 대신 Files API로 업로드하고 모델이 코드 실행으로 쿼리하게 하세요. Anthropic은 1,862행짜리 공개 CSV를 대상으로 25개의 집계 질문¹⁵(합계, 필터링된 개수, group-by, 날짜 필터)을 던졌으며, 정답은 pandas로 계산했습니다:

프롬프트에 붙여 넣으면 표는 요청마다 약 91,000개의 입력 토큰이 되며, Claude Sonnet 5는 25개 질문 중 7개에 정답을 맞혔습니다. 업로드하고 코드 실행을 사용했을 때는 25개 모두 정답이었고 실행 비용은 약 12분의 1이었습니다. Claude Opus 5에서도 같은 패턴이 나타났습니다.

컨텍스트 수명 주기 관리

컨텍스트 레버는 세션이 이 레버가 필요할 만큼 길 때만 효과가 있습니다:

Anthropic은 이전 모델에서 이 레버들을 측정했습니다²⁸.

• 이슈 20건 실행에서는 이 레버들이 절감한 비용이 거의 없거나 전혀 없었고, 컨텍스트 편집은 오히려 실행 비용을 늘렸습니다.
• 긴 실행에서는 가지치기와 압축 모두 비용을 줄였지만, 컨텍스트 편집은 아무런 변화가 없었습니다.
• 가지치기는 직접 작성하는 몇 줄의 코드입니다. 각 작업 경계에서 오래된 큰 도구 결과를 한 줄짜리 발췌문으로 교체합니다.
• 가지치기는 수정이 대화의 끝부분에서 이루어지고 다음 작업이 어차피 그곳에 새 내용을 추가하므로 캐싱이 잘 됩니다.
• 실행 전체로 보면 가지치기와 컨텍스트 편집의 캐싱 효율은 거의 같습니다. 컨텍스트 편집을 사용한다면 몇 번의 큰 배치로 지우세요.

이슈 분류 에이전트의 코드를 바탕으로 작성한 가지치기 예시입니다.

import re

PRUNED = "[pruned at issue boundary]"


def prune_task_boundary(messages, tool_name_by_id, threshold=2000):
    """Call once per task boundary. Replaces large, stale search results with a one-line extract."""
    for message in messages:
        if message["role"] != "user" or not isinstance(message["content"], list):
            continue
        for block in message["content"]:
            if not (isinstance(block, dict) and block.get("type") == "tool_result"):
                continue
            if tool_name_by_id.get(block.get("tool_use_id")) != "search_issues":
                continue
            result_text = block.get("content")
            if not isinstance(result_text, str) or len(result_text) <= threshold:
                continue
            if result_text.startswith(PRUNED):
                continue  # already pruned on an earlier boundary
            # 추출 결과가 짧게 유지되도록 한 줄 결과의 길이를 제한합니다
            first_line = result_text.split("\n", 1)[0].strip()[:200]
            refs = re.findall(r"#(\d+)", result_text)[:5]
            extract = f"{PRUNED} {first_line}"
            if refs:
                extract += " kept refs: " + " ".join("#" + r for r in refs)
            block["content"] = extract

기다릴 수 있는 작업은 배치로 처리하기

아무도 기다리지 않는 모든 요청은 Batch API로 보내고, 대화형 경로는 나머지 요청에만 사용하세요. Batch API는 캐시된 토큰을 포함하여 요청의 모든 토큰에서 50%를 할인해 주는 대신, 결과가 24시간 이내 언제든 도착합니다.

• 배치 처리는 평가 실행, 백필, 그리고 토큰 줄이기 측정의 이슈 분류 에이전트를 반복 실행하는 것과 같은 예약 작업처럼 사람이 지켜보지 않는 에이전트 작업에서 캐싱 다음으로 큰 무료 레버입니다.
• 배치 처리는 대화형 처리를 제외한 이 페이지의 모든 방법과 함께 사용할 수 있지만, 설계상 대화형인 Claude Managed Agents 세션에서는 사용할 수 없습니다(Claude Managed Agents 가격 참조).

현재 모델에 맞춰 프롬프트 감사하기

현재 실행 중인 모델을 기준으로 프롬프트를 감사하고, 모델을 바꿀 때마다 다시 감사하세요. 이는 무료 이득입니다.

• 모델 세대마다 프롬프트에 반응하는 방식이 다르므로, 프롬프트에는 더 이상 사용하지 않는 모델을 위해 작성한 텍스트가 쌓입니다.
• 흔한 경우는 이전 모델을 보완하려고 추가한 지나치게 구체적인 지시입니다. "verify twice"(두 번 검증하세요), "be maximally thorough"(최대한 철저하게 하세요), 필수 단계별 절차, 직접 만든 추론용 스크래치패드 같은 것들입니다.
• 더 새로운 모델은 이러한 지시를 글자 그대로 따르기 때문에 도구 호출 라운드와 작성량이 늘어나고, 정확도는 그대로인 채 비용만 올라갑니다.

감사는 명령 하나로 실행할 수 있습니다. 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로 제안하고(hunk 하나만 표시), 의도적으로 그대로 둔 항목인 환불 기간, 어조 요구 사항, 품질 기준을 나열합니다. 전체를 다시 작성한 결과가 아니라 패치만 검토하면 됩니다.

Anthropic은 이전 모델 간의 두 차례 마이그레이션에 걸쳐 고객 지원 데스크 평가에서 그 효과를 측정했습니다¹⁴.

• Claude Opus 4.8에서 Claude Opus 5로 옮길 때, 이전 모델용으로 작성된 프롬프트는 정확도 변화 없이 새 모델에서 티켓당 비용이 더 높았습니다.
• 같은 프롬프트에 감사를 실행하자 Claude Opus 5는 감사하지 않은 버전보다 비용이 낮아졌을 뿐 아니라 정확도도 높아졌으며, 이는 노이즈 범위를 벗어난 향상이었습니다.
• Claude Sonnet 4.6에서 Claude Sonnet 5로 옮길 때, 감사는 같은 정확도에서 티켓당 비용을 줄였습니다.

오래된 텍스트의 두 가지 유형은 비용이 서로 다릅니다.

• 새 모델이 지나치게 문자 그대로 따르는 지시는 비용을 늘립니다. "verify twice"를 제거하자 Claude Opus 5의 티켓당 비용이 줄었고, "be maximally thorough"를 제거했을 때도 거의 비슷하게 줄었습니다.
• 더 이상 모델에 맞지 않는 텍스트는 대신 정확도를 떨어뜨립니다. 종료된 사고 설정, 모순되는 규칙, 모델 자체의 사고와 충돌하는 직접 만든 스크래치패드는 각각 제거했을 때 Claude Opus 5의 정확도를 회복시켰습니다.

같은 패턴은 도구 설명과 스킬에도 나타나기 쉬우므로, 이들도 함께 감사하는 것이 좋습니다.

비용과 지능 맞바꾸기

이 레버들은 단일 모델이 비용과 지능 사이에서 어디에 위치할지를 결정합니다. 모델 선택, effort, 실패한 작업을 더 높은 설정으로 재실행하기, 모델이 작업하는 예산과 상한, 그리고 모델이 경과 시간을 볼 수 있는지 여부가 여기에 해당합니다. 현재 모델에서 effort 스윕부터 시작하세요(Effort 조정). 비용과 성능이 낮은 것부터 높은 순으로 현재 모델은 Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5, Claude Fable 5.1(프런티어 모델)입니다. 전체 라인업과 가격은 모델 개요에서 확인하세요.

작업당 비용으로 모델 비교하기

비용을 지불하는 대상은 완료된 작업이므로, 토큰당이 아니라 완료된 작업당 비용으로 모델을 비교하세요. 대부분의 에이전트 워크로드에서는 기본 effort(medium)의 Claude Opus 5.5로 시작하세요.

더 뛰어난 모델은 더 적은 작업으로 과제를 끝낼 수 있으며, 이는 토큰당 추가 비용의 상당 부분을 상쇄할 수 있습니다. Anthropic은 고객에게 청구되는 방식 그대로 가격을 산정하여 SWE-bench Pro³ 하위 집합에서 이를 측정했으며, 이 점수는 공개 리더보드와 비교할 수 없습니다.

다음 표는 결과를 보여 줍니다.

해야 할 일.

• 기본 effort의 Claude Opus 5.5로 시작하세요. SWE-bench Pro 하위 집합에서 이 모델은 실행 간 노이즈 범위 안에서 기본값의 Claude Fable 5.1과 동등했으며, 해결된 작업당 비용은 약 5분의 1이었습니다. Opus 5.5와 Fable 5.1은 모두 SWE-bench Pro 하위 집합을 대체로 포화시킵니다. 까다로운 추론과 장기 에이전트 작업에는, 또는 더 높은 effort의 Claude Opus 5.5에서 평가 결과가 여전히 부족할 때는 Claude Fable 5.1을 사용하세요.
• 반대쪽 끝에서는 Claude Haiku 5.5가 출력을 검증할 수 있는 대용량 및 지연 시간에 민감한 작업에 적합합니다.
• 기본 effort의 Claude Opus 5.5와 낮춘 effort의 프런티어 모델을 포함하여, 모든 후보를 자체 트래픽에서 완료된 작업당 비용으로 가격을 산정하세요. Claude Opus 5.5의 토큰 가격은 캐시 읽기를 포함하여 각각 Claude Sonnet 5.5의 두 배이지만, SWE-bench Pro 하위 집합에서 low의 Opus 5.5는 실행 간 노이즈 범위 안에서 기본값의 Sonnet 5.5와 거의 같은 비율의 작업을 해결했고, 해결된 작업당 비용은 약 7% 더 높았을 뿐입니다.
• 순위는 워크로드에 따라 뒤바뀌며 어떤 가격표도 어느 쪽인지 알려 주지 않으므로, 자체 워크로드에서 직접 측정하세요. 긴 리서치 루프에서는 Claude Fable 5.1이 더 적은 작업이 아니라 더 많은 작업을 수행하여 작업당 비용이 더 높아질 수 있습니다(DeepResearch Bench II⁷).
• 중앙값이 아니라 워크로드의 꼬리(tail)를 기준으로 가격을 산정하세요. 일반적인 작업이 아니라 가장 어려운 상위 10%의 작업에서 모델을 비교하세요.

청구 금액은 더 저렴한 모델이 실패하는 작업에 의해 결정됩니다. 실패한 작업도 토큰 비용이 청구되고, 그다음 재시도 비용이 들며, 그 뒤에는 실패가 다운스트림에 초래하는 비용이 따르기 때문입니다. 꼬리 부분은 아무것도 실패하지 않더라도 비용이 몰리는 곳입니다. 20개 문제로 구성된 WideSearch¹ 실행에서는 두 문제가 전체 지출의 43%를 차지했습니다.

다중 모델 전략은 나머지 작업에 프런티어 요금을 지불하지 않으면서 그 꼬리에 프런티어 지능을 투입하기 위해 존재합니다.

모델 업그레이드

사용 중인 모델이 한두 세대 뒤처져 있다면, 가장 저렴한 레버는 모델 문자열을 바꾸는 것입니다. Anthropic의 측정에서는 새 모델이 각각 이전 모델 이상으로 많은 작업을 해결했습니다. 해결된 작업당 비용도 대체로 더 낮았습니다. 차트는 모든 모델이 동일한 테스트 설정으로 실행된 SWE-bench Pro³ 하위 집합과 Terminal-Bench 3²⁰에서 최근 Claude 모델을 비교해 보여 주며, 표는 각 업그레이드가 무엇을 바꾸었는지 정리합니다.

효과가 있는 경우.

• 이전 모델이 이미 대부분의 작업을 해결하는 경우에는 각 시도의 비용이 절감 효과를 좌우합니다. SWE-bench Pro 하위 집합에서 Claude Opus 5.5는 Claude Opus 5와 거의 같은 점수를 내면서 해결된 작업당 비용은 78% 낮습니다.
• 이전 모델이 대부분 실패하는 경우에는 통과율이 절감 효과를 좌우합니다. Terminal-Bench 3²⁰에서 Claude Opus 4.8에서 Claude Opus 5로 업그레이드하면 해결된 작업이 15%에서 41%로 늘고 해결된 작업당 비용은 56% 줄어듭니다.
• 절감될 것이라고 가정하기 전에 자신의 워크로드에서 업그레이드를 측정하세요. 절감은 보장되지 않습니다. DeepResearch Bench II⁷에서는 입력 및 출력 가격이 같고 캐시 읽기가 4배 저렴한데도, 새 모델이 작업당 더 많은 일을 하기 때문에 Claude Fable 5.1이 Claude Fable 5보다 작업당 비용이 더 많이 듭니다.
• 토큰당이 아니라 해결된 작업당 비용으로 비교하세요. 같은 텍스트가 Claude 4.7 이후 모델에서는 토큰이 약 30% 더 많이 들기 때문에, 토큰당 비교는 구조적으로 새 모델이 더 비싸 보이게 만듭니다.

Effort 조정

두 번째 모델을 추가하기 전에 자신의 워크로드에서 effort를 스윕(sweep)해 보세요. 낮은 effort는 비용이 적게 들고 대체로 더 빠르며, 그로 인해 정확도를 얼마나 포기하게 되는지는 작업에 따라 다릅니다. 장기 코딩에서는 effort가 정확도를 높여 주었고, 리서치 작업에서는 한 측정에서는 큰 효과가 있었지만 다른 측정에서는 전혀 없었습니다. effort 매개변수는 모델이 수행하는 사고, 도구 호출, 자체 검증의 양을 조절합니다. 대부분의 모델에서 기본값은 high이며, Claude Opus 5.5와 Claude Haiku 5.5에서는 medium입니다.

다음 표는 현재 모델을 대상으로 두 벤치마크에서 측정한 Anthropic의 결과를 보여 줍니다. 두 벤치마크 간에는 점수와 비용을 비교할 수 없습니다. 비용은 작업당 비용으로 모델 비교하기에서처럼 해결된 작업당이 아니라 작업당입니다. 셀에 별도로 명시되지 않은 한, 각 점수는 SWE-bench Pro에서는 2회, DeepResearch Bench II에서는 3회 실행을 합산한 것입니다.

다음 차트는 SWE-bench Pro³ 하위 집합에서 Claude Opus 5.5의 작업당 비용 대비 정확도를 보여 줍니다.

다음 차트는 DeepResearch Bench II⁷에서 Claude Fable 5.1의 작업당 비용 대비 루브릭 점수를 보여 줍니다.

해야 할 일.

• 자신의 트래픽 샘플에서 두세 가지 effort 수준을 스윕하되, 각각 별도의 세션에서 실행하세요. 세션 도중에 최상위 effort를 변경하면 캐시가 무효화되어 비교가 왜곡됩니다. 이 곡선은 모든 다중 모델 전략이 넘어서야 하는 기준선입니다(자체 워크로드에서 측정하기의 2단계).
• 장기 코딩에서 effort는 실제 트레이드오프이며, 실패한 작업을 더 높은 effort로 재실행하면 이를 다시 절감으로 바꿀 수 있습니다. SWE-bench Pro³ 하위 집합에서 medium의 Claude Sonnet 5.5는 기본값인 high보다 점수가 약 7점 낮았고 작업당 비용은 약 59%였으며(각 2회 실행), 내부 에이전트 코딩 벤치마크¹¹에서는 77.8%에 비해 62.7%를 기록했습니다(작업당 1회 시도).
• 리서치 작업에서는 실제로 배포할 모델을 측정하세요. Claude Fable 5.1은 DeepResearch Bench II에서 low부터 high까지 거의 같은 점수를 냈고, Claude Opus 5.5는 DRACO²¹에서 low일 때 medium보다 13.3점 낮았습니다. 두 결과는 서로 다른 벤치마크에서 서로 다른 모델로 얻은 것이므로, 답이 달라진다는 점은 보여 주지만 그 이유는 보여 주지 않습니다.
• low에서 Claude Opus 5.5의 일반적인 작업은 medium일 때보다 DRACO²¹에서 84%, HLE²²에서 30%, 내부 물리학 문제 세트²³에서 47% 적은 시간이 걸렸고, 점수는 각각 13.3점, 3.4점, 14.0점 낮았습니다(작업당 3회, 3회, 4회 시도).
• 하나의 컨텍스트 윈도우보다 큰 작업을 위한 내부 결함 탐색 벤치마크⁸에서 Claude Fable 5.1은 low, medium, high에서 실행당 각각 15.2시간, 17.5시간, 19.9시간이 걸렸습니다(각 3회 실행). 시간을 절약하려면 모델에 경과 시간 표시하기의 두 가지 변경 사항과 낮은 effort도 비교해 보세요. low effort는 시간을 더 많이 절약했고, 변경 사항은 점수를 더 많이 유지했습니다.

실패한 작업을 더 높은 effort로 재실행

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

Anthropic은 Effort 조정의 SWE-bench Pro³ 하위 집합에서 Claude Opus 5.5 effort 실행 결과를 바탕으로 이 정책을 작업별로 계산했습니다.

다음 표에서 재실행 비용에는 실패한 저비용 시도가 포함됩니다.

• low에서는 작업의 13%가 실패했습니다. 이를 high로 재실행하자 통과율은 모든 작업을 high로 실행했을 때보다 약간 높았고, 비용은 절반을 조금 넘는 수준이었습니다.
• 이 정책은 성능 향상이 아니라 비용 절감을 위해 사용하세요. 작은 향상의 대부분은 두 번째 시도에서 비롯됩니다. 한 번의 high 실행에서 실패한 작업을 high로 다시 실행해도 점수는 거의 같고 비용만 더 듭니다.

이 정책에는 두 가지 조건이 있습니다. 첫째, 실패를 판별할 신호가 필요합니다(여기서는 벤치마크 자체의 테스트). 검사기가 잘못된 결과를 통과시키면 그 실패는 재실행되지 않습니다. 둘째, 첫 번째 시도에서 실패한 작업은 실행 두 번 분량의 실제 소요 시간이 걸립니다. 즉, 비용 절감의 대가로 실패한 작업의 지연 시간이 늘어납니다.

예산 및 출력 상한 설정

두 가지 제어는 서로 다른 역할을 합니다. 세션 예산은 하나의 Claude Managed Agents 세션이 쓸 수 있는 금액을 제한하고, max_tokens는 하나의 응답 길이를 제한합니다. 각각 해당하는 곳에 설정하고, 최종 안전장치로 워크스페이스 지출 한도를 두세요.

• Claude Managed Agents의 세션 예산은 지출에 대한 강제 중단 장치입니다. 세션 예산은 한 세션의 정가 비용에 대한 달러 단위 상한이며, 플랫폼이 토큰, 웹 검색, 세션 실행 시간에 대해 이를 측정합니다.
• 상한에 도달하거나 약간 넘으면 세션이 stop_reason: budget_reached와 함께 일시 중지되며, 예산을 늘리면 다시 시작됩니다. 이는 플랫폼에서 강제되며 정가가 있는 모든 모델에서 작동합니다. 배포(Deployments)는 자신이 시작하는 각 세션에 동일한 예산을 적용합니다.
• max_tokens는 모델에게 보이지 않는 방식으로 단일 응답을 제한하므로, 이를 낮춘다고 해서 모델이 절약하려 하지는 않습니다. 여유 공간이 필요했던 턴은 폐기되지만 여전히 과금됩니다. 상한에 걸린 시도를 재시도해도 거의 도움이 되지 않습니다. 같은 상한에서는 대부분 다시 실패하고, 더 높은 상한에서는 낭비된 시도에 대한 비용까지 지불하게 됩니다.
• 에이전트 작업에는 max_tokens를 64,000으로 설정하고, 중간에 끊긴 시도 하나의 비용이 큰 경우에는 최댓값인 128,000으로 설정하세요. 이렇게 큰 응답은 스트리밍하고, stop_reason: max_tokens는 실패로 처리하며, 비용 절감은 모델이 볼 수 있는 effort로 하세요.

다음 표는 내부 저장소 작업 벤치마크¹²에서 각 상한별로 모델이 해결한 작업과 해결된 작업당 비용을 보여 줍니다. 작업당 1회 시도이며 각 모델은 기본 effort입니다. 16,384 행은 2회 실행의 평균이고, 나머지 행은 각각 1회 실행입니다.

64,000과 128,000에서의 Claude Opus 5.5: 두 상한 모두에서 중간에 끊긴 시도가 없었으므로, 상한은 이 두 행이 해결된 작업 수나 해결된 작업당 비용에서 차이가 나는 이유를 설명하지 못합니다. 각 행은 1회 실행입니다.

상한은 각 모델 내에서 비교하세요. 두 모델은 한 달 간격으로 실행되었으며, 비용은 서로 다른 기준으로 산정되었습니다.

더 짧은 답변을 요청하세요. Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5, Claude Fable 5.1에서 출력 토큰은 입력 토큰보다 다섯 배 비싸며, 에이전트 루프에서는 모델이 작성한 모든 토큰이 이후 모든 턴에서 다시 입력으로 돌아오므로 긴 답변에 대해 계속 반복해서 비용을 지불하게 됩니다.

이전 모델에 대한 측정²⁶에서 Anthropic은 버그 리포트를 분류하는 소규모 에이전트(입력 및 컨텍스트 토큰 줄이기)를 동일한 모델과 도구로 세 가지 최종 답변 지침에 따라 각각 세 번씩 실행했습니다.

• 원래 지침은 두 줄을 요청했습니다.
• 더 짧은 변형은 한 줄을 요청했습니다.
• 더 긴 변형은 제목이 있는 여섯 개 섹션으로 구성된 메모를 요청했습니다.

다음 차트는 각 형식의 실행당 비용을 보여 줍니다.

세 가지 모두 정답 레이블 기준으로 실행 간 노이즈 범위 내의 점수를 기록했으므로, 형식은 정답률보다 지불하는 비용에서 훨씬 더 큰 차이를 보입니다. 철저해 보이는 답이 아니라 실제로 읽을 답을 요청하세요.

내부 저장소 작업¹²에서는 거의 모든 턴이 16,384 토큰 상한보다 훨씬 낮은 수준에서 끝납니다. 드물게 나타나는 긴 턴이 바로 더 높은 상한으로 얻는 것입니다.

모델에 경과 시간 표시하기

에이전트가 더 빨리 끝나고 비용도 줄이게 하려면, 시간이 중요하다고 알려 주고 모든 요청마다 경과 시간을 보여 주세요. Anthropic의 측정에서 이 두 가지 변경은 medium effort의 단일 Claude Opus 5.5 에이전트가 일반적인(중앙값) DRACO²¹ 리서치 작업을 수행하는 시간을 47%, 비용을 60% 줄였으며, 평균 점수는 4.1점 낮아졌습니다.

HLE²²와 내부 물리학 세트²³에서는 일반적인 작업의 소요 시간이 각각 14%와 7% 줄었고, 물리학 세트 점수는 3.0점 낮아졌습니다. effort를 low로 낮추면 이 변경보다 시간과 비용은 더 많이 절약되었지만 점수도 더 많이 떨어졌습니다(참조 21). 이 변경을 적용하기 전에 자체 작업에서 점수를 확인하세요.

실제 동작하는 코드는 두 가지 변경을 에이전트 팀에 적용한 Claude Cookbook 레시피 지연 시간 압박과 예산 하의 멀티에이전트 팀을 참조하세요. 시간이 중요하다는 점을 시스템 프롬프트에서 알리려면 멀티에이전트 하네스를 위한 시간 신호를 참조하세요.

다음 차트에는 리드 에이전트가 헬퍼를 거의 시작하지 않은 팀과 low effort의 단일 에이전트도 함께 표시되어 있습니다.

모델 결합

두 번째 모델을 추가하기 전에 먼저 하나의 모델을 조정하세요. 대부분의 워크로드는 현재 모델에서 effort를 조정하는 것으로 충분하므로 먼저 이를 스윕하고, 스윕 결과 격차가 있다면 더 강력한 모델을 낮은 effort로 단독 실행했을 때의 비용을 산정해 보세요. 점수 대비 지출의 전체 곡선에서 단일 모델을 능가하는 경우에만 조합을 구성하세요. 이 페이지의 다중 모델 결과는 같은 모델을 더 낮은 effort로 실행한 경우, 그리고 한 단계 아래 모델을 단독 실행한 경우와 비교하여 평가되었으며, 자체 워크로드에서도 이 비교를 수행해야 합니다.

다음 표는 두 가지 전략을 비교합니다.

어드바이저 전략: 어려운 결정 에스컬레이션

어드바이저는 실행자가 자문을 구할 때만 도움이 될 수 있습니다.

현재 모델에 대한 Anthropic의 측정에서, 코딩 벤치마크에서 실행자가 자주 자문을 구한 유일한 조합은 같은 effort의 실행자 단독보다 1.7점 높은 점수를 기록했으며, 이는 실행 간 노이즈의 경계에 해당하고 비용은 약 2.1배였습니다. 실행자가 자문을 거의 또는 전혀 구하지 않은 경우, 조합의 점수는 실행자 단독과 실행 간 노이즈 범위 내이거나 그보다 낮았습니다.

이를 켜려면 요청에 베타 기능인 어드바이저 도구를 추가하세요. Claude Managed Agents에서는 세션에 어드바이저 제공하기를 참조하세요. Claude Code에서는 어드바이저 도구로 어려운 결정 에스컬레이션하기를 참조하세요.

다음 표는 각 조합을 같은 effort의 실행자 단독과 비교합니다.

• 내부 에이전트 코딩 벤치마크. high의 Claude Opus 5.5와 Claude Fable 5.1 어드바이저.
• GPQA Diamond. 각 모델의 기본값(medium과 high)의 Claude Haiku 5.5 또는 Claude Sonnet 5.5와 Claude Opus 5.5 어드바이저.
• Chartography. low의 Claude Opus 5.5와 Claude Fable 5.1 어드바이저.

어드바이저는 실행자에게 없는 능력만 넘겨줄 수 있습니다. GPQA Diamond에서 Claude Sonnet 5.5 단독은 거부를 오답으로 계산했을 때 Claude Opus 5.5 단독과 91%로 동점이었지만, 이는 Opus 5.5가 실행당 생물학 질문 6개를 거부한 반면 Sonnet 5.5는 1개를 거부했기 때문입니다. 각 모델이 답변한 질문만 놓고 보면 Opus 5.5가 약 2점 앞섰습니다.

코딩 벤치마크에서 조합의 이득은 실행 간 노이즈의 경계에 있으며, Claude Opus 5.5 자체의 effort 곡선 위에 거의 놓입니다. 즉 어드바이저는 effort를 높였을 때와 비슷한 수준의 성능을 얻게 해 주었습니다. 다음 차트는 이 조합을 해당 곡선 및 8월의 Claude Fable 5.1 곡선과 함께 표시합니다.

해야 할 일.

• 자체 작업에서 자문 비율을 측정하세요. 요청당 약 1,000 프롬프트 토큰인 어드바이저 도구 정의는 실행자가 한 번도 자문을 구하지 않더라도 비용을 추가합니다. 프롬프트 캐싱을 사용하면 멀티 턴 에이전트 루프는 첫 요청 이후 이 정의에 대해 캐시 읽기 가격을 지불하므로, 이 오버헤드는 짧은 단일 요청 작업에서 가장 크게 작용합니다.
• 실행자가 자문을 거의 구하지 않는다면, 자문을 요청하는 시스템 프롬프트에 대해 코딩 및 에이전트 작업을 위한 프롬프팅을 참조하고, 프롬프트를 추가한 후 다시 측정하세요. SWE-bench Pro³ 문제 20개에서 제안된 프롬프트는 Claude Sonnet 5.5에 뚜렷한 차이를 만들지 못했습니다.
• 자문 비율이 급감하면 실행자의 effort를 복원하세요. 이전 모델에 대한 측정에서, 기본 effort에서는 대부분의 작업에서 자문을 구하던 한 조합이 effort를 낮추자 자문을 거의 구하지 않았고, 그 결과 실행자 단독보다 낮은 점수를 기록했습니다(SWE-bench Pro³).
• 모델이 출시될 때마다 다시 확인하세요. 출시는 능력 격차와 가격 비율을 모두 바꾸기 때문입니다.

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

이전 모델인 Claude Sonnet 5를 워커로 사용한 측정에서, 위임이 비용을 절약한 경우는 두 가지뿐이었습니다.

• 비용 분포의 꼬리가 긴 일상적인 작업(BrowseComp⁴의 쉬운 구간)
• 컨텍스트 윈도우 하나보다 큰 작업(내부 결함 탐색 벤치마크⁸)

작업이 하나의 의존적인 체인이거나, 비용 분포의 꼬리가 길지 않고 단일 컨텍스트에 들어맞는 경우에는, 측정한 모든 사례에서 오케스트레이터의 모델을 더 낮은 effort로 단독 실행한 쪽이 앞섰으며, 이 측정 역시 이전 모델에서 이루어졌습니다(더 어려운 BrowseComp 세트와 DeepWideSearch⁶). 독립적인 외부 연구에서도 같은 패턴이 보고됩니다⁵.

오케스트레이터를 구축하려면 Claude Managed Agents의 멀티에이전트 오케스트레이션을 사용하세요. 오케스트레이터 에이전트와 이 에이전트가 호출할 수 있는 워커 에이전트를 구성하며, 각 에이전트는 자체 모델을 사용합니다.

모델 선택 매트릭스는 하위 에이전트 작업용으로 Claude Haiku 5.5를 나열합니다. 워커로 사용하기 전에 자체 워크로드에서 측정하세요.

다음 차트는 결함 탐색 벤치마크의 구성을 비용과 점수로 표시합니다.

해야 할 일.

• 비용 분포의 꼬리가 긴 일상적인 작업: 이 경우를 먼저 측정하되, 비용뿐 아니라 정확도도 확인하세요. 이 결과의 근거가 된 측정은 위임 구성이 모든 실행에서 정답을 낸 문제만 다룹니다(참조 4).
• 컨텍스트 윈도우 하나보다 큰 작업: 파티션을 워커에게 위임하세요. 비용은 읽기 자체에서 발생하므로 effort를 낮추는 것은 도움이 되지 않습니다. 결함 탐색 벤치마크⁸에서 Claude Fable 5.1 단독은 세 가지 effort 설정에 걸쳐 실행당 $468 USD에서 $552 USD의 비용이 들었고 15~20시간이 걸렸습니다. 이전 모델 워커를 사용하면 위임은 비용이 더 적게 들고 더 빨리 끝났지만 점수는 더 낮았습니다.

자체 워크로드에서 측정하기

자체 워크로드에서 측정하세요. 이 페이지의 수치는 측정 시점의 정가를 반영하며 모델과 가격이 바뀌면 달라지고, 에스컬레이션 비율, 작업이 얼마나 깔끔하게 분할되는지, 트랜스크립트 길이에 따라서도 달라집니다. 방법은 동일합니다.

1. 실제 트래픽과 같은 비중으로 프로덕션 로그에서 몇 가지 작업을 추출하고, 각 작업에 대해 결과 검사를 작성하세요(테스트 통과, 티켓 종료, 행 수 일치 등). 점수 옆에 작업당 비용을 기록하세요.
2. 기본값뿐 아니라 여러 effort 수준에 걸쳐 모델 티어별 기준선을 측정하고, 지출 대비 점수를 그래프로 그리세요. 다중 모델 구성은 단일 모델의 곡선 전체보다 나아야 합니다.
3. 곡선에서 effort로 메울 수 없는 격차가 보이면, 적합한 다중 모델 전략을 추가하고 테스트 모음을 다시 실행하세요.
4. 전환하기 전에 트래픽 일부에서 가장 좋은 구성을 섀도 모드로 실행하고, 전환 후에도 테스트 모음을 계속 실행하세요.

작업 비용 산정 방법. 각 응답의 usage에는 가격이 책정되는 다섯 가지 토큰 수가 있습니다. 각각 고유한 요율로 계산하세요. 캐시되지 않은 입력, 입력 가격의 1.25배와 2배인 5분 및 1시간 캐시 쓰기, 캐시 읽기, 출력입니다. 작업의 모든 요청에 걸쳐 합산하세요(Usage and Cost API가 집계를 보고합니다). Claude Haiku 5.5에서는 캐시 읽기와 쓰기를 포함하여 각 요청을 프롬프트 길이에 해당하는 요율로 계산하세요(긴 컨텍스트 가격 참조).

다음 예시는 Claude Opus 5.5의 정가로 요청 하나의 비용을 계산합니다. 다른 모델에는 세 가지 가격을 변경하세요.

INPUT_PER_MTOK = 4.00  # Claude Opus 5.5
# Claude Opus 5.5에서는 입력 가격의 0.05배이며, 배수는 모델마다 다릅니다
CACHE_READ_PER_MTOK = 0.20
OUTPUT_PER_MTOK = 20.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cache_writes = usage.cache_creation
writes_1h = cache_writes.ephemeral_1h_input_tokens if cache_writes else 0
writes_5m = cache_writes.ephemeral_5m_input_tokens if cache_writes else 0
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # 1시간 캐시 쓰기는 입력 가격의 2배, 5분 캐시 쓰기는 1.25배로 청구되며, 읽기는 캐시 읽기 가격으로 청구됩니다.
    + writes_1h * INPUT_PER_MTOK * 2.0
    + writes_5m * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * CACHE_READ_PER_MTOK
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

확인할 사항.

• 캐시 읽기 비중. 에이전트 루프에서는 대부분의 입력 토큰이 캐시 읽기여야 합니다. cache_read_input_tokens가 input_tokens와 cache_creation_input_tokens의 합에 비해 작다면, 캐싱이 활성화되어 있는지와 요청 간에 접두사가 동일하게 유지되는지 확인하세요.
• 어드바이저 도구와 압축. 어드바이저 도구 또는 압축이 활성화되면 일부 토큰은 최상위 합계가 아닌 usage.iterations에만 보고됩니다. 대신 usage.iterations에 걸쳐 합산하고, advisor_message 항목은 어드바이저 모델의 요율로 계산하세요.

다음 표는 시도할 순서대로 레버를 나열합니다. 수치는 Anthropic 자체 테스트에서 나온 것이며, 링크된 각 섹션과 그 참조 항목에 모델과 방법이 나와 있습니다.

Claude API 스킬로 검색 자동화하기

절감 방안을 찾기 전에 Claude API 스킬의 cost-optimize 명령을 실행하세요. 이 명령은 토큰이 어디에 사용되는지 프로파일링하고, 캐싱부터 시작해 레버를 순서대로 적용합니다. 그런 다음 평가가 들어 있는 디렉터리에서 /claude-api hillclimb를 실행하세요.

Anthropic은 tau2-bench retail²⁴에서 cost-optimize의 첫 번째 레버와 두 번의 검색을 측정했으며, 모두 이전 모델을 대상으로 했습니다. cost-optimize가 생성한 캐시 중단점은 작업당 비용을 줄였고, 통과율 하락 폭은 동일한 실행 간의 편차보다 작았습니다.

한 검색에서는 effort를 낮추고 모델 티어를 한 단계 내려 더 저렴한 구성을 찾았습니다. 이 구성의 통과율은 검색 전에 설정한 허용 범위 안에 작업 한 건에도 못 미치는 차이로 머물렀고, 검색이 자체 판정에 사용한 더 엄격한 하한선보다는 낮게 끝났습니다. 더 저렴한 모델을 기본 effort로 시작한 두 번째 검색에서는 채택된 변경이 하나도 없었습니다. 참조 24에 수치와 각 검색을 실행하는 데 든 비용이 나와 있습니다.

다음 차트는 첫 번째 검색의 모든 단계를 보여 줍니다.

검색 결과를 신뢰할 수 있는지는 두 가지 설정에 달려 있습니다.

• 검색이 읽지 않는 분할(split)을 따로 확보하세요. 검색은 그 분할에서 채택 여부를 판단하므로, 검증을 통해 검색이 본 작업에만 맞춰진 변경을 걸러낼 수 있습니다. 프롬프트 수정이 바로 그런 경우였습니다(참조 24).
• 첫 번째 변경 전에 기준선을 반복 측정하세요. 이번 측정에서는 하나의 시작 구성을 동일하게 실행해도 결과가 여러 작업만큼 달랐습니다(참조 24). 반복 측정은 검색의 채택 기준에 노이즈 기준선을 제공합니다.

참조된 벤치마크

참조에서 달리 명시하지 않는 한, 측정값은 이 벤치마크들을 Anthropic 내부에서 실행한 결과입니다. 별도 표기가 없으면 비용은 각 벤치마크를 실행할 당시 적용되던 정가 기준의 USD입니다. Claude Sonnet 5 수치는 입력 및 출력 토큰 100만 개당 $2 USD와 $10 USD를 사용합니다. 2026년 9월 24일 실행에서 나온 Claude Sonnet 5.5 수치는 동일한 입력 및 출력 가격을 사용하며, 출시 당시 가격인 100만 토큰당 $0.20 USD 대신 현재의 캐시 읽기 가격인 $0.10 USD를 각 실행에 기록된 토큰 수에 적용했습니다. 해당 실행은 Claude Sonnet 5.5의 사전 출시 빌드를 사용했으며, 그 실행에서는 어떤 시도도 폴백 모델이 응답하지 않았습니다. "notional USD"(가상 USD)로 표시된 차트는 청구서를 보고하는 것이 아니라 각 요청의 토큰 수에 이 가격을 적용해 산정한 값입니다.

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. 여러 행으로 이루어진 표의 완전성과 정확성으로 채점하는 광범위한 웹 리서치 작업이며, 200개 문제, 구성당 3회 실행, 2026년 8월 1일~2일에 실행했습니다. 이 벤치마크, DeepWideSearch(참조 6), BrowseComp(참조 4), GDPval(참조 2)에서 Claude Fable 5를 사용했을 때, low effort는 정확도가 1~3점 낮아지는 대신 작업당 비용이 3분의 1에서 절반 줄었고, medium은 기본값의 약 70%~87% 비용으로 기본값과 같은 정확도를 보였으며, 기본값은 네 가지 모두에서 medium보다 측정 가능한 이점을 주지 못했습니다. 비용 집중도 차트는 별도의 20개 문제 실행(문제당 3회 실행, 2026년 8월 3일~4일 실행)이며, 요청별 청구 기록으로 비용을 산정했습니다. 이 차트는 60회 실행 중 59회를 포함합니다. 총 $432.31 USD 중 $10.91 USD가 청구된 60번째 실행은 결과와 함께 기록된 비용이 없어 포함하지 않았습니다.
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. 작업 "rubric"(루브릭)에 따라 채점하는 지식 업무 결과물입니다. 공개된 골드 세트의 210개 작업을 작업당 1회 시도로 실행했으며, 2026년 8월 2일에 실행했습니다. Claude 모델이 채점하므로 절대 점수는 공개된 결과와 다를 수 있습니다.
3. SWE-bench Pro: Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025.
   • 측정 내용: Anthropic의 평가 하네스와의 호환성을 기준으로 선정한 482개 문제 하위 집합이며, 점수는 공개 리더보드와 비교할 수 없습니다. 또한 다른 문제 세트에서 max effort로 실행한 결과인 Claude Opus 5.5 시스템 카드의 SWE-bench Pro 결과와도 비교할 수 없습니다.
   • 가격 산정 방식: 이 하위 집합의 비용은 고객 조직이 계량되는 방식으로 산정했습니다. 즉 각 요청의 이전 프롬프트는 캐시 읽기로, 새 토큰은 5분 캐시 쓰기로 계산하며, 실행 자체의 사용량 기록을 사용하고 고객 원장과 대조해 확인했습니다.
   • Claude Opus 5.5 실행: Claude Opus 5.5 수치는 low, medium(기본값), high에서 각각 두 번 실행한 결과의 평균이고 xhigh에서는 한 번 실행한 결과를 사용하며, 모두 2026년 9월 19일~20일에 실행했고 8월의 Claude Opus 5 실행과 동일하게 턴당 16,384 토큰 상한을 적용했습니다. 이 상한으로 인해 xhigh 시도 2건이 중단되었고 다른 설정에서는 중단된 시도가 없었습니다. high와 비교하면 Claude Opus 5.5는 기본값인 medium에서 약 2.5점 낮은 점수를 받았고 작업당 비용은 약 70%였으며, low에서는 약 8점 낮은 점수에 비용은 약 3분의 1이었습니다. xhigh는 high보다 약 1.4점 높은 점수를 받았고 비용은 high의 2.5배였습니다. 비율은 반올림하지 않은 비용에서 계산했습니다.
   • 478개 문제: Opus 5.5 실행은 채점 컨테이너가 내부 패키지 미러에만 접근할 수 있는 버전의 벤치마크를 사용했습니다. 이 버전은 테스트에 실제 웹사이트가 필요한 문제 하나를 제외하며, 다른 세 문제에서는 참조 솔루션이 실패하므로, Opus 5.5 비교와 그 옆에 놓인 Claude Fable 5.1 수치는 나머지 478개 문제를 사용합니다.
   • Claude Sonnet 5.5 실행: Claude Sonnet 5.5는 동일한 버전의 벤치마크를 실행했습니다. 기본값인 high에서 두 번, medium에서 두 번 실행했으며, 모두 2026년 9월 24일에 실행했고 동일한 턴당 16,384 토큰 상한을 적용했으나 중단된 시도는 없었습니다. 수치는 478개 문제를 사용하며, 그 옆에 놓인 Claude Sonnet 5 수치도 8월 실행에서 해당 문제들에 대해 집계한 것입니다.
   • Claude Opus 5 실행: 모델 업그레이드와 이 참조에 나오는 Claude Opus 5 SWE-bench Pro 수치는 기본 effort에서 두 번 실행한 결과의 평균이며 low에서는 한 번 실행한 결과를 사용하고, 모두 2026년 8월 4일에 실행했습니다.
   • 어드바이저, Claude Sonnet 5 조합: 어드바이저 전략의 자문 비율 예시의 근거가 된 Claude Opus 5 어드바이저와 Claude Sonnet 5 실행자 조합은 이 하위 집합에서 같은 측정 시리즈로 얻은 것입니다. 기본 effort의 조합은 두 번(2026년 8월 7일과 8월 8일, 실행과 정확한 재현), 낮은 effort의 조합은 한 번(2026년 8월 8일), Claude Sonnet 5 단독은 두 번(77.4%, 두 조합의 기준선) 실행했습니다.
   • 어드바이저, Claude Sonnet 5.5 자문 확인: 어드바이저 전략에서 인용한 Claude Sonnet 5.5 자문 확인은 478개 문제 중 20개 문제 각각에 대해 한 번씩 시도했으며, 2026년 9월 24일에 어드바이저 도구를 통해 Claude Opus 5.5 어드바이저와 함께 실행했습니다. 네 가지 구성을 실행했습니다. high와 xhigh 각각에 대해 어드바이저 도구 문서가 코딩 작업용으로 제안하는 시스템 프롬프트를 사용한 경우와 사용하지 않은 경우입니다. 기본 effort인 high에서 Claude Sonnet 5.5는 프롬프트 사용 여부와 관계없이 20개 문제 중 어느 것에서도 어드바이저에게 자문을 구하지 않았습니다. xhigh에서는 프롬프트가 없을 때 20개 문제 중 3개, 있을 때 4개에서 자문을 구했으며, 매번 턴 수가 가장 많은 시도에서였습니다.
   • 에스컬레이션 수치: 에스컬레이션 수치는 Opus 5.5 실행에서 작업별로 산출했습니다. low로 먼저 시도하고 실패한 작업에 high를 적용하면 실행 조합에 따라 96.4%~97.5%를 해결했고 비용은 약 $0.17 USD였습니다. medium으로 먼저 시도하면 96.0%~97.1%에 약 $0.24 USD, 자신의 실패에 대해 high를 다시 실행하면 96.9%에 $0.31 USD, 모든 작업을 high로 실행하면 94.8%~95.8%에 $0.29 USD였습니다.
   • 모델 비교: 모델 비교의 Claude Fable 5.1 수치는 동일한 하위 집합에서 기본 effort로 2026년 8월 26일에 한 번 실행한 결과입니다. 478개 문제에 대해 집계하면 92.3%를 해결했고 해결된 작업당 $1.19 USD였습니다. 해당 섹션의 차트와 그 Claude Opus 5.5 및 Claude Sonnet 5.5 수치는 도표에 표시된 각 설정의 두 실행을 합산한 것이며, 모두 478개 문제에 대해 집계했습니다. Claude Opus 5.5는 low, medium, high, Claude Sonnet 5.5는 medium과 high입니다.
   • 모델 비교, 작업당 작업량: 이 수치에서 low의 Claude Opus 5.5는 기본값의 Claude Sonnet 5.5보다 작업당 수행한 작업이 적었습니다. Sonnet 5.5 출력 토큰의 절반을 조금 넘는 양과 캐시 읽기의 3분의 1을 조금 넘는 양이었습니다. 각자의 기본값에서 medium의 Opus 5.5는 Sonnet 5.5보다 약 5퍼센트포인트 더 많이 해결했고 비용은 약 두 배였습니다. 이 설정에서는 작업당 Sonnet 5.5보다 약간 더 많은 작업을 수행했습니다.
   • 모델 업그레이드, 실행: 모델 업그레이드의 Claude Fable 5 지점은 2026년 8월 26일에 기본 effort로 실행한 세 번의 실행을 합산한 것이며, 고객 조직이 계량되는 방식으로 가격을 산정했습니다. 업그레이드 사다리는 모든 모델을 각자의 출시 기본값으로 478개 문제에 대해 집계합니다. Opus 5, Opus 5.5, Sonnet 5, Sonnet 5.5(각각 두 번 실행)와 Fable 5(위에서 설명한 세 번 실행)를 제외하면 모델당 한 번 실행한 결과를 사용합니다. Opus 4.7, Opus 4.8, Sonnet 4.6, Sonnet 5 실행은 2026년 8월 17일~19일에, Opus 5 실행은 8월 4일에 실행했으며, 모두 하나의 하네스와 조직에서 실행했습니다. Opus 5.5와 Sonnet 5.5 실행은 이 참조의 앞부분에서 설명한 것입니다.
   • 모델 업그레이드, 해결된 작업당 비용: 해당 Claude Opus 5 실행을 8월 17일~19일 시리즈에서 출시 기본값으로 실행한 Claude Opus 4.8 한 번의 실행과 동일한 478개 문제에 대해 비교하면, Claude Opus 5는 해결된 작업당 Claude Opus 4.8보다 21% 더 비쌉니다. 차트의 SWE-bench Pro 패널에는 Claude Opus 4.7도 Claude Opus 4.8도 표시되지 않습니다. 같은 측정에서 고객이 청구받는 방식으로 가격을 산정하면, Claude Opus 5는 해결된 작업당 21% 더 비싼 대가로 Claude Opus 4.8보다 12점 더 많은 작업을 해결하고, Claude Opus 4.8은 Claude Opus 4.7과 같은 비율의 작업을 해결된 작업당 14% 더 적은 비용으로 해결하며, low effort의 Claude Opus 5는 이 벤치마크에서 해결된 작업당 비용의 약 30%로 Claude Opus 4.8의 기본값을 능가합니다.
   • 모델 업그레이드, 가격: 모델 업그레이드에서 Claude Sonnet 4.6 대비 Claude Sonnet 5의 절감은 더 낮은 토큰당 가격에서 나오며, 이는 작업당 더 많이 사용하는 토큰을 상쇄하고도 남습니다. Claude Sonnet 5.5는 캐시 읽기를 제외한 모든 항목에서 Claude Sonnet 5와 같은 요금을 부과하며, 캐시 읽기는 절반 가격입니다. Claude Opus 5.5의 토큰 가격은 Claude Opus 5보다 낮으며, 캐시 읽기에서 가장 큰 차이가 납니다. Claude Sonnet 5와 마찬가지로 프런티어 티어도 가격을 통해 이점을 얻었습니다. Claude Fable 5.1의 절감 대부분은 더 낮은 캐시 읽기 가격에서 나옵니다.
   • 캐싱 없는 비용, 기록된 토큰 수로 가격 산정: Anthropic은 캐싱이 가장 먼저인 이유의 캐싱 계수를 위해, 이 참조의 앞부분에서 설명한 Claude Opus 5.5 및 Claude Sonnet 5.5 실행의 기록된 토큰 수를 478개 문제에 대해 다시 가격 산정했으며, 캐싱을 끈 실행은 하지 않았습니다.
   • 모델별 계수: 각 계수는 모든 입력 토큰을 입력 가격으로, 출력 토큰은 그대로 두고 계산한 토큰 비용을 고객 조직이 계량되는 방식으로 산정한 비용으로 나눈 값입니다. Claude Opus 5.5는 medium에서 3.3, low에서 2.4, high에서 3.8, xhigh에서 5.4(한 번 실행)이며, Claude Sonnet 5.5는 캐시 읽기를 100만 토큰당 $0.10 USD로 했을 때 high에서 3.1, medium에서 2.4이고, 출시 가격인 $0.20 USD에서는 high에서 2.8입니다. 캐싱 차트의 실행과 달리 이 실행들에는 웹 검색 요금이 발생하지 않았으며, 작업의 첫 요청은 캐시 쓰기로 가격을 산정합니다.
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. Effort 수치는 500개 문제 구간을 사용하며, 설정당 1~3회 실행하고 2026년 8월 3일에 실행했습니다. 기본값 지점은 2026년 7월 26일~27일의 두 실행을 합산한 것입니다. 오케스트레이터 전략의 긴 비용 꼬리를 가진 일상적인 작업의 측정은 프로토콜이 고정되었을 때 모델이 단독으로 안정적으로 해결한 10개 문제를 사용하며, 26개 문제 구간에서 가져왔습니다. 위임 실행 50회(문제당 5회, 2026년 8월 1일~2일)와 모델 단독 실행 70회(2026년 8월 2일~3일 50회, 7월 12일~13일과 2026년 8월 1일의 보관된 20회)를 사용했고, 실행당 기대값으로 $6.45 USD 대 $11.99 USD이며, 위임 수치에는 약 20%의 측정 오차 범위가 있습니다. 10개 문제는 위임 구성(Claude Fable 5 오케스트레이터와 Claude Sonnet 5 워커 하나)이 5회 실행 모두에서 정답이었고 Claude Fable 5 단독이 보관된 두 번의 실행 모두에서 정답이었던 문제들입니다. 위임 실행은 바로 그 실행들이며, 이 열 개 문제에서 다시 실행한 것은 Claude Fable 5 단독뿐입니다. 보관된 실행과 새 실행을 합친 70회 실행 중 Claude Fable 5 단독은 68회 정답이었습니다. 이 문제들에서 위임 구성은 평균적으로 Claude Fable 5 단독의 약 절반 비용이 들었고(앞서 제시한 $6.45 USD와 $11.99 USD), 90번째 백분위수에서는 약 3분의 1(실행당 $12 USD 대 $33 USD)이었으며, 가장 비싼 실행은 $42 USD 대 $84 USD였습니다. 그 $84 USD 실행은 오답이기도 했습니다. 더 어려운 전체 BrowseComp 세트에서는 Claude Fable 5 단독이 해당 세트에서 측정한 오케스트레이터 구성의 정확도에 22%~30% 더 낮은 비용으로 도달했습니다.
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회 실행했으며 2026년 8월 2일에 실행했습니다(단일 워커 팀 지점은 2026년 7월 26일~27일에 실행). Claude Fable 5에서 low effort는 Claude Sonnet 5 워커를 둔 오케스트레이터와 29% 더 낮은 비용으로 동등한 결과를 냈고, 문제당 4.5분이 걸렸으며 기본값에서는 7.9분이 걸렸습니다.
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 Managed Agents에서 실행했습니다(2026년 8월 26일~27일).
   • 채점 방식: 어떤 구성도 거부하지 않은 33개 작업에 대해 채점했으며, 프로덕션 안전 분류기가 중간에 중단시킨 시도는 제외했습니다. Claude Opus 4.6이 벤치마크의 루브릭 프로토콜에 따라 판정합니다. 원본은 다른 판정자를 사용하며, Anthropic 판정자는 자사 스타일을 선호할 수 있습니다.
   • 점수: 점수는 각 모델이 자체적으로 선점된 작업을 제외한 33개 작업 기준의 평균입니다. 어떤 구성에서도 시도가 중단되지 않은 33개 중 21개 작업에서는 Claude Fable 5.1이 모든 effort 수준에서 Claude Fable 5보다 2~3점 앞서며 두 모델 모두 effort에 따라 변화가 없습니다.
   • 가격 산정 방식: 비용은 고객 조직이 계량되는 방식으로 산정했습니다. 각 요청의 이전 프롬프트는 캐시 읽기로, 새 토큰은 5분 캐시 쓰기로 계산하며, 세션의 첫 요청은 받은 캐시 읽기를 그대로 유지하고, 실행 자체의 사용량 기록을 사용하며, 여기에 플랫폼의 웹 검색 요금을 더했습니다. 작업당 비용은 50개 작업 실행의 비용을 50으로 나눈 값이며, 중단된 시도를 포함하고 세 번의 실행에 대해 평균을 냈습니다.
   • 결과, Claude Fable 5: Claude Fable 5는 같은 방식으로 가격을 산정했을 때 low에서 작업당 $2.30 USD, high에서 $4.71 USD였습니다. 모델 업그레이드의 백분율은 반올림하지 않은 비용에서 나온 것입니다.
   • 결과, Claude Opus 5: 기본 effort의 Claude Opus 5는 같은 환경과 하위 집합에서 2026년 8월 28일에 세 번 실행했습니다. 원래 50개 작업에서 68.8%, 33개 작업 기준에서 70.8%, 21개 작업 세트에서 71.1%였고, 작업당 $6.28 USD(캐싱 없이는 $23.72 USD)였습니다. 다른 모델이 실행된 것보다 더 새로운 안전장치 배포 아래에서 안전 분류기에 의해 중단된 시도는 없었습니다.
   • 모델 비교: 모델 비교의 리서치 비교는 다음 수치에 근거합니다. low의 Claude Fable 5.1은 33개 작업 기준에서 Claude Sonnet 5보다 10점 높은 점수(66% 대 56%)를 받았고, 50개 작업 전체에 대한 작업당 비용은 약 네 배였습니다($4.48 USD 대 $1.18 USD). 이 참조의 앞부분에 점수와 비용이 제시된 기본값의 Claude Opus 5는 기본값의 Claude Fable 5.1보다 높은 점수를 받았으며, 후자는 33개 작업 기준에서 65%를 받았고 50개 작업 전체에 대해 작업당 $6.89 USD가 들었습니다. 따라서 리서치에서 Claude Fable 5.1은 low에서만 그 가격값을 합니다.
   • 캐싱 차트: 캐싱 차트는 동일한 요청을 모든 입력 토큰에 캐시되지 않은 요율을 적용해 다시 가격 산정합니다.
   • 측정하지 않음: Claude Sonnet 5.5는 이 벤치마크에서 측정하지 않았습니다.
8. 코퍼스 결함 스윕: Anthropic 내부 벤치마크이며, 하나의 컨텍스트 윈도우보다 큰 작업을 위한 것입니다. 14개 공개 Python 패키지 소스에서 가져온 2,160만 토큰 코퍼스에 130개의 심어 둔 결함이 있고 결정론적 채점을 사용하며, 프로토콜은 실행 전에 고정하고 내부 검토를 거쳤으며, 구성당 세 번 실행했습니다. 모든 구성은 Claude Managed Agents에서 실행했습니다. 차트에 표시된 팀 구성은 Claude Fable 5.1 오케스트레이터가 플랫폼의 문서화된 한도인 동시 Claude Sonnet 5 워커 25개로 플랫폼 내부에서 전체 스윕을 실행한 구성이며, 2026년 8월 30일에 실행했습니다. 세 번의 실행은 추가 항목 감사 후 F1 0.764, 0.825, 0.791(원점수 0.751, 0.821, 0.781)을 기록했고 비용은 $225 USD, $234 USD, $283 USD였습니다. 팀 구성은 low, medium, high의 Claude Fable 5.1 단독보다 비용이 약 절반(47%~55% 적음)이었고, 점수는 10~12점 낮았으며, 실행당 약 2.3시간이 걸렸고 단독은 15~20시간이 걸렸습니다. 팀 구성은 실행당 약 5억 6천만 개의 캐시된 토큰을 읽었으며, 거의 전부 Claude Sonnet 5의 캐시 읽기 요율이었습니다. 이는 Claude Fable 5.1이 단독으로 읽은 약 3억 6,500만 개의 약 1.5배입니다. high effort의 Claude Fable 5.1 단독은 여전히 최고 정확도를 유지하며 팀 구성 비용의 약 2.2배가 들므로, 여기서 위임은 정확도의 대부분을 얻게 해 주지만 전부는 아닙니다. Claude Sonnet 5 단독 구성은 2026년 8월 3일~4일에 실행했고, Claude Fable 5.1 단독 구성은 2026년 8월 24일~25일에 플랫폼의 출시 서빙 설정으로 effort 설정당 세 개의 시드로 동일한 코퍼스 빌드에서 실행했습니다. 샌드박스 이미지에는 코퍼스 일부의 설치된 사본이 들어 있었고, Claude Fable 5.1의 최종 조립 단계는 9회 실행 중 7회에서 이를 대조했으며, 이러한 추가분 없이 다시 채점하면 영향을 받은 시드가 최대 3점 움직였습니다. 절대 F1은 이 코퍼스 빌드에 고유하며 벤치마크 간에 비교할 수 없고, 구성 간 비교는 동일 조건입니다.
9. GPQA Diamond: Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023. 198개 질문의 Diamond 하위 집합이며, 참조 답안에 대해 모델이 채점하고 어드바이저 토큰은 요청별로 계량합니다. Claude Haiku 5.5와 Claude Sonnet 5.5는 각각 단독 및 Claude Opus 5.5 어드바이저와 함께, Claude Opus 5.5는 단독으로 구성당 두 번씩 2026년 10월 7일에 실행했으며, 모두 서버 측 폴백을 끄고 각 모델의 기본 effort로 실행했으며 거부는 오답으로 계산했습니다. 플랫폼 안전 검사는 Claude Haiku 5.5와 Claude Sonnet 5.5 단독에서 실행당 생물학 질문 하나를, 어드바이저를 둔 Haiku 5.5에서는 두 번의 실행 중 한 번에서 하나를, 어드바이저를 둔 Sonnet 5.5에서는 하나도 거부하지 않았고, Opus 5.5에서는 실행당 여섯 개를 거부했으며, Opus 5.5는 이를 오답으로 계산하면 91%, 답변한 질문에 대해서는 93.5%를 기록했습니다. Claude Haiku 5.5 단독은 85%로 Opus 5.5보다 6점 낮았습니다. 어드바이저 구성은 자문을 요청하는 프롬프트 없이 도구를 추가했으며, 어느 실행자도 어떤 질문에서도 어드바이저를 호출하지 않았습니다. 조합은 실행자 단독보다 0.5점(Claude Haiku 5.5)과 1.0점(Claude Sonnet 5.5) 높았으며, 둘 다 실행 간 노이즈 범위 내입니다.
10. DeepSWE: Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026. 이 세트는 다섯 개 언어에 걸친 113개의 독창적인 작업과 프로그램 기반 검증기를 갖추고 있습니다. 조합은 각각 두 번씩 2026년 8월 7일에 실행했으며 어드바이저 토큰은 요청별로 계량했고, 어드바이저 도구 대신 클라이언트 측 어드바이저 루프를 사용했으며 회계 처리는 동일합니다. 단일 모델 effort 스윕은 토큰 수로 가격을 산정한 단일 실행이며, 캐시를 고려한 근사치입니다. 작업당 비용은 실행 총액을 113으로 나눈 값입니다. 이 벤치마크에서 어드바이저를 둔 낮은 effort의 Claude Sonnet 5 실행자는 동일한 실행자 단독보다 23점 높은 점수를 받았습니다.
11. 내부 에이전트 코딩 벤치마크:
    • 측정 내용: Anthropic 내부 벤치마크이며, 저장소 자체 테스트로 채점하는 370개 저장소 작업입니다. API 수치는 일반 API 에이전트와 128,000 토큰 출력 상한으로 구성당 한 번 실행해 측정했습니다. 기본 effort의 Opus 5 단독은 2026년 8월 9일~10일에, low와 medium은 2026년 8월 10일에, 명시적으로 설정한 다섯 가지 effort 값의 Claude Fable 5.1 단독은 2026년 8월 20일에(차트에는 그중 세 가지를 표시), 조합은 2026년 8월 24일~25일에 실행했습니다.
    • 8월 실행: 8월 실행은 조합과 Claude Opus 5 대조군에 대해 작업당 다섯 번 시도했고 다른 지점에 대해서는 한 번 시도했습니다.
    • 가격 산정 방식: 비용은 시도당입니다. 비용은 고객 조직이 계량되는 방식으로 산정했습니다. 각 에이전트 루프 요청의 이전 프롬프트는 캐시 읽기로, 새 토큰은 5분 캐시 쓰기로 계산하며, 실행 자체의 사용량 기록을 사용하고, 캐시를 사용하지 않는 각 어드바이저 호출은 기록된 토큰으로 계산하며, 모두 정가를 적용했습니다.
    • Claude Opus 5.5 단독: Claude Opus 5.5 단독은 2026년 9월 19일~20일에 370개 작업 전체에서 실행했습니다. 기본 effort(medium)와 high에서는 작업당 다섯 번 시도했고, low와 xhigh에서는 한 번 시도했습니다(설정 확인 실패 후 각각 370개 중 369개가 채점됨). Claude Opus 5.5 단독은 low에서 시도의 74.8%를 시도당 $0.35 USD로, medium에서 86.6%를 $0.84 USD로, high에서 88.4%를 $1.38 USD로, xhigh에서 91.1%를 $4.11 USD로 해결했습니다.
    • Claude Fable 5.1 어드바이저를 둔 Claude Opus 5.5, 실행: 출시된 Claude Fable 5.1을 어드바이저로 둔 high의 Claude Opus 5.5 실행자(8월 실행은 사전 출시 스냅샷을 사용)는 같은 날짜에 작업당 다섯 번 시도했으며, 한 작업이 설정 확인에 실패해 1,845건의 시도가 채점되었습니다. 부하로 인해 어드바이저가 거절된 279건의 시도는 다시 실행했고, 8월과 마찬가지로 자문이 시간 초과된 시도는 유지했습니다.
    • Claude Fable 5.1 단독: 비교를 위해, 출시된 Claude Fable 5.1 단독은 기본값인 high에서 2026년 10월 7일에 작업당 한 번 시도해 85.7%(370개 작업 중 317개)를 기록했습니다.
    • 자문: 8월 조합은 시도당 평균 약 두 번의 어드바이저 자문을 했고, Claude Opus 5.5 조합은 1.39회를 요청해 1.35회를 받았습니다.
    • Claude Fable 5.1 어드바이저를 둔 Claude Opus 5.5, 결과: Claude Opus 5.5 조합은 시도당 $2.92 USD에 90.1%를 기록했습니다. 기본값인 medium의 Claude Opus 5.5와 비교하면 3.5점을 위해 약 3.5배의 비용이 든 셈입니다. 지연 시간 비용은 자문 자체입니다. 작업당 약 한두 번의 추가 프런티어 모델 호출이며, 각각 작업의 임계 경로에 있습니다. Claude Opus 5.5 실행자에서는 조언이 실행자 비용을 거의 절감하지 못했습니다. high의 Claude Opus 5.5 단독이 시도당 $1.38 USD인 데 비해 시도당 $1.36 USD였고, 자문 비용은 $1.55 USD였습니다.
    • 8월 조합: 8월에 Claude Opus 5 실행자와 Claude Fable 5.1 어드바이저를 둔 조합에서 실행자는 기본값의 Claude Opus 5 단독보다 시도당 $1.26 USD를 덜 썼고 자문 비용은 $2.47 USD였으므로, 그 절감분은 조언 비용의 약 절반을 충당했습니다. 그 8월 조합은 당시 측정된 구성 중 가장 정확했으며 시도당 $6.21 USD였습니다.
    • Claude Sonnet 5.5 단독, 실행: Claude Sonnet 5.5 단독은 2026년 9월 24일에 370개 작업 전체에서 기본 effort(high)와 medium으로 작업당 한 번 시도했으며, 동일한 128,000 토큰 출력 상한을 적용했으나 중단된 시도는 없었습니다. medium에서는 370개 전부가, high에서는 설정 확인 실패 후 370개 중 369개가 채점되었습니다. 비용은 고객 조직이 계량되는 방식으로 산정했습니다.
    • Claude Sonnet 5.5 단독, 결과: 어드바이저가 없을 때 Claude Sonnet 5.5는 기본값인 high에서 시도당 $0.33 USD에 77.8%를 기록했으며, 이는 기본값의 Claude Opus 5.5보다 약 9점 낮고 비용은 약 5분의 2입니다. medium에서는 시도당 $0.16 USD에 62.7%를 기록했습니다. medium에서 Claude Sonnet 5.5는 기본값인 high보다 약 15점 낮은 점수를 받았고 시도당 비용은 약 48%였습니다.
    • 모델 비교: 모델 비교에서 기본값의 Claude Opus 5.5는 시도당 비용이 medium의 Claude Fable 5.1의 3분의 1 미만이었으며, 이는 단일 실행입니다.
12. 내부 저장소 작업 벤치마크(상한 측정):
    • 측정 내용: 약 130개 저장소 작업으로 이루어진 별도의 Anthropic 내부 세트이며, 2026년 8월 20일(Claude Fable 5.1)과 2026년 9월 19일(기본 effort인 medium의 Claude Opus 5.5)에 일반 API 에이전트 루프로 작업당 한 번 시도해 실행했습니다.
    • 가격 산정 방식: 해결된 작업당 비용은 Claude Fable 5.1의 경우 5분 프롬프트 캐시로 고객이 청구받는 방식으로, Claude Opus 5.5의 경우 실행이 기록한 토큰 수에서 정가로 산정했습니다.
    • Claude Fable 5.1 실행: Claude Fable 5.1 실행은 기본 effort를 명시적으로 설정해 상한당 135개 작업입니다. 16,384 토큰 수치는 두 번 실행의 평균(둘 다 36.3%)이고, 64,000 및 128,000 수치는 단일 실행(58.5%와 60.0%)입니다. 다섯 개 문제는 네 번의 실행 모두에서 안전 거부를 받았으며 실패로 계산합니다.
    • Claude Opus 5.5 실행: Claude Opus 5.5의 16,384 토큰 수치는 두 번 실행의 평균(134개와 135개 작업이 채점됨)이고, 64,000 및 128,000 수치는 단일 실행(각각 135개 작업)입니다. 16,384 토큰 실행마다 두 건, 64,000 및 128,000 토큰 실행마다 한 건의 시도가 안전 거부로 끝났으며 실패로 계산합니다. Claude Opus 5.5는 16,384에서 57.6%(58.2%와 57.0%), 64,000에서 75.6%, 128,000에서 68.9%를 해결했습니다. 64,000 또는 128,000에서는 중단된 시도가 없었으므로, 상한으로는 이 두 실행 간의 차이를 설명할 수 없습니다.
    • 상한으로 종료된 시도: 16,384 토큰 상한으로 종료된 Claude Opus 5.5 시도 66건 중 1건, Claude Fable 5.1 시도 117건 중 9건만이 여전히 통과했습니다.
    • 시도당 비용: 시도당 비용은 Claude Opus 5.5의 경우 정가 기준으로 16,384에서 $3 USD, 64,000에서 $4 USD였고, Claude Fable 5.1의 경우 고객이 청구받는 방식으로 $8 USD와 $13 USD였습니다.
    • SWE-bench Pro 상한 수치: SWE-bench Pro 상한 수치는 참조 3의 482개 문제 세트에서 층화한 100개 문제 하위 집합에서 기본 effort로 2026년 8월 26일에 상한당 한 번 실행한 Claude Fable 5.1 결과이며, 그 점수와 비교할 수 없습니다. 기본 effort에서 16,384와 64,000의 실행은 각각 100개 문제 중 94개를 해결했습니다.
    • 턴 길이: 이 섹션의 점 도표에 나오는 턴별 분포는 128,000에서의 Claude Opus 5.5 및 Claude Fable 5.1 실행에서 나온 것입니다. Opus 5.5 턴은 상한에 도달한 것이 없었고(가장 긴 것은 약 61,000 토큰이었으며 턴의 0.56%가 16,384를 초과), Fable 5.1 턴 하나가 128,000에 도달했습니다(턴의 0.46%가 16,384를 초과). 상한이 128,000일 때 Claude Fable 5.1의 14,331개 턴 중 2개가 64,000 토큰보다 길었고, Claude Opus 5.5 턴은 하나도 그렇지 않았습니다.
13. Chartography: Surge AI, "Chartography," 2026.
    • 측정 내용: 공개된 100개 질문 세트 전체이며, 2026년 8월 6일과 9일(Claude Opus 5 단독) 및 2026년 9월 20일(Claude Opus 5.5)에 Claude Managed Agents에서 Anthropic의 구현으로 측정했습니다(표준 클라우드 샌드박스, 어드바이저 구성은 Managed Agents 어드바이저 사용).
    • 채점 방식: 참조 판정자 대신 Claude Sonnet 4.6이 채점하고 벤치마크는 도구와 함께 실행되므로, 점수는 여기서 구성 간에는 비교할 수 있지만 공개 리더보드와는 비교할 수 없습니다. 또한 다른 채점자를 사용하고 max effort로 실행한 Claude Opus 5.5 시스템 카드의 Chartography 결과와도 비교할 수 없습니다. 구성당 두 번 실행(Claude Opus 5.5는 세 번)을 합산했으며, 실행 간 편차는 최대 10점이었습니다.
    • 가격 산정 방식: 비용은 에이전트를 일상적으로 실행하는 고객이 청구받는 금액입니다. 각 차트의 첫 요청은 같은 에이전트의 다른 세션이 이전 5분 이내에 실행되었을 때처럼 에이전트의 공유 시스템 프롬프트와 도구를 캐시에서 읽습니다. 차트를 단독으로 실행하면 Claude Opus 5 또는 Claude Opus 5.5에서는 약 $0.03 USD, Claude Fable 5.1에서는 약 $0.12 USD 더 듭니다. 8월 수치는 실행의 사용량 기록에서 이 방식으로 다시 가격 산정했습니다. 비용에는 샌드박스 시간이 제외되며, 8월 실행에서 샌드박스 시간이 추가한 비용은 1% 미만이었습니다.
    • Claude Fable 5.1 단독, 8월 실행: Claude Fable 5.1 단독 실행은 2026년 8월 24일에 플랫폼의 출시 서빙 설정으로 설정당 두 번 실행한 것입니다. 여섯 건의 시도가 15분 세션 상한에 도달해 0점을 받았고, 실행당 두 개의 차트는 안전 거부 후 Claude Opus 5가 응답했습니다.
    • Claude Fable 5.1 어드바이저를 둔 Claude Opus 5: Claude Fable 5.1 어드바이저를 둔 Claude Opus 5 낮은 effort 실행자는 2026년 8월 30일에 동일한 설정으로 두 번 실행했습니다(63.0과 67.0, 평균 65.0, 차트당 $0.47 USD. 각 실행에서 작업의 88%에서 어드바이저에게 자문을 구했고, 219개 응답 중 4개는 프로덕션 안전 필터가 어드바이저 자체의 응답을 중단시킨 후 Claude Opus 5가 대신 응답한 것입니다). 그 조합은 medium의 Claude Fable 5.1 단독과 실행 간 노이즈 범위 내에서 동등했으며(65.0 대 67.5), 작업당 비용은 약 1.8배였습니다. 대부분의 작업에서 발동하는 자문은 더 강력한 모델을 직접 실행하는 것보다 비용이 더 듭니다.
    • Claude Opus 5.5 실행: Claude Opus 5.5는 서버 측 폴백을 끄고 안전 분류기가 모든 도구 호출을 판정하는 상태에서 low로 실행했습니다. 단독 세 번(70, 68, 68)과 Claude Fable 5.1 어드바이저를 구성한 세 번(59, 63, 63)이며, 후자에서는 300개 작업 중 1개에서 어드바이저에게 자문을 구했습니다.
    • low effort 결과: 이 차트 읽기 벤치마크에서 low의 Claude Opus 5.5는 차트당 약 $0.03 USD에 68.7점을 받았고, low의 Claude Fable 5.1은 $0.15 USD에 62.5점, low의 Claude Opus 5는 $0.16 USD에 49점이었습니다.
    • Claude Fable 5.1 단독, 10월 실행: Claude Opus 5.5 조합과의 비교를 위해, 기본값인 high의 Claude Fable 5.1 단독을 Claude Opus 5.5 실행과 동일한 구현 및 플랫폼 설정으로 2026년 10월 7일에 세 번 실행했습니다. 82, 79, 79이며 평균은 80.0입니다.
    • 자문 비율: 이전 조합의 자문 비율 비교는 컨테이너 도구 세트를 사용하는 Messages API에서 동일한 구성을 2026년 8월 10일~11일에 다시 실행한 결과입니다.
14. 지원 데스크 프롬프트 감사 평가:
    • 측정 내용: 결정론적 채점을 사용하는 Anthropic이 구성한 44개 지원 티켓 세트이며, 2026년 8월 초에 실행해 2026년 8월 8일에 보고했습니다. 여섯 개의 시스템 프롬프트 아래에서 실행했으며, 각각은 동일한 깨끗한 프롬프트에 Claude Opus 4.8과 Claude Sonnet 4.6용으로 작성된 프롬프트에서 흔한 패턴 하나를 추가한 것입니다.
    • 차트: 각 차트 지점은 세 가지 경우(이전 모델, 동일한 프롬프트의 새 모델, 감사 후의 새 모델) 중 하나를 여섯 개 프롬프트와 44개 티켓에 대해 평균한 것입니다.
    • 결과, Claude Opus 5: Claude Opus 5에서 Claude Opus 4.8용으로 작성된 프롬프트는 Claude Opus 4.8에서보다 티켓당 36% 더 비쌌고 정확도에는 변화가 없었습니다. 감사 후에는 감사 전보다 Claude Opus 5에서 14% 더 저렴했으며(반올림하지 않은 평균에서 계산한 값이며, 차트의 반올림된 비용인 티켓당 3.43센트와 2.93센트로는 14.6%), Claude Opus 5는 티켓의 97%를 올바르게 해결해 92%에서 상승했습니다. 패턴별로 Claude Opus 5에서 "verify twice"를 제거하면 티켓당 비용이 3분의 1 줄었고, "be maximally thorough"를 제거하면 거의 그만큼 줄었습니다. 종료된 사고 설정, 모순되는 규칙, 직접 만든 스크래치패드를 각각 제거하면 정확도가 7~11점 회복되었습니다.
    • 결과, Claude Sonnet 5: Claude Sonnet 4.6에서 Claude Sonnet 5로의 마이그레이션에서 감사는 동일한 정확도로 티켓당 비용을 14% 줄였습니다.
    • 주의 사항: Opus 5 정확도 향상의 95% 신뢰 구간은 3~8점이며, Sonnet 정확도 차이는 노이즈 범위 내입니다.
15. 데이터 파일 질문 세트: 공개 주류 판매 CSV의 1,862행 슬라이스에 대한 25개의 집계 질문으로 이루어진 Anthropic이 구성한 세트이며, 정답은 pandas로 계산하고 정확 일치로 채점합니다. 사고를 비활성화한 Claude Sonnet 5와 Claude Opus 5에서 실행했고(컨텍스트 내 방식은 기본값에서는 완료할 수 없음), 4,000 토큰 출력 상한을 적용했으며 프롬프트 캐싱은 사용하지 않았고, 구성당 세 번 실행해 2026년 8월 19일에 실행했습니다. 파일 방식은 Files API를 통해 CSV를 업로드하고 code_execution_20260120 도구를 사용합니다. 컨텍스트 내 방식의 Claude Sonnet 5 세 번의 실행은 25개 질문 중 6, 7, 7개에 올바르게 답했으며, 차트의 레이블과 본문은 그 평균인 6.67을 가장 가까운 질문 수로 제시하고, 차트의 점은 평균인 26.7%에 그려져 있습니다.
16. 캐시 지속 시간 측정:
    • 측정 내용: 입력 및 컨텍스트 토큰 줄이기의 20개 이슈 분류 작업을 2026년 8월 23일에 Claude Sonnet 5에서, 2026년 9월 19일과 20일에 기본 effort(medium)와 high의 Claude Opus 5.5에서 Messages API로 동일한 하네스(Claude Opus 5.5의 경우 동일한 요청 본문을 보내는 포팅 버전)로 실행했으며, Claude Opus 5.5 셀은 max_tokens를 4,096으로 올렸고, 무작위로 선택한 일부 턴 앞에 일시 중지를 삽입했습니다(두 모델 모두에서 20개 이슈 전체에 대해 없음, 5%, 10%, 6분의 모든 턴, 그리고 Claude Sonnet 5에서는 2분의 모든 턴 추가. 두 모델 모두에서 5개 이슈 하위 집합에 대해 20분 및 45분 일시 중지). 이 페이지의 Claude Opus 5.5 수치는 두 effort 수준을 모두 포함합니다.
    • 다른 모델과 날짜: 아래의 Claude Opus 5 keep-alive 수치는 2026년 8월 23일에 max_tokens를 4,096으로 올려 동일한 작업에서 나온 것이며, 2분 및 45분 일시 중지를 제외하고 동일한 일정을 사용했습니다. Claude Sonnet 5.5는 Claude Sonnet 5와 동일한 측정(동일한 일시 중지 일정과 세 가지 캐시 설정, 셀당 세 번 실행)을 Claude Opus 5.5에 사용한 포팅 하네스로 기본 effort인 high에서 2026년 9월 24일에 실행했습니다.
    • 채점 및 가격 산정 방식: 셀당 세 번 실행했으며, 비용은 각 응답의 usage 필드에서 정가로 계산했고(Claude Opus 5.5의 경우 100만 토큰당 입력 $4 USD, 5분 쓰기 $5 USD, 1시간 쓰기 $8 USD, 캐시 읽기 $0.20 USD, 출력 $20 USD. Claude Sonnet 5는 사용량이 고객 조직과 동일한 방식으로 계량되는 Anthropic 내부 조직에서 실행), 정확도는 동일한 골드 레이블에 대해 측정했습니다.
    • 실행 및 가격 산정 방식, Claude Sonnet 5.5: Claude Sonnet 5.5는 세션 요청에서 max_tokens를 4,096으로, keep-alive 요청에서 1로 설정했고, 사용량이 고객 조직과 동일한 방식으로 계량되는 Anthropic 내부 조직에서 실행했으며, 현재 정가(100만 토큰당 입력 $2 USD, 5분 쓰기 $2.50 USD, 1시간 쓰기 $4 USD, 캐시 읽기 $0.10 USD, 출력 $10 USD)로 가격을 산정했습니다. 어떤 턴도 도달하지 않은 더 높은 max_tokens를 제외하면, Claude Sonnet 5 실행과 입력이 하나 다릅니다. 작업의 유일한 애니메이션 GIF를 API가 사용하는 유일한 프레임인 첫 프레임의 PNG로 보냈으며(비전), 둘은 동일한 수의 입력 토큰으로 계산됩니다.
    • 손익분기점: 손익분기점은 Claude Sonnet 5에서 턴의 약 3.3%, Claude Opus 5.5에서 3.1%~3.2%입니다. 이는 각 세션의 턴별 컨텍스트 크기로 비용 모델이 계산한 세션별 손익분기 비율의 중앙값이며, Claude Sonnet 5의 20개 이슈 세션 45개 전체와 각 effort 수준에서 Claude Opus 5.5의 20개 이슈 세션 36개 전체에 대한 값입니다(전체 작업에서 실행한 모든 일시 중지 일정, 세 가지 캐시 설정 모두, 각각 세 번 실행. 5개 이슈 셀은 포함되지 않음). Claude Sonnet 5.5의 손익분기점은 턴의 약 3.1%이며, 20개 이슈 세션 45개에 대한 중앙값입니다. 캐시 지속 시간 차트는 이 Claude Sonnet 5.5 세션들을 지점당 세 개씩 표시합니다.
    • 5분 및 1시간 설정, Claude Sonnet 5 및 Claude Opus 5.5: 5% 셀에서 Claude Sonnet 5는 5분 설정과 1시간 설정이 동률이었는데, 그 추첨의 일시 중지가 작은 접두사에 해당했기 때문입니다. Claude Opus 5.5에서는 거의 동률이었습니다. Claude Sonnet 5에서 캐시 읽기 가격이 100만 토큰당 $0.20 USD일 때, 세션 비용은 5분 설정에서 일시 중지 없음, 턴의 5%, 10%가 일시 중지된 경우 각각 $0.60 USD, $0.69 USD, $0.99 USD였고, 1시간 설정에서는 $0.70 USD, $0.70 USD, $0.71 USD였습니다.
    • Keep-alive 요청, Claude Sonnet 5 및 Claude Opus 5: Anthropic은 5분 캐시를 갱신하는 keep-alive 요청을 2026년 8월 23일에 Claude Sonnet 5와 Claude Opus 5에서, 그리고 위의 실행에서 Claude Opus 5.5에서 측정했으며, 항상 max_tokens: 1로 보냈습니다. Claude Sonnet 5에서는 턴의 5%가 일시 중지된 경우 1시간 설정보다 7.7% 저렴했고 10%에서는 거의 같았으며, Claude Opus 5에서는 어느 비율에서도 측정 가능한 차이가 없었고, 두 모델 모두에서 모든 턴 앞에 6분 이상의 일시 중지가 있으면 비용이 더 들었습니다. 따라서 이 두 모델에서 사용할 설정은 keep-alive 요청이 아니라 1시간 지속 시간입니다.
    • Keep-alive 요청, Claude Opus 5.5: Claude Opus 5.5에서 keep-alive 요청은 턴의 5%와 10%가 일시 중지된 경우 1시간 설정보다 8%~18% 저렴했고(기본 effort인 medium에서 8%~13%, high에서 10%~18% 저렴. 각 keep-alive 세션 자체의 토큰을 1시간 캐시 가격으로 다시 청구해 세션 간 노이즈를 제거하면 약 10%~15%), 모든 턴 앞에 일시 중지가 있는 경우에는 더 비쌌습니다. 6분에서 4%~6%, 20분에서 9%~10%, 45분에서 56%~58% 더 비쌌습니다.
    • max_tokens: 0 요청, Claude Opus 5.5: Claude Opus 5.5에 대한 Anthropic의 출시 전 API 테스트는 max_tokens: 0 요청이 캐시를 쓰고 다음 요청이 이를 읽는다는 것을 보여 주지만, 그러한 요청이 기존 항목을 갱신하는지는 Opus 5.5에서 측정하지 않았습니다.
    • 5분 및 1시간 설정, Claude Sonnet 5.5: 턴의 5%가 일시 중지된 경우 5분 설정은 평균적으로 1시간 설정보다 5% 더 비쌌으며(세 번의 실행에 걸쳐 2% 저렴에서 12% 비쌈까지), 이는 실행 간 변동 범위 내입니다. 그 추첨의 일시 중지는 Claude Sonnet 5에서처럼 작은 접두사에 해당했으며, 각 5분 세션 자체의 토큰을 1시간 캐시 가격으로 다시 청구하면 약 1% 더 비쌉니다. 10%가 일시 중지된 경우에는 54% 더 비쌌습니다(36%~73% 더 비쌈). 일시 중지가 없을 때 5분 설정은 평균적으로 1시간 설정보다 19% 저렴했으며(세 번의 실행에 걸쳐 3%~32% 저렴. 1시간 설정의 더 높은 쓰기 가격으로 예측되는 값은 약 20%), 2분 일시 중지에서는 모든 실행에서 21%~24% 저렴했습니다.
    • Keep-alive 요청, Claude Sonnet 5.5: Keep-alive 요청은 턴의 5%가 일시 중지된 경우 평균적으로 1시간 설정보다 16% 저렴했고(세 번의 실행에 걸쳐 13%~20% 저렴), 10%에서는 8% 저렴했으며(3%~10% 저렴), 모든 턴 앞에 6분 이상의 일시 중지가 있으면 비용이 더 들었습니다. 턴의 5%와 10%가 일시 중지된 경우 일시 중지는 Claude Sonnet 5.5와 Claude Opus 5.5에서 6~32분 지속되었습니다. 위의 Claude Opus 5.5와 마찬가지로 각 keep-alive 세션 자체의 토큰을 1시간 캐시 가격으로 다시 청구하면 5% 일시 중지에서 15%~16% 저렴하고 10%에서 약 10% 저렴하며, 모든 턴 앞에 일시 중지가 있는 경우 6분에서 7% 더 비싸고 20분에서 9%~10% 더 비싸며 45분에서 66%~73% 더 비쌉니다. 6분 수치는 3번 실행을 제외한 것입니다. 그 세션의 39개 keep-alive 요청 중 2개가 시간 초과되어 그 두 턴 전에 캐시가 만료되었고, 세션은 1번과 2번 실행의 80,000~85,000 토큰에 비해 214,000 토큰을 캐시에 썼으며, 3번 실행의 1시간 세션보다 38% 더 들었습니다.
    • Keep-alive 요청, Claude Sonnet 5.5, 실행별: 대신 각 실행의 keep-alive 세션을 같은 실행의 1시간 세션과 비교하면, keep-alive 비용은 6분에서 거의 같음에서 10% 더 비쌈까지(1번과 2번 실행. 두 실행의 평균으로는 4% 더 비쌈), 20분에서 거의 같음에서 16% 더 비쌈까지, 45분에서 64%~80% 더 비쌌습니다.
    • Keep-alive 요청, Claude Sonnet 5.5, 표본 크기: Keep-alive 차트의 6분 지점은 세 가지 설정 모두에서 1번과 2번 실행을 평균한 것입니다. 각 셀은 세션 세 개입니다(위의 6분 수치는 두 개). 일시 중지가 없을 때 keep-alive는 추가 요청을 보내지 않으므로 5분 설정과 일치하지만, 둘은 단일 실행 내에서 최대 23%까지 차이가 났으므로 세 번 실행 평균에서 몇 퍼센트의 차이는 명확한 효과가 아닙니다.
    • 캐싱 끔과 켬, Claude Sonnet 5: Claude Sonnet 5에서 동일한 작업을 캐싱을 끈 상태와 켠 상태로 각각 세 번씩 2026년 8월 19일에 max_tokens를 700으로 하여 실행했습니다. 세션당 평균 $3.36 USD 대 $0.57 USD로 83% 절감되었습니다.
    • 기록된 토큰 수로 가격 산정, Claude Sonnet 5.5: Anthropic은 캐싱이 가장 먼저인 이유의 캐싱 수치를 위해, 5분 캐시를 사용하고 일시 중지가 없는 세 개의 Claude Sonnet 5.5 세션의 기록된 토큰 수도 다시 가격 산정했으며, Claude Sonnet 5.5에서 캐싱을 끈 실행은 하지 않았습니다. 이 세 세션 각각은 작업의 20개 이슈에 걸친 40개 요청으로 이루어진 하나의 대화입니다. 2026년 10월 12일 기준 정가에서 세션은 사용량 필드 기준으로 평균 각각 $0.51 USD가 들었고, 모든 입력 토큰을 입력 가격으로 하고 출력 토큰은 그대로 둔 경우 $3.70 USD였습니다. 86% 절감(세 세션에 걸쳐 86%~87%), 즉 7.3배입니다. 출시 당시 캐시 읽기 가격인 $0.20 USD에서는 절감이 82%이므로, Claude Sonnet 5 수치보다 상승한 것은 더 낮은 캐시 읽기 가격에서 나옵니다.
    • 기록된 토큰 수로 가격 산정, Claude Opus 5.5: 같은 방식으로 다시 가격 산정하면, 기본 effort인 medium에서 5분 캐시를 사용하고 일시 중지가 없는 세 개의 Claude Opus 5.5 세션은 평균 각각 $1.02 USD가 들었고 $6.93 USD와 비교해 85% 절감, 즉 6.8배입니다. Anthropic은 Claude Opus 5.5에서 캐싱을 끈 실행은 하지 않았으며, 모델은 요청의 79%에서 사고를 사용했습니다.
    • 사고 설정 방식, 두 세트의 실행만 해당: 5분 캐시를 사용하고 일시 중지가 없는 세 개의 Claude Sonnet 5.5 세션의 요청은 사고 옵션을 설정하지 않았으므로 사고는 모델의 기본값으로 남았고, 모델은 요청의 38%에서 이를 사용했습니다. 캐싱을 끈 경우와 켠 경우의 Claude Sonnet 5 실행의 요청도 사고 옵션을 설정하지 않았으므로 사고는 모델의 기본값으로 남았고, 모델은 캐싱을 끈 경우 121개 요청 중 41개, 캐싱을 켠 경우 120개 중 40개에서 이를 사용했습니다.
    • 일시 중지 후 지연 시간: Claude Sonnet 5와 Claude Opus 5에서 일시 중지 후의 턴은 1시간 설정에서 웜 캐시 지연 시간을 유지했습니다. 일시 중지 후 Claude Opus 5.5의 첫 토큰까지의 시간은 측정하지 않았습니다. 일시 중지 후 Claude Sonnet 5.5의 첫 토큰까지의 시간은 측정하지 않았습니다.
17. 프로덕션의 캐시 읽기 비중: 2026년 8월 23일로 끝나는 14일 동안의 퍼스트파티 Claude API 사용량을 집계한 것이며, 직접 API 제품만 포함하고 Anthropic 내부 조직은 제외했으며 어떤 조직도 식별하지 않았습니다. 조직-일은 요청에 도구 정의와 도구 결과가 포함되고, 프롬프트에 평균 9회 이상의 이전 도구 호출이 있으며, 캐싱이 사용되었고, 그러한 요청이 최소 10건 있을 때 에이전트 루프로 계산합니다(API에는 대화 식별자가 없으므로 이것이 대화 길이를 대신함). 106,487개 조직에 걸친 303,003개 조직-일이며, 캐시 읽기 비중의 중앙값은 전체 입력 토큰의 84.2%, 상위 사분위수는 91.7%입니다. 사용 사례 레이블(조직이 선언한 사용 사례, 없으면 분류된 사용 사례)은 해당 조직-일의 74%와 토큰의 99%를 포괄하며, 코딩 조직-일의 약 72%가 80% 이상을 읽습니다. 조직-일의 상위 10분위는 코딩에서 95.9% 이상, 지원, 리서치, 데이터 및 기타 에이전트에서 94.2%~94.8%를 읽습니다. 이전 도구 호출 25회 이상에서의 요청 수준 분할은 6시간 표본에서 나온 것입니다. 코딩은 92% 읽기, 7% 쓰기, 1% 미만 캐시되지 않음입니다.
18. 압축 시점 및 상태 줄 측정:
    • 측정 내용: 입력 및 컨텍스트 토큰 줄이기의 분류 에이전트 긴 변형을 2026년 8월 24일에 5분 캐시를 사용하는 Claude Sonnet 5에서 실행했으며, 비용은 사용량 필드에서 정가로 계산했고 실험군당 다섯 세션입니다. 처음부터 끝까지 기본 effort를 사용하는 무변경 실험군(세션당 $0.81 USD)과, 낮은 effort로 시작해 동일한 두 가지 캐시 무효화 변경(기본 effort로의 전환과 도구 하나 추가)을 수행하는 두 실험군이 있으며, 하나는 요청 12와 17에서 세션 중간에(세션당 $0.95 USD), 다른 하나는 첫 번째 압축 후 첫 요청에서 함께(세션당 $0.75 USD) 수행합니다.
    • 네 번째 실험군: 2026년 8월 25일에 실행한 여섯 세션의 네 번째 실험군은 첫 번째 압축을 촉발한 요청에서 동일한 두 가지 변경을 수행했습니다(세션당 $0.92 USD). 해당 요청의 요약 패스는 81,000 토큰 컨텍스트를 읽는 대신 캐시에 썼으므로, 그 패스는 경계 실험군의 동일한 패스가 $0.04 USD인 데 비해 $0.21 USD가 들었습니다.
    • 압축: 세션은 프롬프트가 80,000 토큰 압축 트리거를 넘으면 요청 21~25에서 처음 압축되었고(21개 세션 중 16개는 요청 22), 두 개의 무변경 세션은 끝 무렵에 두 번째로 압축되었습니다. 경계 실험군의 총액이 무변경 실험군보다 낮은 것은 캐싱이 아니라 변경 전의 낮은 effort 요청과 그 두 번째 압축을 반영한 것입니다. 두 실험군의 재쓰기 비용 차이는 $0.01 USD 미만입니다.
    • 세션 중간 실험군: 세션 중간 실험군은 캐시 재쓰기에 세션당 $0.23 USD를 지불했으며, 세션 중간 실험군과 경계 실험군의 차이는 $0.20 USD였고 95% 신뢰 구간은 $0.11 USD~$0.29 USD였습니다. 세션 중간 실험군에서 effort 변경과 추가된 도구는 각각 39,000개와 60,000개의 캐시된 토큰을 다시 썼습니다. 그 세션 중 하나는 압축 후 모델이 검색 도구를 잘못 호출해 빈 결과를 받은 뒤 저렴하게 실행되었으며($0.82 USD), 포함했고 이를 제외하면 실험군 평균은 $0.98 USD입니다.
    • 정확도와 캐시 읽기: 정확도는 8월 24일의 각 실험군에서 평균 20개 레이블 중 14.2개, 8월 25일 실험군에서 14.7개였습니다. 캐시 읽기는 프롬프트 토큰의 변경 없음에서 91%, 세션 중간에서 85%, 경계에서 91%, 촉발 요청에서 변경한 경우 86%였습니다.
    • 별도 측정, 상태 줄: 입력 및 컨텍스트 토큰 줄이기의 20개 이슈 분류 작업에 대한 별도 측정을 2026년 8월 18일에 역시 5분 캐시를 사용하는 Claude Sonnet 5에서 실행했으며, 동일한 방식으로 가격을 산정했고 실험군당 세 번 실행했습니다. 시스템 프롬프트 맨 앞에 25 토큰 상태 줄을 두면 실행당 평균 $4.24 USD(세 번의 실행에 걸쳐 $4.12 USD~$4.47 USD)가 들었고 캐시에서 아무것도 읽지 않았으며, 동일한 줄을 마지막 캐시 중단점 뒤의 최신 사용자 턴 끝에 두면 실행당 $0.59 USD($0.55 USD~$0.61 USD)가 들었습니다. 전자는 캐싱을 끈 상태에서 동일한 작업이 든 비용보다 많습니다. 동일한 구성으로 나중에 다시 실행하면 $4.28 USD와 $0.61 USD가 나왔습니다.
19. Claude Fable 5.1에서의 캐시 지속 시간 측정: 참조 16과 동일한 20개 이슈 분류 작업 및 하네스이며 max_tokens를 4,096으로 올렸고, 2026년 8월 23일과 8월 26일에 Claude Fable 5.1 출시 스냅샷을 출시 가격(100만 토큰당 입력 $10 USD, 5분 쓰기 $12.50 USD, 1시간 쓰기 $20 USD, 캐시 읽기 $0.25 USD, 출력 $50 USD)으로 실행했으며, 일정당 세 가지 설정은 5분 캐시, 1시간 캐시, 그리고 변경되지 않은 접두사에 대한 max_tokens: 0 요청을 이전 요청의 시작 시점부터 측정해 4분마다 보내 웜 상태로 유지한 5분 캐시입니다(8월 23일 실행은 max_tokens: 1로 keep-alive 요청을 보냈으며, 여기에 보고된 8월 26일 셀에서는 응답을 받은 모든 keep-alive 요청이 캐시를 갱신했고 그 응답은 출력 토큰이 없다고 보고했습니다). 일정은 일시 중지 없음, 턴의 10%, 20개 이슈 전체에서 6분의 모든 턴, 그리고 5개 이슈 하위 집합에서 45분 일시 중지이며, 셀당 세 번 실행했고(45분 일시 중지의 8월 26일 keep-alive 셀은 여섯 번), 비용은 각 응답의 usage 필드에서 정가로 계산했으며, 정확도는 동일한 골드 레이블에 대해 측정했습니다(20개 중 12~18개 정확한 레이블). 8월 26일의 5분, 1시간, keep-alive 설정별 세션 평균은 다음과 같습니다. 일시 중지 없음 $2.42 USD, $3.09 USD, $2.29 USD, 10% 일시 중지 $4.50 USD, $2.96 USD, $2.36 USD, 모든 턴 $22.89 USD, $3.01 USD, $2.62 USD이며, 8월 23일 셀은 6% 이내로 일치합니다. 45분 수치(5개 이슈 세션당 $1.68 USD, $0.59 USD, $0.71 USD)는 8월 26일의 이후 세션에서 나온 것입니다. 그날의 첫 번째 세션 세트는 해당 머신이 종료되면서 중단되었고, 두 번째는 서비스 결함의 영향을 받아 제외했습니다. 세 번째 세트가 5분 및 1시간 수치를 제공하며, 그 세 개의 keep-alive 세션은 각 keep-alive 요청을 한 번만 보냈고 속도 제한 거부로 요청을 잃었으므로 평균에 포함되지 않습니다. Keep-alive 수치는 거부된 keep-alive 요청을 2초 이내에 다시 보낸 여섯 개의 추가 세션의 평균입니다. 8월 23일 실행은 $1.67 USD, $0.58 USD, $0.70 USD를 제공했습니다. 5분 설정과 1시간 설정 간의 손익분기점은 턴의 3.1%이며, 참조 16과 동일한 측정입니다. Claude Fable 5.1의 캐시 읽기는 입력 가격의 0.025배이고 캐시 쓰기는 표준 배수를 유지하므로, 접두사를 다시 읽는 keep-alive 요청은 저렴하고 1시간 지속 시간의 쓰기 프리미엄이 더 큰 비용이 되지만, keep-alive 요청이 프리미엄보다 더 비싼 45분 일시 중지는 예외입니다.
20. Terminal-Bench 3: 공개 터미널 에이전트 벤치마크의 74개 작업이며, 플랫폼의 내장 도구 대신 평가 하네스가 각 작업 자체의 컨테이너에서 실행하는 셸과 파일 편집기라는 두 개의 커스텀 도구를 사용해 Claude Managed Agents에서 실행했고, 그 외에는 외부 계정에 대한 플랫폼의 기본 설정으로 모델당 high effort로 두 번씩 2026년 8월 27일~28일에 실행했습니다. 이 실행은 Terminal-Bench 버전 3.0을 사용했으며, 점수는 공개 Terminal-Bench 리더보드나 max effort로 Claude Code에서 실행한 결과인 Claude Opus 5.5 시스템 카드의 Terminal-Bench 4.0 결과와 비교할 수 없습니다. 각 작업의 시간 제한은 벤치마크 자체 제한의 2.5배이며, 이는 에이전트에게 작업당 75분에서 20시간(중앙값 작업은 5시간)을 제공하고, 각 작업은 지정된 메모리의 세 배(6 GiB에서 96 GiB)를 받으며, 보조 서비스를 실행하는 12개 작업에는 추가 메모리가 제공됩니다. 에이전트는 일반 인터넷 접근이 없었습니다. 컨테이너는 내부 패키지 미러, GitHub와 Python Package Index를 포함한 짧은 다운로드 사이트 목록, 일부 작업에 특화된 몇몇 사이트에 접근할 수 있었고, 여덟 개 작업은 네트워크 접근이 전혀 없었습니다. 점수는 모델당 148회 시도에 대한 원시 통과율이며, 단일 실행은 5~11점씩 변동합니다. 비용은 고객이 정가로 청구받을 금액이며, 5분 캐시 수명으로 실행의 사용량 기록에서 요청별로 다시 가격 산정했습니다. Claude Opus 4.7, Claude Opus 4.8, Claude Opus 5는 각각 작업당 $8 USD~$15 USD를 사용합니다. Claude Opus 4.7은 148회 시도 중 11회를 출력 상한에서 종료했습니다.
21. DRACO: Perplexity, "DRACO: a Cross-Domain Benchmark for Deep Research Accuracy, Completeness, and Objectivity," arXiv:2602.11685, 2026.
    • 측정 내용: 10개 도메인에 걸친 100개 리서치 작업을 각각 약 40개의 가중 기준으로 이루어진 전문가 작성 루브릭에 따라 채점하며, 점수는 충족된 기준의 가중 비율로 0에서 100까지입니다.
    • 구성: 모든 구성은 Claude Opus 5.5, 기본 적응형 사고, 프로덕션 안전 분류기 켬, 스트리밍과 함께 max_tokens 128,000으로 Claude API에서 실행했습니다. medium effort(모델의 기본값)와 low의 단일 에이전트, 문장과 시계를 적용한 medium의 단일 에이전트, 그리고 이를 적용한 경우와 적용하지 않은 경우의 medium 팀입니다. 팀은 도구를 통해 동일한 모델의 헬퍼 에이전트를 시작할 수 있는 리드 에이전트이며, 그 수에는 제한이 없습니다.
    • 문장: 두 가지 변경은 문장과 시계입니다. 문장 "Time matters here: do not spend time that can be avoided, and the earlier a correct result is obtained, the better."는 에이전트의 첫 user 메시지에서 작업 끝에 빈 줄 뒤에, 그리고 각 헬퍼의 브리프 끝에 들어갑니다.
    • 시계: 시계는 [elapsed 252s]와 같이 경과 시간을 초 단위로 나타낸 것이며, 첫 요청을 포함한 모든 요청 전에 최신 user 메시지 끝에 추가됩니다. 첫 요청에서는 작업 뒤의 자체 텍스트 블록에, 메시지에 도구 결과가 있을 때는 마지막 도구 결과 텍스트 끝에 빈 줄 뒤에 추가됩니다. 이전 시계는 그대로 유지되므로 캐시된 접두사는 다음 요청에서도 계속 일치합니다. 팀의 모든 에이전트는 동일한 시계를 읽으며, 시스템 프롬프트는 변하지 않습니다.
    • 측정된 실행에서: 측정된 실행은 이 문구와 형식을 사용했습니다. 시계는 작업 시작이 아니라 첫 응답의 첫 토큰에서 시작했습니다. 측정된 팀 실행에서 헬퍼의 보고서는 마지막 도구 결과 안이 아니라 시계 뒤의 별도 메시지로 리드에게 전달되었습니다.
    • 시기: 각 구성은 작업당 세 번 시도했고 시도당 4시간 제한이 있었으며, 2026년 9월 24일에 실행했고 한 세트의 모든 구성은 함께 시작했습니다.
    • 도구: 에이전트는 평가 하네스가 Anthropic 웹 인덱스 위에서 호스팅하는 검색 및 가져오기 도구와, 네트워크 접근이 없는 샌드박스의 Python 및 셸을 사용했습니다. 이 도구들이 시간의 일부를 결정하며 여러분의 도구는 다른 속도로 실행될 것이므로, 이 페이지는 시간을 분 단위가 아니라 구성 간의 비율로 제시합니다.
    • 시간 측정 방식: 시간은 시도의 첫 요청부터 모든 에이전트의 마지막 요청 종료까지의 실제 경과 시간이며 도구 실행을 포함하고, 작업의 시도에 대해 평균합니다. 일반적인 작업 수치는 두 구성 간 각 작업의 비율에 대한 작업 전체의 중앙값입니다.
    • 가격 산정 방식: 각 작업의 비용은 요청을 Claude Opus 5.5의 공개 정가로 산정한 것이며, 프롬프트 캐싱은 각 요청 끝에 캐시 중단점을 설정하고 5분 캐시 수명을 사용하는 고객에게 청구되는 방식으로 계산합니다. 각 요청은 이전 요청의 프롬프트를 캐시에서 읽고 나머지를 씁니다. 시도의 첫 요청과 이전 요청 후 5분 넘게 지나 시작하는 모든 요청은 전체 프롬프트를 씁니다. 비용은 모델 토큰만 포함하며, 하네스의 도구는 요금을 추가하지 않습니다.
    • 채점 방식: 모든 구간은 작업에 대한 95% 부트스트랩 구간이며, 점수 변화는 작업에 대한 쌍체 차이입니다. Claude Opus 5가 답변을 채점하므로 Claude Opus 5.5가 자신의 작업을 채점하지 않으며, 각 답변의 점수는 다섯 번의 판정 실행을 평균한 것입니다.
    • 주의 사항: 프로덕션 안전 분류기가 각 구성에서 세 번의 시도를 중단시켰으며 모두 한 작업에서였고, 그 시도들은 0점을 받습니다. 그 작업을 제외해도 어떤 결과도 바뀌지 않습니다. 또한 실행은 각 에이전트의 도구 사용을 고객 요청에는 없는 Anthropic 내부 안전 검사에 통과시켰으며, 이는 모든 구성에서 각 요청에 측정되지 않은 시간을 추가합니다. DRACO에서 변경이 없는 단일 에이전트는 약 두 배 많은 요청을, 팀은 약 3분의 1 더 많은 요청을 했으므로, 이 검사는 아마도 DRACO 시간 절감을 약간 더 크게 보이게 할 것입니다.
    • 결과, 단일 에이전트: 모델에 경과 시간 표시하기의 결과입니다. 변경을 적용하면 단일 에이전트는 일반적인 작업에서 시간이 47% 덜 걸렸고 비용은 60% 낮았으며, 평균 비용은 작업당 $1.13 USD에서 $0.44 USD로 떨어졌고, 점수는 4.1점 낮았습니다(95% 구간 2.9~5.2점 낮음).
    • 결과, 낮은 effort: 단일 에이전트의 effort를 낮추면 변경보다 더 많은 시간과 비용을 절약했고 더 많은 점수를 잃었습니다. low effort에서는 medium보다 DRACO에서 13.3점, HLE에서 3.4점, 물리학 세트에서 14.0점 낮은 점수를 받았고, 일반적인 작업은 시간이 84%, 30%, 47% 덜 걸렸습니다. medium effort에서 변경을 적용하면 low보다 9.2점, 2.5점, 11.0점 높은 점수를 받았고, 일반적인 작업은 low보다 1.2배에서 3.2배 더 오래 걸렸습니다.
    • 결과, 팀, 헬퍼: 팀의 리드는 헬퍼를 거의 시작하지 않았습니다. 변경이 없을 때 DRACO에서는 300회 시도 중 5회, HLE에서는 1,479회 중 13회, 물리학 세트에서는 280회 중 0회만 헬퍼를 시작했습니다.
    • 결과, 팀: 따라서 팀 결과는 대부분 팀 자체의 지침과 도구를 가진 리드 에이전트가 혼자 작업하는 모습을 보여 주며, Anthropic은 병렬로 작업하는 팀에 대한 변경의 측정값을 가지고 있지 않습니다. 변경이 없을 때 팀은 이미 일반적인 DRACO 작업에서 단일 에이전트 시간의 약 절반이 걸렸고 점수는 3.3점 낮았습니다(95% 구간 2.1~4.6점 낮음). 변경을 적용하면 팀은 일반적인 DRACO 작업에서 시간이 17% 덜 걸렸고 비용은 20% 낮았으며, 점수는 1.6점 낮았습니다(95% 구간 0.3~2.8점 낮음).
    • 측정하지 않음: Anthropic은 Claude Managed Agents에서 변경을 측정하지 않았습니다.
22. HLE: Phan et al., "Humanity's Last Exam," arXiv:2501.14249, 2025. 정확한 답이 있는 전문가 작성 질문이며, 참조 답안에 대해 채점합니다. 2025년 9월 10일 릴리스의 처음 500개 질문에서 이미지를 포함해 측정했으며, 벤치마크 자체의 출처는 검색에서 차단했고 설정은 참조 21과 동일합니다. 각 구성은 질문당 세 번 시도했으며 2026년 9월 24일에 실행했습니다. Claude Opus 5가 벤치마크의 공개된 판정자 프롬프트를 사용해 각 답변을 참조 답안과 비교하며, 세 번의 판정 중 다수결이 인정됩니다. 점수는 모든 구성에서 493개 질문을 포괄합니다. 나머지 중 다섯 개는 채점 요청이 판정자의 100만 토큰 한도를 초과했고, 다른 두 개는 변경이 없는 단일 에이전트의 실행이 그에 대한 세 번의 시도가 끝나기 전에 중단되었기 때문에 제외했습니다. 시간 및 비용 비율은 한두 개 질문에 타이밍이 없으므로 단일 에이전트에서 492개 질문, 팀에서 491개 질문을 포괄합니다. 프로덕션 안전 분류기가 각 구성의 시도 중 3%~4%를 중단시켰으며 그 시도들은 0점을 받습니다. 이를 제외해도 어떤 결과도 바뀌지 않습니다. 모델에 경과 시간 표시하기의 결과입니다. 변경을 적용하면 단일 에이전트는 일반적인 질문에서 시간이 14% 덜 걸렸고 비용은 9% 낮았습니다. Claude Opus 5 판정자에서 점수는 뚜렷한 변화를 보이지 않았습니다(0.9점 낮음, 95% 구간 2.5점 낮음에서 0.7점 높음). 두 번째 채점자인 Claude Opus 4.6에서는 점수가 1.9점 낮았습니다(95% 구간 0.2~3.7점 낮음). 평균 시간은 일반적인 질문보다 더 많이 줄었습니다. 변경이 매우 긴 몇몇 질문을 단축시켰기 때문에 평균 시간은 43%, 평균 비용은 37% 줄었습니다. 일반적인 질문에서 팀의 시간은 3% 이하로 변했고 점수는 뚜렷하게 변하지 않았습니다.
23. 물리학 세트: 공개 CritPt 벤치마크를 개작한 70개의 연구 수준 물리학 문제로 이루어진 내부 세트입니다. Zhu et al., "Probing the Critical Point (CritPt) of AI Reasoning: a Frontier Physics Research Benchmark," arXiv:2509.26574, 2025. 전문가 검토자가 문제 진술을 수정했습니다. Claude Opus 4.6이 세트의 채점 프롬프트를 사용해 공개되지 않은 전문가 참조 솔루션에 대해 각 답변을 부분 점수로 채점하므로, 점수는 공개된 결과와 비교할 수 없습니다. 점수는 문제의 시도에 대한 평균 등급을 문제에 대해 평균한 것이며 100점 만점의 점수입니다. 70개 문제 전체에서 문제당 네 번 시도로 측정했으며 2026년 9월 24일에 실행했습니다. 모든 에이전트는 네트워크 접근이 없는 샌드박스 컨테이너에서 Python 도구, 셸, 파일 편집기를 가졌고 검색이나 가져오기 도구는 없었습니다. 물리학 세트에서는 안전 분류기가 시도를 중단시키지 않았습니다. 그 외의 설정은 참조 21과 같습니다. 모델에 경과 시간 표시하기의 결과입니다. 변경을 적용하면 단일 에이전트는 일반적인 문제에서 시간이 7% 덜 걸렸고 비용은 4% 낮았으며, 점수는 3.0점 낮았습니다(95% 구간 0.4~5.6점 낮음). 일반적인 문제에서 팀의 시간은 3% 이하로 변했고 점수는 뚜렷하게 변하지 않았습니다. 단일 에이전트의 평균 시간은 14% 줄었습니다. 단일 에이전트의 평균 시간 절감 전체는 한 문제에서 나온 것이며, 그 문제에서 변경이 없는 에이전트는 시도당 약 30분 동안 코드를 실행했습니다. 그 문제를 제외하면 평균 시간은 변경 유무와 관계없이 거의 같습니다.
24. tau2-bench retail: Barres et al., "τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment," arXiv:2506.07982, 2025.
    • 측정 내용: retail 도메인의 114개 작업을 공개 하네스에서 Claude API를 대상으로 실행했으며, Claude Haiku 4.5를 시뮬레이션된 사용자로, Claude Sonnet 5를 자연어 판정자로 사용하고 프롬프트 캐싱을 켰습니다. 작업은 57개 검색용과 57개 보류용으로 나누었습니다.
    • 시기: 두 번의 검색은 Claude API 스킬의 hillclimb 명령으로 구동해 2026년 9월 6일에 실행했습니다. 캐싱 전후 쌍은 2026년 9월 8일에 실행했습니다.
    • 채점 방식: 검색에서 시작점과 확정된 구성은 세 번의 보류 실행의 평균이며, 유지된 단계는 두 번의 실행으로 판정했고 다른 후보는 한두 번의 실행으로 채점했습니다. 캐싱 쌍은 하네스의 캐시 중단점만 전환하고 114개 작업 전체에서 각각 세 번 실행했으며, 구성은 이전 실행에서 cost-optimize 명령이 생성한 것입니다. 보류 수치는 검색이 읽지 않은 57개 작업에 대한 것입니다.
    • 가격 산정 방식: 작업당 비용은 에이전트와 시뮬레이션된 사용자의 토큰 수를 정가로 산정하며(Claude Opus 5는 100만 입력 및 출력 토큰당 $5 USD와 $25 USD, Claude Sonnet 5는 $2 USD와 $10 USD, 캐시 읽기와 쓰기는 공개된 요율), 판정자는 제외합니다. 백분율 변화는 반올림하지 않은 비용에서 나오며, 월별 수치는 에이전트의 토큰만으로 작업당 $0.135 USD와 $0.047 USD에 10,000을 곱한 것입니다. 월 10,000건의 대화에서 이는 첫 번째 검색 전 약 $1,350 USD, 이후 $470 USD입니다.
    • 주의 사항: 이 측정은 이전 Claude Opus 및 Claude Sonnet 모델에서 실행되었습니다. 캐싱 쌍은 Claude Sonnet 5에서 실행했고, 두 번째 검색은 Claude Sonnet 5에서 시작했으며, 첫 번째 검색은 Claude Opus 5에서 Claude Sonnet 5로 이동했습니다. Claude Fable 5.1은 이 벤치마크에서 측정하지 않았습니다.
    • 캐싱 쌍: 이 쌍은 기본 effort의 Claude Sonnet 5에서 실행했습니다. 공개 하네스는 출시된 그대로 매 턴마다 전체 대화를 캐시 없이 보냅니다. 캐시된 구성은 시스템 프롬프트에 중단점 하나, 최신 메시지에 중단점 하나를 둡니다. 두 검색 모두 그 캐싱을 켠 상태로 실행했습니다. 작업당 비용은 캐시 없음 $0.223 USD에서 캐시 $0.062 USD로 72% 절감되었고, 통과율은 79.2%에서 76.0%로 변했습니다. 해당 구성의 동일한 캐시 실행은 날짜에 따라 114개 중 85개에서 93개까지 범위를 보였습니다. 모든 캐시 실행은 모든 캐시 없는 실행 이하의 점수를 받았지만, 4개 작업 미만의 차이는 동일한 캐시 실행의 편차 범위 안에 있으므로, 이 표본 크기에서는 정확도 변화가 너무 작아 측정할 수 없습니다.
    • 검색이 실행된 방식. hillclimb 명령은 네 가지 질문을 하고, 계획을 제시하며, 무언가를 소비하기 전에 승인을 기다립니다. 첫 번째 검색에서 계획은 사용자 시뮬레이터, 채점자, 캐싱, temperature, 작업을 변경하지 않았습니다. 네 가지 질문 중 마지막은 다음으로 시작했습니다. One pass over the full set is 114 cases x 1 rep on claude-opus-5, roughly 22 minutes. 각 라운드에서 검색은 하나의 변경을 제안하고 전체 세트를 실행합니다. 수치가 움직였고 예측된 메커니즘이 사용량 데이터에 나타날 때만 변경을 유지합니다. 세 라운드 연속으로 아무 성과가 없으면 중단하고, 새로운 실행에서 우승 구성을 확인합니다.
    • 첫 번째 검색, 결과. 검색은 검색 전에 설정한 2점 범위 내에서 통과율을 유지하면서 작업당 비용을 61% 줄였습니다. 기본 effort의 Claude Opus 5(작업당 $0.142 USD, 76.0% 통과)에서 비용 중립적인 프롬프트 수정 하나를 적용한 low의 Claude Sonnet 5($0.055 USD, 74.3%)로 이동했습니다. 검색은 평가 실행에 $179 USD, 자체 토큰에 $228 USD가 들었습니다.
    • 첫 번째 검색, 시작: Claude Opus 5, 기본 effort. $0.142 USD에 76.0%. 동일한 세 번의 실행은 57개 중 43~44개에 걸쳤습니다. 검색은 하한을 2점 아래인 74.0%로 설정했고, 판정을 위해 57개 중 43개(75.4%)로 올림했습니다.
    • 첫 번째 검색, 1단계, effort를 low로: 유지. 이를 유지한 두 번의 실행에서 77.2%, 검색 후 세 번 실행 확인에서 77.8%, $0.119 USD로 17% 저렴했습니다. 검색 자체의 상태 줄은 일부 다음과 같이 읽힙니다. two runs held-out 42 and 46, mean 44.0 >= floor 43; cost mean $0.1187 <= gate $0.1208; mechanism confirmed (output tokens -34% with calls flat).
    • 첫 번째 검색, 2단계, low의 Claude Sonnet 5: 유지. $0.055 USD에 75.4%, 61% 저렴했습니다.
    • 첫 번째 검색, 3단계, 프롬프트 수정(주문 ID를 묻는 대신 로그인 후 고객의 주문을 조회): 선택 시 유지되었으나 이후 유지되지 않음. 두 번의 실행에서 79.8%, 세 번의 새 실행에서 74.3%. 검색은 이를 비용 중립적이라고 보고 남겨 두었습니다. 절약된 턴이 또 다른 조회 턴이 되었기 때문입니다.
    • 첫 번째 검색, 4단계, 프롬프트 수정(요청받을 때만 사람에게 이관): 거부되고 되돌림. 71.9%. 목표로 한 3개 사례는 고쳤지만 일반적인 "say what you can and can't do" 템플릿으로 다른 10개를 망가뜨렸습니다.
    • 첫 번째 검색, 5단계, 프롬프트 수정: 실행하지 않음. 예측된 이득 0.5개 작업은 검색의 2개 작업 채택 기준 미만이었습니다.
    • 첫 번째 검색, 확인: 3단계 프롬프트를 적용한 low의 Claude Sonnet 5, 세 번의 새 실행. $0.055 USD에 74.3%로, 2점 범위 안에 0.14개 작업 차이로 들어왔고, 시작점보다 57개 중 1개 작업 낮으며, 검색이 등록한 57개 중 43개 하한 아래입니다. 이 구성의 다섯 번의 실행은 42~46에 걸쳐 시작점의 43~44보다 넓었습니다.
    • 첫 번째 검색, 보여 준 것. Effort와 모델 레버가 절감을 만들어 냈고, 각각의 메커니즘이 이를 확인했습니다. 프롬프트 레버는 실제 동작 변화를 만들어 냈지만 지속적인 이득은 없었습니다. 이 워크로드에서 작업당 비용을 결정하는 것은 문구가 아니라 턴 수와 각 턴이 다시 읽는 캐시된 접두사입니다.
    • 두 번째 검색. 캐싱을 켠 기본 effort의 Claude Sonnet 5에서 시작했습니다. 보류된 절반에서 $0.062 USD에 79.5%였고 세 번의 실행은 57개 중 42~47개에 걸쳤으므로 하한은 57개 중 45개(78.9%)였습니다. 시작 구성의 동일한 실행은 여기서 57개 중 최대 5개 작업까지 차이가 났습니다. 두 번째 검색은 아무것도 유지하지 않았습니다. low effort, 두 가지 프롬프트 수정, 그리고 둘 다 적용한 경우는 각각 77.2%로 하한 아래였고 10%~14%를 절감해 검색의 15% 비용 기준에 미치지 못했습니다. 정확도를 위한 프롬프트 수정은 두 번의 실행에서 79.8%, 세 번의 새 실행에서 73.7%를 기록했고 되돌렸습니다. 검색은 약 19번의 평가 실행과 $120 USD가 들었습니다.
25. Claude Managed Agents 작업 세트:
    • 측정 내용: 메모리, 멀티에이전트, 긴 컨텍스트 작업을 포함한 여덟 개 영역의 79개 스크립트된 에이전트 작업으로 이루어진 Anthropic 내부 세트이며, 테스트가 모든 도구 호출에 응답하는 Claude Managed Agents 세션으로 실행했습니다. 각 작업은 모델당 다섯 번 실행했습니다.
    • 실행: 수치는 2026년 10월 7일에 모델당 한 번 실행해 그날 채점한 결과입니다. 2026년 10월 8일과 9일에 동일한 작업을 세 번 더 실행했을 때 Claude Haiku 5.5는 시도의 91%~93%를 통과했고, 10월 8일에 한 번 더 실행했을 때 Claude Haiku 4.5는 63%를 통과했습니다.
    • 채점 방식: 채점자인 Claude Sonnet 4.6이 한 번 채점해 작업 체크리스트의 모든 줄을 충족으로 표시한 경우에만 시도가 통과했으므로, 통과율은 채점자에 따라 달라집니다. 한 작업을 제외한 모든 작업에서, 도구 결과를 전체로 보여 준 별도의 호출이 에이전트가 도구를 통해 작성한 파일과 메시지를 확인하는 줄을 그 결과에 대해 채점했습니다.
    • 가격 산정 방식: 비용은 5분 프롬프트 캐싱을 적용한 정가의 토큰 비용이며 요청별로 가격을 산정하고 세션 런타임은 제외합니다.
    • 결과, 토큰 가격과 비용: Claude Haiku 4.5는 요청의 80%를 캐시하지 않았습니다. 각 요청의 프롬프트가 약 4,100 토큰 이하였고 캐시 가능한 최소 프롬프트 길이는 4,096 토큰(Claude Haiku 5.5는 512)이기 때문입니다. Claude Haiku 4.5에서 Claude Haiku 5.5로 토큰 가격은 최대 90% 하락했고, 79개 작업의 토큰 비용은 약 75% 하락했습니다. 토큰 비용이 가격보다 덜 하락한 것은 Claude Haiku 5.5 요청의 약 5%가 100,000 토큰을 넘는 프롬프트를 가졌고 이는 더 높은 가격을 지불하며(긴 컨텍스트 가격), 비용의 73%를 차지했기 때문입니다.
    • 사고: Anthropic은 Claude Haiku 5.5의 effort를 medium으로 설정했고 두 모델 모두에 사고 설정이나 출력 제한을 보내지 않았으므로, 사고는 각 모델에 대한 Claude Managed Agents 자체 설정에 맡겨졌습니다. Claude Haiku 5.5는 요청의 59%에서, Claude Haiku 4.5는 22%에서 사고를 사용했습니다. 이 비교는 동일한 설정이 아니라 제공되는 그대로의 각 모델에 대한 것입니다.
    • 캐싱 없는 비용, 기록된 토큰 수로 가격 산정: Anthropic은 캐싱이 가장 먼저인 이유의 캐싱 계수를 위해 Claude Haiku 5.5의 10월 7일 실행의 기록된 토큰 수도 다시 가격 산정했으며, 캐싱을 끈 실행은 하지 않았고 Claude Managed Agents가 프롬프트 캐싱을 자체적으로 적용하므로, 이 계수는 두 설정이 아니라 동일한 요청에 대한 두 가격을 비교합니다.
    • 계수: 계수 1.7은 모든 입력 토큰을 입력 가격으로 하고 출력 토큰은 그대로 둔 실행의 토큰 비용을, 각 세션을 자체적으로 가격 산정한 토큰 비용(각 요청의 이전 프롬프트는 캐시 읽기로, 새 토큰은 5분 캐시 쓰기로)으로 나눈 값입니다. 각 요청은 두 비용 모두에서 자체 프롬프트 길이에 맞게 가격이 산정되므로, 100,000 토큰을 넘는 87개 요청은 두 경우 모두 더 높은 가격을 지불합니다. 이 가이드의 해당 실행 비용이 사용하는 기록된 그대로의 토큰 수에서는 계수가 1.9인데, 작업의 다섯 번의 시도가 나란히 실행되어 서로의 캐시 항목을 읽었기 때문입니다.
    • 계수가 낮은 이유: 세션이 짧아 중앙값이 4개 요청이기 때문에 계수가 낮습니다. 대부분의 입력 토큰은 두 번째 또는 세 번째 요청에서 도구 결과로 도착하며 캐시에서 한두 번만 읽힙니다. 여덟 개의 긴 컨텍스트 작업이 비용의 4분의 3을 차지합니다. 10월 8일의 두 번째 실행도 1.7을 제공합니다.
26. 답변 형식 측정:
    • 측정 내용: 입력 및 컨텍스트 토큰 줄이기의 20개 이슈 분류 작업을 프롬프트 캐싱을 켜고 요청에 사고 설정 없이(따라서 사고는 모델의 기본값으로 남음) Claude Sonnet 5에서 세 가지 최종 답변 지침으로 지침당 세 번씩 실행했습니다.
    • 두 줄 지침: 원본은 두 줄을 요청했습니다. 4. Finish with exactly two lines: LABEL: <one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish> SUMMARY: <one or two sentences for the engineering team>
    • 한 줄 지침: 더 짧은 변형은 한 줄을 요청했습니다. 4. Finish with exactly one line in this form: DECISION | LABEL | REASON where DECISION is one of: triage-now, needs-info, close-duplicate; LABEL is one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish; REASON is one clause under 15 words. Output nothing after that line.
    • 메모 지침: 더 긴 변형은 문제 요약, 증거, 중복 확인, 권장 레이블, 다음 단계, 확신도라는 제목이 붙은 여섯 개 섹션으로 이루어진 메모를 요청했습니다.
    • 전송된 지침에 추가로 포함된 내용: 전송된 그대로 두 줄 지침에는 "Be concise."도 포함되어 있었고 메모 지침에는 "Be thorough and explicit."가 포함되어 있었습니다.
    • 시기: 두 줄 및 한 줄 지침은 2026년 8월 18일에 max_tokens를 700으로 하여, 메모 지침은 2026년 8월 19일에 max_tokens를 3,000으로 하여 실행했습니다. 상한에 도달한 응답은 없었습니다.
    • 채점 및 가격 산정 방식: 수치는 Claude Sonnet 5의 정가로 세 번 실행의 평균이며, 정확도는 골드 레이블에 대한 정확 일치입니다.
    • 결과: 한 줄 답변은 두 줄 원본보다 출력 토큰을 39% 적게 사용했고 실행당 비용은 14% 낮았습니다(차트의 반올림된 비용 $0.49 USD와 $0.57 USD에서 계산한 값이며, 반올림하지 않은 평균으로는 13%). 메모는 두 줄 원본의 여섯 배의 출력 토큰을 사용했고 한 줄 답변의 2.8배 비용이 들었습니다.
    • 사고: 응답의 약 절반에 사고가 포함되었으며, 그 토큰은 출력 토큰에 계산됩니다.
27. 도구 검색 측정:
    • 측정 내용: 입력 및 컨텍스트 토큰 줄이기의 20개 이슈 분류 작업을 2026년 8월 19일에 프롬프트 캐싱을 켜고 요청에 사고 설정 없이(따라서 사고는 모델의 기본값으로 남음) Claude Sonnet 5에서 구성당 세 번씩 실행했습니다. 에이전트는 자체 도구 두 개와 공개 MCP 서버의 실제 도구 정의를 가졌으며, 총 7, 17, 52, 102, 252, 502개의 도구에서 모든 정의를 로드하거나 추가된 정의를 defer_loading으로 표시해 도구 검색으로 불러오게 했습니다.
    • 채점 및 가격 산정 방식: 수치는 Claude Sonnet 5의 정가로 세 번 실행의 평균이며, 정확도는 골드 레이블에 대한 정확 일치입니다.
    • 결과: 모든 정의를 로드하면 실행 비용이 7개 도구에서 $0.55 USD에서 502개 도구에서 $1.02 USD로 거의 두 배가 되었습니다. 도구 검색을 사용하면 모든 카탈로그 크기에서 $0.55 USD~$0.56 USD였고, 502개 도구에서 45% 저렴했습니다(차트의 반올림된 비용 $0.56 USD와 $1.02 USD에서 계산한 값이며, 반올림하지 않은 평균으로는 45.6%). 모든 실행은 도구 검색 사용 여부와 관계없이 20개 이슈 중 15~18개에 올바르게 답했습니다.
    • 주의 사항: 어떤 실행도 카탈로그의 도구나 도구 검색 도구를 호출하지 않았습니다. 에이전트 자체의 두 도구는 항상 로드되어 있었고 모든 도구 호출은 그중 하나로 갔습니다. 이 측정은 사용하지 않는 정의를 가지고 다니는 비용을 보여 주는 것이지, 도구가 필요할 때 도구 검색이 그것을 찾는지를 보여 주는 것이 아닙니다.
    • 별도 측정: 동일한 모델과 날짜에서 카탈로그 없이 MCP 커넥터를 통해 공개 GitHub MCP 서버를 연결한 별도 측정에서, 서버의 도구 세트를 지연 로딩한 세 번의 실행은 그렇지 않은 세 번의 실행보다 20% 저렴했으며(실행당 $0.56 USD와 $0.70 USD), 각 실험군의 세 번의 실행은 각각 17, 16, 16개 이슈에 올바르게 답했습니다. 이 별도 측정의 요청에는 도구 검색 도구가 포함되지 않았습니다. 도구 세트를 로드했을 때 각 실행은 서버의 도구 중 하나인 issue_read를 3~4번 호출했고, 지연 로딩했을 때는 어떤 실행도 서버의 도구를 호출하지 않았습니다.
28. 입력 줄이기 및 컨텍스트 수명 주기 측정:
    • 측정 내용: 입력 및 컨텍스트 토큰 줄이기의 20개 이슈 분류 작업과 그 긴 변형을 2026년 8월 19일(UTC 기준 날짜)에 Claude Sonnet 5에서 설정당 세 번씩 요청에 사고 설정 없이(따라서 사고는 모델의 기본값으로 남음) 실행했으며, 응답의 약 10개 중 3개에 사고가 포함되었습니다.
    • 차트: 컨텍스트 수명 주기 관리의 차트는 각 작업에서 네 가지 설정을 비교합니다. 프롬프트 캐싱과 입력 줄이기(이미지 크기 조정 및 도구 검색)를 켠 작업, 그리고 컨텍스트 편집, 압축, 또는 가지치기 중 하나의 레버를 추가한 동일한 작업입니다. 차트는 10% 미만의 변화를 변화 없음으로 계산합니다.
    • 레버 설정: 레버 설정은 두 작업 간에 달랐습니다. 컨텍스트 편집은 20개 이슈 작업에서 프롬프트가 20,000을 넘으면 최소 2,000 토큰을, 긴 작업에서는 50,000을 넘으면 최소 40,000 토큰을 지웠고 가장 최근 세 번의 도구 사용을 유지했으며, 압축은 20개 이슈 작업에서 50,000 입력 토큰에서, 긴 작업에서 80,000에서 트리거되었습니다.
    • 가격 산정 방식: 각 비용은 응답의 사용량 필드에서 Claude Sonnet 5의 정가로 계산한 세 번 실행의 평균이며, 캐시 쓰기는 100만 토큰당 $2.50 USD, 캐시 읽기는 $0.20 USD입니다.
    • 결과, 입력 줄이기: 다섯 번째 설정인 입력 줄이기 없이 프롬프트 캐싱만 사용한 경우 20개 이슈 작업에서 실행당 $0.57 USD, 긴 작업에서 $1.38 USD가 들었으므로, 입력 줄이기는 전자에서 26%, 후자에서 21%를 줄였습니다. 캐싱을 끈 동일한 20개 이슈 작업(실행당 $3.36 USD, 참조 16)과 비교하면, 프롬프트 캐싱과 입력 줄이기를 함께 사용하면 88%를 절감했습니다(반올림하지 않은 평균으로는 87.5%).
    • 결과, 20개 이슈 실행: 레버가 없는 작업이 실행당 $0.42 USD였던 20개 이슈 실행에서, 컨텍스트 편집은 73% 더 비쌌고, 압축은 각 실행의 끝 무렵에 한 번 실행되어 7% 저렴했으며, 가지치기는 어떤 검색 결과도 2,000자 임계값을 넘지 않았으므로 아무것도 다시 쓰지 않았습니다.
    • 결과, 긴 실행: 레버가 없는 작업이 실행당 $1.09 USD였던 긴 실행에서, 가지치기는 39% 저렴했고, 압축은 32% 저렴했으며, 컨텍스트 편집은 4% 더 비쌌습니다.
    • 캐시 읽기, 긴 실행: 가지치기를 적용한 긴 실행에서 프롬프트 토큰의 89%가 작업 경계 후 첫 요청에서, 81%가 다른 요청에서 캐시에서 읽혔습니다. 긴 실행 전체에서 프롬프트 토큰의 85%가 가지치기에서, 85%가 컨텍스트 편집에서 캐시에서 읽혔으며, 레버가 없을 때는 95%였습니다.

다음 단계