Claude Opus 5와 Claude Opus 4.8은 입력 토큰 100만 개당 5달러, 출력 토큰 100만 개당 25달러로 동일하게 청구되지만, 동일한 프롬프트(prompt)에 대해 기본 Opus 5 설정은 3.1배 더 많은 비용이 발생했습니다. 그 이유는 적응형 사고(adaptive thinking) 때문입니다. Opus 5는 기본적으로 사고(thinking)를 수행하며, 이 사고 과정을 출력(output)으로 청구하지만 사용자에게는 보여주지 않습니다. 하나의 요청 설정만으로 비용 차이를 완전히 없앨 수 있지만, 이는 더 큰 모델인 Fable 5가 수용을 거부하는 설정입니다. Opus 5는 2026-07-24에 일반 가용(GA) 상태가 되었으며, Fable-5 수준의 지능을 절반의 토큰 가격으로 제공하는 것으로 포지셔닝되었습니다. 실제로 청구 금액이 절반으로 줄어들지는 전적으로 이 한 가지 선택에 달려 있습니다.

요약 (TL;DR)

• 기본 Opus 5는 당사의 5가지 작업 매트릭스에서 동일한 가격의 Opus 4.8보다 3.1배 더 많은 비용을 청구했습니다. 출력 토큰의 42-95%가 숨겨진 사고(thinking) 과정이었습니다.
• thinking: {"type": "disabled"} 설정을 통해 Opus 5를 4.8과 정확히 동일한 수준(출력 토큰 384 대 384)으로 맞출 수 있었으며, 정확도는 유지되었습니다. Fable 5는 해당 파라미터(parameter)를 거부합니다.
• 에이전트 트래픽(agent traffic)의 경우 비용 부담이 +33%로 급감하며, 도구(tool)/배치(batch) 시나리오에서는 거의 동일한 수준입니다. 도구 루프(tool loops)에서는 적응형 사고가 거의 작동하지 않기 때문입니다.
• 1M 컨텍스트(context)는 실제이며(969,950개 토큰에서 바늘 찾기(needle) 성공), 캐시 하한선(cache floor)은 512 토큰으로 Opus 4.8의 1,024개 토끼의 절반입니다.

Opus 5, Opus 4.8, Fable 5는 플랫폼으로서 어떻게 다른가?

비용에 대한 심층 분석에 앞서, 방향성 지도를 살펴보겠습니다: 현재 세 가지 Claude 티어(tier), 두 가지 차이의 축, 요율(rates) 및 요청 형태(request shape). 나란히 비교하면 다음과 같습니다 (측정된 항목은 표시되어 있으며, 나머지는 모델 문서 기준입니다):

세 개의 행은 별도의 설명이 필요합니다. thinking: disabled 행은 마이그레이션 함정입니다. Opus 5에서는 이것이 노력(effort)과 결합되어 있으며, 문서에 따라 high 또는 그 이하에서만 허용되는 반면, 4.8은 이 두 설정을 독립적인 것으로 취급했습니다. 이는 버전 게이트 마이그레이션 스크립트(version-gate migration scripts)와 관련이 있습니다. fast-mode 행은 나중에 중요해질 비교 구도를 설정합니다. 서두르는 Opus 5의 비용은 정확히 Fable 5의 요금 체계와 동일하므로, "fast Opus 5 vs default Fable 5"는 동일한 토큰 가격에서 순수하게 속도 대 성능(speed-vs-capability)의 트레이드오프(trade-off)가 됩니다. 그리고 retention 행은 조용한 규정 준수(compliance)의 승리입니다. Opus 5에서 Fable급 지능을 Fable 5의 30일 데이터 보관 의무 없이 사용할 수 있습니다.

표 형식으로 나타내기 어려운 플랫폼 관련 참고 사항이 두 가지 더 있습니다. Anthropic은 사고(thinking) 기능이 비활성화되었을 때 발생하는 예외 사례(도구 호출(tool calls)이 간혹 가시적인 텍스트로 작성되거나 내부 태그가 유출되는 현상)를 문서화하고 있습니다. 아래에서 측정한 에이전트 제품군 내 84회의 thinking-off 호출 동안 우리는 두 사례 모두 겪지 않았지만, 이 가이드는 라우팅 규칙을 강화합니다. 즉, 비용(tax)이 어차피 적게 드는 도구 중심의 경로(tool-heavy routes)에서는 사고 기능을 켜두라는 것입니다. 그리고 대화 중간의 도구 변경(beta, Opus 5)은 프롬프트 캐시(prompt cache)를 깨뜨리지 않고 턴 사이에 도구를 추가하거나 제거할 수 있게 해주며, 이는 우리의 프롬프트 캐싱 가이드가 긴 에이전트 세션을 위해 구축한 캐시된 접두사(cached-prefix) 경제성을 보호합니다.

Opus 5의 기본 비용은 Opus 4.8과 비교해 어떠한가?

동일한 요금 체계에서 동일한 작업을 수행할 때 3.1배 더 비쌉니다. 우리는 현재의 세 가지 Claude 티어(tier)를 기본 설정 상태에서 네이티브 Messages API를 통해 5가지 작업 매트릭스(셀당 n=3, 솔트 처리된 프롬프트)로 실행했으며, 규모 측정을 위해 Fable 5를 함께 사용했습니다:

답변은 동일하고 비용 비율도 4.8과 같지만, 청구 금액은 3배입니다. Opus 4.8은 요청하지 않으면 생각하지 않지만, Opus 5는 적응형 사고 (adaptive thinking) 기능이 켜진 상태로 출시되며, 이 사고 과정은 출력 비용인 $25/M(백만 토큰당)의 전체 요율로 청구됩니다.

Fable 5 열은 직관에 반하는 결과를 보여줍니다. 요율이 두 배($10/$50)인 모델임에도 불구하고, 절대적인 달러 금액으로는 기본 Opus 5보다 35% 적게 청구되었습니다. 이는 Fable 5가 동일한 작업을 383개의 출력 토큰 (output tokens)으로 해결한 반면, Opus 5는 1,305개를 사용했기 때문입니다. 세 모델 모두 문서화된 동일한 기본 노력 수준 (high)으로 실행되므로, 이 격차는 설정 (configuration)의 차이가 아니라 사고 교정 (thinking calibration)의 차이입니다. 두 가지 메커니즘이 이 수치에 부합합니다. 첫째, 더 유능한 모델은 쉬운 정답을 확신하는 데 더 적은 숙고 (deliberation)가 필요합니다. Fable 5는 문장제 문제에서 52개의 토큰을 사용한 반면 Opus 5는 152개를 사용했고, 단락 문제에서는 264개를 사용한 반면 Opus 5는 1,031개를 사용했습니다. 둘째, Opus 5의 핵심 역량은 테스트 시간 연산 스케일링 (test-time compute scaling)으로, 어려운 문제에서 추가적인 숙고를 품질로 전환하는 것입니다. Opus 5의 기본 교정 설정은 숙고가 전혀 필요 없는 요청을 포함하여 모든 요청에 대해 해당 보험을 구매하는 것과 같습니다. 쉬운 트래픽에 대해서는 사용하지도 않을 보험료를 지불하고 있는 셈이며, Fable 5는 대부분 이 보험 구매를 거부합니다.

추가 지출은 어디로 가는가?

사용자가 읽을 수 없는 추론 (reasoning)으로 들어갑니다. 청구된 출력 토큰을 눈에 보이는 답변 텍스트와 비교했을 때, Opus 5의 기본 출력 지출 중 42~95%는 숨겨진 사고 (hidden thinking)였으며, 이는 전혀 필요하지 않은 질문에서도 발생합니다. 예를 들어, 17*23의 정답은 1개의 토큰 답변 뒤에 11개의 사고 토큰을 동반했고, 120단어 쓰기 작업은 1,031개의 출력 토큰 중 약 806개를 숙고에 사용했습니다. 사고 내용은 요약이나 흔적 등 어떤 형태로도 반환되지 않으며, 이로 인해 Opus 5는 Fable 5와 함께 당사가 토큰 사용 구조 (token usage anatomy) 연구에서 매핑한 가시성 스펙트럼 중 가장 폐쇄적인 쪽에 위치하게 됩니다. 사용 내역 항목에서 개수는 확인할 수 있지만, 그 비용으로 무엇을 샀는지는 볼 수 없습니다.

사고 스위치 (thinking switch)는 실제로 무엇을 하나요?

그것은 Opus 5를 Opus 4.8의 청구서로 바꿔 놓습니다. thinking: {"type": "disabled"}를 전송하면 모든 작업에서 사고 (thinking)가 0으로 수렴했으며, 총액은 4.8과 정확히 일치했습니다. 출력 토큰(output tokens) 384개 대 384개, 세트당 $0.01130 대 $0.01120로 나타났습니다:

먼저 라벨링에 관한 참고 사항을 말씀드립니다: 여기에 언급된 모든 모델은 동일한 API 기본값인 노력(effort) high를 문서화하고 있으며, Anthropic은 명시적인 high 설정이 해당 파라미터를 생략하는 것과 동일하다고 밝히고 있습니다. 우리의 암시적 기본값(implicit-default) 실험군과 명시적 high 실험군은 여전히 16%의 차이를 보이지만, 이는 우리가 실행한 모든 배치에서 가장 노이즈가 심한 셀인 작문 작업(writing task)에서 발생하는 실행 간 변동성(run-to-run variance)일 뿐 실제적인 차이가 아닙니다. 따라서 이 두 행은 동일한 실험군을 두 번 측정한 것으로 간주하십시오. 세 가지 기본값을 구분 짓는 것은 노력(effort) 수준이 아니라, 해당 수준에서 사고(thinking)가 수행하는 역할입니다: 4.8에서는 없음, Fable 5에서는 절약적이고 적응적(frugal and adaptive), Opus 5에서는 공격적이고 적응적(aggressive and adaptive)입니다.

두 가지 사항이 눈에 띕니다. 첫째, 노력 조절 다이얼(effort dial)은 비용 조절 노브(cost knob)가 아니라 품질 사다리(quality ladder)입니다. 사다리 자체(low부터 max까지)는 새로운 것이 아니며, 4.8 버전도 동일한 범위를 수용합니다. 하지만 이토록 단순한 작업에서는 low 이상의 모든 단계가 동일한 정확도에서 더 많은 숙고(deliberation)를 구매할 뿐이며, xhigh는 4.8 버전 비용의 3.8배에 달합니다. 최상위 티어는 진정으로 어려운 문제에 대한 테스트 시간 연산 스케일링(test-time compute scaling)을 위해 존재하지만, 5가지 작업으로 구성된 이 검증 매트릭스(sanity matrix)로는 이를 실행할 수 없습니다. 대신 이 매트릭스가 보여줄 수 있는 것은 비용 측면이며, 비용 측면을 보면 다이얼을 조절한다고 해서 결코 4.8 버전 수준의 비용 균형(parity)으로 돌아갈 수 없음을 알 수 있습니다. 오직 스위치를 끄는 것만이 기본값 대비 67% 낮은 비용으로 그 균형을 맞출 수 있습니다. 둘째, 이 스위치가 존재한다는 사실 그 자체입니다. Fable 5는 thinking: {"type": "disabled"} 요청에 대해 400 에러를 반환하며 거부하므로, 이는 Opus 제품군 전체의 공통 사항이 아닌 Opus 5만의 진정한 차별점입니다. 동일한 thinking 객체는 /v1/messages와 OpenAI 호환 /v1/chat/completions라는 두 가지 게이트웨이 인터페이스(gateway surfaces) 모두에서 작동합니다. 후자의 경우, 비활성화된 실행은 completion_tokens_details 내의 reasoning_tokens가 0으로 보고됩니다:

{"model": "claude-opus-5", "thinking": {"type": "disabled"}}

솔직한 주의 사항을 덧붙이자면, 우리가 검증한 작업들은 검색(retrieval) 및 단일 단계(single-step) 형태이며, 다단계 문장제 문제(multi-step word problem)를 포함하여 사고(thinking)를 꺼두었을 때도 9/9의 정확도를 유지했습니다. 더 어려운 에이전트적 작업(agentic work)이야말로 적응형 사고(adaptive thinking)가 존재하는 바로 그 영역입니다. 따라서 이 스위치를 경로별 결정 사항으로 취급하십시오. 이는 우리가 Kimi K3와 Gemini 3.6 Flash에 대해 내린 결론과 동일한 규칙입니다. 즉, 추출(extraction), 포맷팅(formatting), 단일 단계 호출(single-step calls)에는 끄고, 평가(evals) 결과 사고 기능이 비용만큼의 가치를 창출한다고 판단되는 곳에는 기본값으로 사용하십시오.

에이전트 워크로드에서도 3배의 세금이 유지되는가?

아니요, 그리고 그 차이가 바로 핵심입니다. 우리의 에이전트 시나리오 제품군(도구 루프 (tool loops), RAG, 도구 사용 (tooling), 배치 (batch), 긴 채팅 (long chat); 각 실험군당 50개 에피소드) 전체를 살펴보면, 기본 설정의 Opus 5 비용은 Opus 4.8보다 210%가 아닌 단 33%만 더 높았으며, 도구 중심의 시나리오들은 거의 대등한 수준(1.01-1.22배)으로 실행되었습니다. 적응형 사고 (Adaptive thinking)는 그곳에서 진정으로 적응적인 모습을 보여주었습니다. 단순 작성 프롬프트(bare writing prompt)에서 호출당 약 806개의 사고 토큰 (thinking tokens)이 소모된 반면, 에이전트 루프 내부에서는 호출당 약 88개의 사고 토큰이 소모되었습니다. 예외적인 것은 1.58배의 비용이 발생한 긴 채팅 (long chat)이었으며, 이 영역은 여전히 스위치를 끄는 것이 이득인 구간입니다 (사고 기능 비활성화 시 1.22배). 함수 호출 (Function calling)은 사고 세금 (thinking tax)이 전혀 나타나지 않았습니다. 기본 설정에서 도구 호출 요청은 사고 토큰이 포함되지 않은 52개의 출력 토큰으로 반환되었으며, 이는 사고 기능이 없는 모델이 사용하는 예산과 동일했습니다.

따라서 실질적인 구분 기준은 모델이 아니라 트래픽의 형태입니다. 단순 완성 (bare completions) 및 채팅 형태의 호출은 3배의 기본 세금이 부과되므로 스위치를 끄는 것이 유리하며, 도구 중심의 에이전트 트래픽은 대부분 그럴 필요가 없습니다.

Opus 5는 정말 Fable 5의 절반 가격인가?

스위치를 전환한 후에야 그렇습니다. 토큰당 비용으로 보면, Fable 5의 $10/$50 대비 Opus 5는 $5/$25로 맞습니다. 실제로 우리의 단순 작업 매트릭스 (bare-task matrix)에서 기본 Opus 5는 세트당 $0.03427를 청구한 반면, Fable 5는 $0.02233를 청구하여 절대 금액으로는 53% 더 높았습니다. 이는 Fable 5가 동일한 작업을 383개의 출력 토큰으로 해결한 반면, Opus 5는 1,305개의 토큰을 사용했기 때문입니다. 사고 기능을 비활성화하면 Opus 5의 $0.01130는 Fable 5 청구액의 거의 정확히 절반이 되며, 이는 Fable 5 자체는 수용하지 않는 파라미터를 통해 실현된 출시 당시의 약속입니다.

컨텍스트 (Context), 캐시 (cache), 그리고 토크나이저 (tokenizer): 그 외에 무엇을 검증했는가?

1M (100만) 컨텍스트 윈도우 (window)는 실재하며, 한계를 넘을 때 명확하게 실패합니다. 969,950개 토큰 프롬프트 앞부분에 위치한 회상 바늘 (recall needle) 테스트는 39초 만에 정확한 결과를 반환했습니다. 또한 1,010,221개 토큰 프롬프트는 조용히 잘리는 대신 prompt is too long: … > 1000000 maximum이라는 명확한 오류를 반환했습니다.

캐시 하한선(cache floor)이 절반으로 줄었습니다. Anthropic의 문서에 따르면 Opus 5(및 Fable 5)의 최소 캐싱 가능 접두사(cacheable prefix)는 512토큰으로, Opus 4.8 및 Sonnet 5의 1,024토큰보다 낮아졌습니다. 우리의 전수 조사 결과도 이와 일치하였으며, 511토큰 근처의 접두사는 캐싱되지 않았고 547토큰은 안정적으로 캐싱되었습니다. 캐시된 읽기(Cached reads)는 100만 토큰당 $0.50(0.1배)로 청구되며, 쓰기(writes)는 1.25배, TTL(Time To Live)은 5분입니다. 이제 더 짧은 시스템 프롬프트(system prompts)도 캐싱이 가능해졌으며, 이는 높은 QPS(Queries Per Second) 경로에서 조용하지만 중요한 요소입니다.

토크나이저(tokenizer)는 Opus 5, Opus 4.8, Fable 5, Sonnet 5 전반에 걸쳐 변경되지 않았습니다. 우리의 다국어 및 코드 샘플에서 동일한 토큰 수를 기록했으므로, 언어별 예산 및 프롬프트 크기 추정치는 재설정(re-baselining) 없이 그대로 적용할 수 있습니다.

FAQ

Claude Opus 5에서 사고(thinking) 기능을 끌 수 있나요?

네, 노력(effort) 수준을 high 이하로 설정하면 가능합니다. 문서에 따르면 xhigh 또는 max와 결합할 경우 400 오류가 반환됩니다. 우리의 테스트에서 이 설정을 통해 사고 토큰(thinking tokens)을 0으로 만들었으며, 비용을 Opus 4.8과 동일한 수준으로 맞출 수 있었습니다(우리의 매트릭스 기준 출력 토큰 384개 vs 384개). 이는 Opus 5에만 해당되는 사항입니다. Fable 5는 어떤 노력 수준에서도 동일한 파라미터를 사용할 경우 400 오류를 반환하며 거부합니다. 노력 조절 다이얼(low부터 max까지)도 작동하지만, 비용이 완전히 동일해지지는 않습니다. 우리의 매트릭스 기본값 대비 low에서는 -21%에서 xhigh에서는 +24%까지 차이가 납니다.

동일한 정가임에도 왜 제 Opus 5 청구 금액이 Opus 4.8보다 높은가요?

Opus 5는 기본적으로 사고(thinking)를 수행하며, 이 사고 과정은 출력(output)으로서 100만 토큰당 $25로 청구되기 때문입니다. 우리의 측정 결과, 단순 프롬프트(bare prompts)의 경우 청구된 출력의 42~95%가 숨겨진 추론(hidden reasoning)이었습니다. 예를 들어, 1토큰의 답변 뒤에 11개의 사고 토큰이 따라붙어 두 자릿수 배수의 비용이 발생했습니다. 사용 내역 항목에서 reasoning_tokens를 읽어 본인의 트래픽에서 차지하는 비중을 확인하고, 사고 기능이 필요하지 않은 경로에서는 해당 기능을 비활성화하십시오.

에이전트 워크로드(agent workloads)는 Opus 5에서 사고 기능을 꺼야 할까요?

보통은 그렇지 않습니다. 저희의 에이전트 제품군(agent suite)에서 기본 비용은 Opus 4.8 대비 단 +33%에 불과하며, 도구(tool) 및 배치(batch) 시나리오에서는 거의 대등한 수준을 보입니다. 이는 도구 루프(tool loops) 내부에서 적응형 사고(adaptive thinking)가 거의 실행되지 않기 때문입니다. 예외적인 경우는 긴 채팅 형태의 세션(1.58배)으로, 이 경우에는 스위칭(switch)을 사용하는 것이 여전히 이득입니다. 귀하의 작업 혼합(mix)을 직접 측정해 보십시오. 비용 부담(tax)은 도구 호출(tool calls)이 아닌 순수 완료(bare completions) 단계에서 발생합니다.

2026-07-25부터 2026-07-27까지 Synthorai 게이트웨이를 통해 claude-opus-5, claude-opus-4-8, claude-fable-5를 대상으로 측정됨: 하나의 표준 배치(n=3 per cell, 솔트 처리된 프롬프트, 네이티브 Messages API)를 통한 5개 작업 매트릭스 및 노력/스위치 어블레이션(effort/switch ablation), 150개 에피소드 시나리오 제품군에서의 에이전트 수치, 니들 리콜(needle-recall) 및 프리픽스 스윕(prefix sweeps)을 통한 컨텍스트 및 캐시 프로브, 직접 요청 프로브를 통한 API 형태 행(prefill, switch acceptance). 정확도 측정에는 단일 확인 가능한 정답이 있는 작업을 사용함. 가격 및 동작은 변경될 수 있으므로, 귀하의 사용 기록을 통해 확인하십시오.