2026년 7월 24일 클로드 Opus 5 출시 관련 모든 주류 언론 기사는 동일한 기능을 언급했습니다. 포춘지는 이를 비용과 기능 사이를 전환하는 방법이라고 불렀습니다. CNBC, 블룸버그, 테크크런치 모두 이 기능을 지목했습니다. 하지만 아무도 이 기능이 무엇인지, 어떤 레벨이 있는지, 레벨을 변경하면 어떤 일이 발생하는지, 또는 청구서에 어떤 영향을 미치는지에 대해서는 말하지 않았습니다.
이것은 effort라는 요청 매개변수이며, Opus 5에는 다섯 가지 레벨이 있고 기본값은 high입니다. 이것이 기능의 전부입니다. 이 기능이 기사화될 가치가 있는 이유는 Anthropic이 이 모델의 레벨을 재조정했기 때문입니다. 이는 Opus 4.8에서 설정했던 튜닝 값이 이제는 틀렸다는 것을 의미하며, 특정 설정 조합은 이번 주에 많은 마이그레이션 로그에 나타날 400 오류를 반환할 것입니다.
버튼
effort 매개변수의 실제 의미
effort는 Messages API 요청의 output_config 객체 안에 있습니다:
{
"model": "claude-opus-5",
"max_tokens": 8192,
"output_config": { "effort": "high" },
"messages": [
{ "role": "user", "content": "Refactor this module and explain the tradeoffs." }
]
}
이것은 모델이 답변하기 전에 얼마나 많은 내부 추론을 하는지를 제어합니다. Opus 5는 기본적으로 적응형 사고를 실행하며, effort는 그 사고 예산을 얼마나 관대하게 사용할지를 설정하는 다이얼입니다. effort가 높을수록 더 많은 추론 토큰, 더 높은 비용, 더 긴 지연 시간을 의미합니다. effort가 낮을수록 이 세 가지 모두가 줄어듭니다.
일반 사용자 인터페이스는 원시 JSON 필드 대신 `effort` 선택기로 동일한 개념을 노출하며, 언론에서 비용 대 기능 전환이라는 틀을 제시한 것도 여기에서 비롯됩니다. 그 밑에는 이 매개변수가 있습니다. API를 기반으로 개발하는 경우, 이 매개변수가 실제로 제어하는 것이므로 이 기사의 나머지 부분에서는 이에 대해 설명합니다. 전체 요청 형태는 Opus 5 API 안내서에 있으며, 매개변수 참조는 Anthropic의 모델 개요에 있습니다.
effort가 아닌 한 가지: 장황함 제어. Anthropic의 Opus 5 프롬프트 가이드에서는 effort를 낮추는 것이 가시적인 응답의 길이가 아니라 사고를 줄이는 것이라고 명시합니다. Opus 5는 이미 Opus 4.8보다 더 긴 기본 답변과 더 긴 결과물을 작성합니다. 더 짧은 출력을 원한다면 프롬프트에서 더 짧은 출력을 요청하세요. low로 낮춘다고 해서 그렇게 되지 않습니다.
다섯 가지 레벨
| 레벨 | 기능 | 일반적인 활용 |
|---|---|---|
low |
답변 전 최소한의 추론 | 대량 분류, 추출, 라우팅, 짧은 요약 |
medium |
적당한 추론 | 검색된 컨텍스트 기반 Q&A, 단일 파일 편집, 구조화된 변환 |
high |
기본값. 상당한 추론 | 아직 아무것도 측정하지 않았을 때의 일반적인 작업 |
xhigh |
확장된 추론 | 코딩 및 에이전트 루프. Anthropic이 권장하는 두 가지 시작점 |
max |
최대 추론 예산 | 잘못된 답변이 토큰보다 더 많은 비용을 초래하는 어려운 단일샷 문제 |
이 표에 대해 간과하기 쉬운 두 가지가 있습니다.
기본값은 high이며, low나 xhigh가 아닙니다. output_config 없이 요청을 보내면 high가 적용됩니다. 이는 비용 예측에 중요합니다. Opus 5에서 전혀 건드리지 않은 요청은 실제 추론 작업을 수행하고 이에 대한 요금이 청구되지만, Opus 4.8에서는 동일한 요청이 전혀 사고를 하지 않았습니다. 이 변경 사항은 Opus 4.8에서 Opus 5로의 마이그레이션에서 발생한 두 가지 주요 변경 사항 중 하나이며, 재무팀을 가장 놀라게 할 가능성이 높습니다.
그리고 코딩 및 에이전트 작업에는 max가 아닌 xhigh가 권장됩니다. Anthropic은 이러한 작업 부하의 시작점으로 xhigh를 제시합니다. max는 그 위에 존재하지만, 거기서 시작하는 것은 아마도 이점을 측정할 수 없는 여유 공간에 비용을 지불하는 것을 의미합니다. xhigh에서 시작한 다음 아래로 조정하세요.
재조정으로 변경된 사항
여기서 모델 간에 설정을 그대로 가져가는 것이 좋지 않은 이유가 나옵니다.
Anthropic은 Opus 5에서 각 effort 레벨이 의미하는 바를 재조정했습니다. Opus 5의 medium 레이블은 Opus 4.8의 medium이 설명했던 것과 동일한 양의 추론을 나타내지 않습니다. Anthropic의 지침은 4.8 구성을 그대로 가져오지 말고 Opus 5에서 새로운 effort 스윕을 실행하는 것입니다.
실질적인 결과는 경고보다 더 흥미롭습니다. 이전 Opus 모델에서는 low와 medium이 진지한 작업에는 대부분 이론적이었습니다. 저렴했지만 눈에 띄게 성능이 떨어져서 팀들은 모든 것을 high 이상으로 설정하고 비용을 지불했습니다. Opus 5에서는 낮은 레벨들이 이전보다 의미 있게 강력해져서, Opus 등급 모델에서 low와 medium이 프로덕션 작업에 실제로 유용하게 사용될 수 있는 첫 번째 사례가 되었습니다.
그것이 바로 출시의 실제 비용 지렛대이며, 언론 보도에서 '토글'이라는 단어로 압축된 부분입니다. Opus 5는 Opus 4.8과 동일하게 백만 입력 토큰당 5달러, 백만 출력 토큰당 25달러입니다. 추론 토큰은 청구서의 출력 측면에 해당합니다. 따라서 분류 파이프라인을 high로 실행하는 것과 low로 실행하는 것의 차이는 반올림 오류가 아니라, 추가 추론이 처음부터 정확도를 제공하지 않았던 작업 부하에서 출력 비용의 상당 부분을 차지합니다. Opus 5 가격 분석에는 50% 배치 할인 및 512 토큰 캐시 최소치를 포함한 전체 요금표가 있으며, 이 두 가지 모두 낮은 effort 설정과 중첩됩니다.
하나의 엔드포인트가 아니라 전체 Claude 환경에서 절약을 찾고 있다면, Claude API 청구서 절감에 대한 지침이 여기에도 적용되며, 이제 effort가 목록에 추가되었습니다.
max_tokens와 xhigh, max의 상호작용
max_tokens는 사고 토큰과 응답 토큰을 함께 제한합니다. 이는 가시적인 텍스트뿐만 아니라 요청의 전체 출력 측면에 대한 확고한 상한선입니다.
effort를 높이면 모델이 작성하기 전에 추론에 얼마나 많은 상한선을 소비하는지가 높아집니다. max_tokens를 사고하지 않는 모델에 맞게 설정한 값으로 유지하면서 effort를 xhigh 또는 max로 올리면, 모델은 추론 예산을 소진하고 답변을 완료하기 전에 잘릴 수 있습니다. 요청에 명백히 잘못된 것이 없는데도 잘린 응답을 받게 됩니다.
해결책은 여유 공간을 주는 것입니다. Anthropic의 지침은 Opus 5에서 xhigh 또는 max를 실행할 때 max_tokens: 64000으로 시작하는 것입니다:
{
"model": "claude-opus-5",
"max_tokens": 64000,
"output_config": { "effort": "xhigh" },
"messages": [
{ "role": "user", "content": "Fix the failing integration test and explain the root cause." }
]
}
높은 max_tokens는 상한선이지 구매가 아닙니다. 실제로 생성된 토큰에 대해서만 요금이 청구되므로, 64000으로 설정한다고 해서 64000에 대한 비용을 지불하는 것은 아닙니다. 이는 모델이 사고 도중에 강제로 중단되지 않도록 하는 것을 의미합니다.
아직 아무도 언급하지 않은 400 오류
이것은 지원 티켓을 유발할 것입니다.
사고를 비활성화하고 높은 effort를 요청하는 것은 모순된 지시이며, Opus 5는 이 조합을 전면적으로 거부합니다. thinking: {type: "disabled"}를 xhigh 또는 max effort와 함께 보내면 요청당 400 오류가 반환됩니다:
{
"model": "claude-opus-5",
"max_tokens": 8192,
"thinking": { "type": "disabled" },
"output_config": { "effort": "xhigh" }
}
해당 요청은 실패합니다. 사고를 비활성화하면 effort가 high로 제한됩니다. 따라서 유효한 조합은 다음과 같습니다:
- 사고 활성화(기본값) 및 다섯 가지 레벨 중 하나.
- 사고 비활성화 및
low,medium,high만 가능.
이 오류를 발생시키는 마이그레이션 경로는 예측 가능합니다. 팀이 Opus 4.8 구성에서 무해했던 thinking: {type: "disabled"}를 그대로 가져온 다음, 코딩 권장 사항에 따라 effort를 xhigh로 별도로 올리는 경우입니다. 두 편집은 개별적으로는 합리적으로 보입니다. 함께 사용하면 400 오류가 발생합니다.
Anthropic의 자체 조언은 Opus 5에서 사고를 전혀 비활성화하지 않는 것입니다. 사고를 끄면 두 가지 실패 모드가 가끔 나타납니다. 모델이 도구 호출을 실행되지 않는 일반 텍스트로 작성하거나, 내부 XML 태그가 가시적인 출력으로 유출되는 경우입니다. 에이전트 루프에서는 유출된 텍스트가 이후 턴을 오염시킵니다. Opus 5에서 비용을 제어하는 권장 방법은 사고 비활성화가 아니라 낮은 effort 레벨입니다. 이 두 가지 문제에 대해서는 Opus 5 프롬프트 가이드에서 더 자세히 다룹니다.
자체 평가에서 effort 스윕을 실행하는 방법
Anthropic은 재스윕을 권장합니다. 다음은 오후에 완료할 수 있는 절차입니다.
1. 작업 세트 고정. 합성 예시가 아닌 프로덕션 로그에서 실제 프롬프트 30~50개를 가져오세요. 실제로 걱정하는 어려운 케이스를 포함하세요. 쉬운 작업에서는 effort 차이가 사라지므로, 깔끔한 샘플 세트는 아무것도 알려주지 않을 것입니다.
2. 어떤 출력도 보기 전에 통과 기준을 적어두세요. 테스트 성공, JSON이 스키마에 대해 유효성 검사 통과, 추출된 필드가 실제 값과 일치, 사람이 예/아니오로 평가. 기준이 '느낌'이라면 스윕도 '느낌'을 생성할 것입니다.
3. 모든 프롬프트를 모든 레벨에서 실행하세요. 5개 레벨에 40개 프롬프트를 곱하면 200번의 호출입니다. Opus 5에서는 충분히 저렴해서 크게 고민할 필요가 없으며, 지연 시간에 민감한 작업이 아니므로 Batch API를 통해 절반 가격으로 보낼 수 있습니다.
4. 실행당 세 가지 숫자 캡처, 하나가 아닌: 통과 또는 실패, usage.output_tokens, 그리고 실제 지연 시간. 응답의 usage 블록은 실제 비용 신호가 있는 곳입니다. 왜냐하면 추측해야 할 추론 토큰을 세기 때문입니다.
5. 기준을 통과하는 가장 저렴한 레벨을 선택한 다음, 튜닝에 사용하지 않은 홀드아웃 세트에서 이를 확인하세요. 홀드아웃을 건너뛰는 팀은 40개의 특정 프롬프트에 맞춰진 설정을 출시하는 경향이 있습니다.
6. 다음 모델에서 다시 실행하세요. 이 스윕이 존재하는 전체 이유는 4.8과 5 모델 간에 레벨이 재조정되었기 때문입니다. 다시 발생할 것이라고 가정하세요.
Apidog에서 레벨을 나란히 비교하기
스윕의 기계적인 부분은 하나의 필드를 변경하여 하나의 요청 본문을 다섯 번 보내고 반환되는 것을 정렬하는 것입니다. 이것은 상당한 양의 curl 복사-붙여넣기 작업이며, Apidog가 깔끔하게 처리하는 부분입니다.
작동하는 설정:
- Anthropic Messages 엔드포인트에 대한 요청을 생성하고, 키를 본문에 붙여넣는 대신 환경 변수로 저장하세요. 키는 팀과 공유하는 어떤 것에도 노출되지 않아야 합니다.
- 작동하는 요청을 컬렉션에 저장한 다음, 이를 다섯 번 복제하고 각 복사본에서
output_config.effort만 변경하세요. - 각 응답의
usage객체를 검사하여 레벨별 출력 토큰을 직접 볼 수 있고, 캐싱이 적용되는지 확인할 때는cache_read_input_tokens도 볼 수 있습니다. - 스트리밍을 켜고 SSE 이벤트를 읽으면
xhigh와low에서 지연 시간이 실제로 어떻게 변하는지 확인할 수 있습니다. stop_reason이 존재하고max_tokens가 아니라는 어설션을 추가하여, 잘린xhigh응답이 짧은 답변처럼 조용히 보이는 대신 컬렉션에서 크게 실패하도록 하세요.
마지막 어설션이 가장 먼저 설정할 가치가 있는 것입니다. 높은 effort에서 잘림이 발생할 가능성이 가장 높기 때문입니다. 읽으면서 비교 컬렉션을 만들고 싶다면 Apidog를 다운로드하세요. 여기에 필수는 아니지만, 다섯 개의 쉘 스크립트를 유지 관리하는 것보다 낫습니다.
솔직한 상한선
effort는 Opus 5를 더 저렴하게 잘 실행할 수 있도록 합니다. 하지만 Opus 5를 Claude 스택의 최상단으로 만들지는 않습니다.
Anthropic의 자체 Opus 5 출시 수치는 강력합니다. Opus 4.8의 Frontier-Bench v0.1 점수를 두 배 이상 넘고, ARC-AGI 3에서 다음으로 좋은 모델보다 약 3배 뛰어나며, CursorBench 3.2에서 Fable 5의 0.5% 이내에 절반 가격으로 도달했습니다. 이 모든 수치는 Anthropic이 발표한 공급업체 자체 측정치이며, 2026년 7월 25일 현재 독립적으로 재현된 것은 없습니다. 이를 중립적인 측정값이 아닌 출처가 있는 주장으로 취급하고, 각 수치에 대한 주의사항은 Opus 5 벤치마크 분석을 참조하십시오.
Opus 5 위에 있는 Fable 5는 여전히 Anthropic의 가장 유능하고 널리 출시된 모델로, 백만 입력 토큰당 10달러, 백만 출력 토큰당 50달러입니다. 그리고 Anthropic이 직접 명시했듯이 Opus 5는 사이버 보안 익스플로잇 및 자율 생물학 연구에서 여전히 Mythos 5에 뒤처집니다. Opus 5를 max로 실행해도 어느 쪽 격차도 좁혀지지 않습니다. 솔직히 요약하자면, 최전선급 기능이 최전선 가격의 절반에 제공되며, 그 위에 명확한 상한선이 있습니다. 귀하의 작업 부하에 대해 가격 차이가 가치가 있는지는 Opus 5 vs Fable 5에서 다룹니다.
버튼
자주 묻는 질문
클로드 Opus 5의 기본 effort 레벨은 무엇인가요? high입니다. output_config 필드가 없는 요청은 적응형 사고가 활성화된 상태에서 high effort로 실행됩니다.
다섯 가지 effort 레벨은 무엇인가요? low, medium, high, xhigh, max입니다. Anthropic은 코딩 및 에이전트 작업에 xhigh에서 시작하여 자체 평가에 따라 아래로 조정할 것을 권장합니다.
effort를 xhigh로 설정했을 때 요청이 400 오류를 반환하는 이유는 무엇인가요? 거의 확실하게 thinking: {type: "disabled"}도 함께 보냈기 때문입니다. 사고를 비활성화하면 effort가 high로 제한되며, 이 조합은 요청당 거부됩니다. 사고 비활성화 블록을 제거하거나 effort를 high 이하로 낮추세요.
Opus 4.8 effort 설정을 Opus 5에 재사용할 수 있나요? 아니요. 레벨이 재조정되어 동일한 레이블이 다른 양의 추론을 의미합니다. Anthropic은 새로운 스윕을 실행할 것을 요청합니다. 변경된 전체 목록은 마이그레이션 가이드에 있습니다.
effort를 낮추면 응답이 짧아지나요? 아니요. effort는 추론을 제어하며, 가시적인 길이를 제어하지 않습니다. Opus 5의 기본 응답은 Opus 4.8보다 더 깁니다. 더 짧은 출력을 원한다면 프롬프트에서 명시적으로 간결성을 요청하세요.
xhigh 또는 max에서 어떤 max_tokens를 사용해야 하나요? 64000으로 시작하세요. max_tokens는 사고 및 응답을 함께 제한하므로, 사고하지 않는 모델에 맞춰진 예산은 잘릴 수 있습니다. 실제로 생성된 토큰에 대해서만 요금이 청구되므로, 높은 상한선 자체는 비용이 들지 않습니다.
이 모든 것에 대한 전체 사양 시트, 가용성 매트릭스 및 가격 컨텍스트는 클로드 Opus 5란 무엇인가에서 시작하세요.