Claude Opus 5 vs Opus 4.8 실측 비교: 가격은 같지만 비용은 3배 차이

Claude Opus 5와 Claude Opus 4.8의 요금은 입력 token 100만 개당 $5, 출력 token 100만 개당 $25로 같다. 하지만 동일한 prompt를 기본 설정으로 실행했을 때 Opus 5의 비용은 3.1배였다. 원인은 adaptive thinking이다. Opus 5는 기본적으로 thinking을 수행하며, 이 과정에서 사용한 token은 출력으로 과금되지만 사용자에게는 표시되지 않는다. 요청 설정 하나만 바꾸면 비용을 정확히 같은 수준으로 낮출 수 있다. 더 큰 모델인 Fable 5에서는 사용할 수 없는 설정이다. Opus 5는 2026-07-24에 GA로 출시됐으며, token 가격을 절반으로 낮추면서 Fable-5 수준의 지능을 제공하는 모델로 소개됐다. 실제 청구액이 절반이 될지는 거의 전적으로 이 설정 하나에 달려 있다.

TL;DR

• 기본 설정의 Opus 5는 같은 가격인 Opus 4.8보다 5개 작업 매트릭스에서 3.1배 많이 청구됐다. 출력 token의 42-95%는 숨겨진 thinking이었다.
• thinking: {"type": "disabled"}를 적용하자 Opus 5와 4.8의 출력 token이 정확히 같아졌고(384 대 384), 정확도도 유지됐다. Fable 5는 이 parameter를 거부한다.
• agent 트래픽에서는 추가 비용이 +33%로 줄었으며, tool 및 batch 시나리오는 거의 같은 수준이었다. tool loop에서는 adaptive thinking이 거의 실행되지 않는다.
• 1M context는 실제로 지원되며 969,950 token 위치의 needle도 회수했다. cache 하한은 512 token으로, 4.8의 1,024 token보다 절반 낮다.

플랫폼 관점에서 Opus 5, Opus 4.8, Fable 5는 어떻게 다른가?

비용을 자세히 보기 전에 현재 Claude의 세 tier를 비교해 보자. 차이는 크게 요금과 요청 형태라는 두 축으로 나뉜다. 아래 표에서 별도 표기한 항목은 직접 측정했으며, 나머지는 모델 문서를 기준으로 했다.

세 항목은 추가 설명이 필요하다. thinking: disabled는 migration 시 주의해야 한다. Opus 5에서는 effort와 연동돼 문서상 high 이하에서만 허용된다. 반면 4.8에서는 두 설정이 서로 독립적이었다. migration script에 버전 조건을 넣어야 한다. fast mode도 뒤에서 중요한 비교 기준이 된다. 빠른 Opus 5의 요금은 Fable 5와 정확히 같으므로, “fast Opus 5와 기본 Fable 5” 비교는 동일한 token 가격에서 속도와 성능 중 무엇을 택할지의 문제다. 데이터 보관 측면에서는 규정 준수에 이점이 있다. Opus 5는 Fable급 지능을 제공하면서도 Fable 5의 30일 보관 의무가 없다.

표에 담기 어려운 플랫폼 특성도 두 가지 있다. Anthropic 문서에 따르면 thinking을 끄면 드물게 tool call이 사용자에게 보이는 text로 출력되거나 내부 tag가 노출될 수 있다. 아래에서 측정한 agent suite의 thinking-off 호출 84회에서는 두 현상 모두 발생하지 않았다. 그래도 이 지침은 routing 원칙을 뒷받침한다. 추가 비용이 어차피 적은 tool 중심 route에서는 thinking을 켜 두는 편이 낫다. 또 Opus 5의 beta 기능인 대화 중 tool 변경을 사용하면 prompt cache를 무효화하지 않고 turn 사이에 tool을 추가하거나 제거할 수 있다. 긴 agent session에서 prompt caching 가이드의 핵심인 cached prefix의 비용 효율을 유지하는 데 도움이 된다.

기본 설정에서 Opus 5의 비용은 Opus 4.8보다 얼마나 높은가?

같은 요금으로 같은 작업을 처리했지만 3.1배 더 들었다. 현재 Claude의 세 tier를 기본 설정으로 5개 작업 매트릭스에서 실행했다(cell당 n=3, prompt에 salt 적용). native Messages API를 사용했으며, 규모를 비교할 수 있도록 Fable 5도 함께 측정했다.

답은 같고 요금도 4.8과 같지만 청구액은 3배다. Opus 4.8은 요청하지 않는 한 thinking을 수행하지 않는다. Opus 5는 adaptive thinking이 기본으로 켜져 있으며, thinking token에는 출력 요금인 $25/M이 그대로 적용된다.

Fable 5 결과는 직관과 반대다. 요금이 두 배($10/$50)인 모델인데도 기본 Opus 5보다 실제 비용은 35% 낮았다. 같은 작업에 Opus 5는 출력 token 1,305개를 사용했지만 Fable 5는 383개만 사용했기 때문이다. 세 모델 모두 문서상 기본 effort는 high로 같다. 따라서 차이는 설정이 아니라 thinking 보정 방식에서 나온다. 수치에 부합하는 메커니즘은 두 가지다. 첫째, 성능이 높은 모델은 쉬운 답을 확신하는 데 필요한 숙고가 적다. 문장형 문제에서 Fable 5는 52 token을 사용했지만 Opus 5는 152 token을 사용했다. 문단 작성에서는 각각 264 token과 1,031 token이었다. 둘째, Opus 5의 핵심 성능은 test-time compute scaling에 있다. 어려운 문제에서 더 많이 숙고해 품질을 높이는 방식이며, 기본 보정은 이런 대비책을 필요 없는 요청까지 포함해 모든 요청에 적용한다. 쉬운 트래픽에서는 사용하지 않는 대비책에 비용을 내는 셈이다. Fable 5는 대체로 그 비용을 지출하지 않는다.

추가 비용은 어디에 쓰이는가?

사용자가 볼 수 없는 reasoning에 쓰인다. 청구된 출력 token과 실제로 보이는 답변 text를 비교하면, Opus 5 기본 출력 비용의 42-95%가 숨겨진 thinking이었다. thinking이 필요 없는 질문에서도 실행됐다. 17*23의 답은 1 token이었지만 뒤에서 thinking token 11개를 사용했고, 120단어 작성 작업은 출력 token 1,031개 중 약 806개를 숙고에 썼다. thinking 내용은 어떤 형태로도 반환되지 않는다. 요약도 trace도 없다. 따라서 Opus 5는 token 사용량 구조에서 분류한 가시성 범위 중 Fable 5와 함께 가장 폐쇄적인 쪽에 속한다. usage 세부 항목에서 token 수는 확인할 수 있지만, 그 비용으로 무엇을 얻었는지는 알 수 없다.

Thinking switch를 바꾸면 실제로 어떻게 달라지는가?

Opus 5의 청구액이 Opus 4.8과 같아진다. thinking: {"type": "disabled"}를 보내자 모든 작업의 thinking이 0이 됐다. 총 출력 token도 384 대 384로 4.8과 정확히 같았고, 세트당 비용은 $0.01130 대 $0.01120이었다.

먼저 표의 조건명을 설명할 필요가 있다. 세 모델 모두 문서상 API 기본값은 effort high다. Anthropic은 high를 명시하는 것과 parameter를 생략하는 것이 같다고 설명한다. 그런데도 측정에서는 암시적 기본값과 명시적 high 조건이 16% 차이 났다. 이는 실제 설정 차이가 아니라 작성 작업에서 발생한 run 간 변동이다. 작성 작업은 지금까지 실행한 모든 batch에서 변동이 가장 큰 cell이었다. 따라서 두 행은 같은 조건을 두 번 측정한 것으로 보면 된다. 세 모델의 기본값을 가르는 요인은 effort 수준이 아니라 그 수준에서 thinking이 동작하는 방식이다. 4.8은 thinking을 하지 않고, Fable 5는 적은 양을 adaptive하게 사용하며, Opus 5는 더 적극적으로 adaptive thinking을 수행한다.

두 가지 결과가 눈에 띈다. 첫째, effort dial은 비용 조절 장치가 아니라 품질 단계다. low부터 max까지의 단계 자체는 새로운 기능이 아니며 4.8도 같은 범위를 지원한다. 하지만 이렇게 단순한 작업에서는 low보다 높은 모든 단계가 정확도 변화 없이 숙고량만 늘렸다. xhigh에서는 4.8 청구액의 3.8배까지 올라갔다. 상위 단계는 실제로 어려운 문제에서 test-time compute scaling을 적용하기 위한 것이다. 5개 작업으로 구성된 간단한 검증 매트릭스로는 이 성능을 확인할 수 없다. 다만 비용 측면은 확인할 수 있으며, effort dial만으로는 4.8과 같은 수준까지 낮출 수 없다. 기본값보다 67% 낮추려면 thinking을 꺼야 한다. 둘째, Opus 5에는 이 switch 자체가 존재한다. Fable 5는 thinking: {"type": "disabled"}를 400으로 거부한다. 따라서 이는 모델군 전체의 공통 특성이 아니라 Opus 5만의 차별점이다. 같은 thinking object를 gateway의 /v1/messages와 OpenAI 호환 /v1/chat/completions 양쪽에서 사용할 수 있다. 후자에서 thinking을 끄면 completion_tokens_details의 reasoning_tokens가 0으로 보고된다.

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

한계도 분명하다. 검증 가능한 작업은 retrieval과 단일 단계 문제에 가까웠다. thinking을 꺼도 여러 단계의 문장형 문제를 포함해 정확도는 9/9로 유지됐다. 하지만 adaptive thinking은 더 어려운 agentic 작업을 위해 존재한다. 따라서 switch는 route별로 결정해야 한다. Kimi K3와 Gemini 3.6 Flash에서도 같은 결론을 얻었다. 추출, 포맷팅, 단일 단계 호출에서는 끄고, eval에서 thinking의 비용 대비 효과가 확인된 route에서는 기본값을 유지하는 방식이다.

Agent workload에서도 3배의 추가 비용이 유지되는가?

그렇지 않다. 이 차이가 핵심이다. agent 시나리오 suite(tool loop, RAG, tooling, batch, 긴 chat, 조건당 50개 episode)에서 기본 Opus 5의 비용은 Opus 4.8보다 33% 높았다. 210%가 아니었다. tool 중심 시나리오는 거의 같은 수준인 1.01-1.22x였다. 이 환경에서는 adaptive thinking이 실제로 상황에 맞게 동작한다. agent loop 안에서는 호출당 thinking token이 약 88개였지만, 별도의 작성 prompt에서는 806개였다. 예외는 1.58x를 기록한 긴 chat이다. 이 경우 thinking을 끄면 1.22x로 낮아져 여전히 효과가 있다. function calling에서는 thinking 추가 비용이 아예 없었다. 기본 설정에서 tool-call 요청은 thinking 없이 출력 token 52개로 반환됐으며, thinking을 사용하지 않는 모델과 같은 수준이었다.

실무에서는 모델이 아니라 트래픽 형태를 기준으로 나눠야 한다. 일반 completion과 chat 형태의 호출에는 기본적으로 3배의 추가 비용이 붙으므로 switch가 필요하다. tool 중심의 agent 트래픽에서는 대체로 끌 필요가 없다.

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

Switch를 바꾼 뒤에만 그렇다. token 단가는 Opus 5가 $5/$25, Fable 5가 $10/$50이므로 절반이 맞다. 하지만 일반 작업 매트릭스에서 기본 Opus 5의 세트당 비용은 $0.03427이었고, Fable 5는 $0.02233이었다. 실제 비용은 Opus 5가 53% 더 높았다. 같은 작업에서 Fable 5는 출력 token 383개, Opus 5는 1,305개를 사용했기 때문이다. thinking을 끄면 Opus 5의 비용은 $0.01130으로 낮아져 Fable 5 청구액의 거의 정확히 절반이 된다. 출시 당시 약속한 비용이 실현되는 셈이지만, 이를 위해서는 Fable 5 자체는 지원하지 않는 parameter를 설정해야 한다.

Context, cache, tokenizer에서 추가로 확인한 내용은?

1M window는 실제로 지원되며 한도를 넘으면 명확히 실패한다. 969,950-token prompt의 맨 앞에 둔 recall needle을 39초 만에 정확히 반환했다. 1,010,221-token prompt는 조용히 잘리지 않고 prompt is too long: … > 1000000 maximum 오류를 명확히 반환했다.

Cache 하한은 절반으로 낮아졌다. Anthropic 문서에서 Opus 5와 Fable 5의 cache 가능한 최소 prefix는 512 token이다. Opus 4.8과 Sonnet 5의 1,024 token보다 낮다. sweep 결과도 이와 일치했다. 511 token 부근의 prefix는 한 번도 cache되지 않았고, 547 token부터는 안정적으로 cache됐다. cached read 요금은 $0.50/M(0.1x), write는 1.25x이며 TTL은 5분이다. 이제 더 짧은 system prompt도 cache할 수 있어 high-QPS route에서 유용하다.

Opus 5, Opus 4.8, Fable 5, Sonnet 5의 tokenizer는 바뀌지 않았다. 다국어 및 코드 sample에서 token 수가 모두 같았다. 따라서 언어별 예산과 prompt 크기 추정치를 다시 기준화할 필요 없이 그대로 사용할 수 있다.

FAQ

Claude Opus 5에서 thinking을 끌 수 있는가?

그렇다. effort high 이하에서 끌 수 있다. 문서에 따르면 xhigh 또는 max와 함께 사용하면 400을 반환한다. 측정에서는 thinking token이 0이 됐고, 비용도 Opus 4.8과 같은 수준으로 낮아졌다. 매트릭스에서 출력 token은 384 대 384였다. 이 기능은 Opus 5에만 해당한다. Fable 5는 effort와 관계없이 같은 parameter를 400으로 거부한다. low부터 max까지의 effort dial도 동작하지만 같은 수준까지 비용을 낮출 수는 없다. 매트릭스에서 기본값 대비 low는 -21%, xhigh는 +24%였다.

정가가 같은데 Opus 5 청구액이 Opus 4.8보다 높은 이유는 무엇인가?

Opus 5는 기본적으로 thinking을 수행하며, thinking에는 출력 요금인 $25/M이 적용되기 때문이다. 일반 prompt에서 청구된 출력 token 중 42-95%가 숨겨진 reasoning이었다. 두 자릿수 곱셈에서도 1-token 답변 뒤에 thinking token 11개가 붙었다. 자체 트래픽에서 비중을 확인하려면 usage 세부 항목의 reasoning_tokens를 읽고, thinking이 필요 없는 route에서는 비활성화하면 된다.

Opus 5를 사용하는 agent workload에서도 thinking을 꺼야 하는가?

대체로 그럴 필요가 없다. agent suite에서 기본 비용은 Opus 4.8 대비 +33%에 그쳤고, tool 및 batch 시나리오는 거의 같은 수준이었다. tool loop 안에서는 adaptive thinking이 거의 실행되지 않기 때문이다. 예외는 긴 chat 형태의 session으로, 비용이 1.58x였다. 이 경우 switch를 바꾸는 효과가 있다. 실제 트래픽 구성을 직접 측정해야 한다. 추가 비용은 tool call보다 일반 completion에서 발생한다.

2026-07-25부터 2026-07-27까지 Synthorai gateway를 통해 claude-opus-5, claude-opus-4-8, claude-fable-5를 측정했다. 5개 작업 매트릭스와 effort/switch ablation은 하나의 기준 batch에서 수행했다(cell당 n=3, prompt에 salt 적용, native Messages API). agent 수치는 150개 episode로 구성된 시나리오 suite에서 얻었다. context와 cache는 needle-recall 및 prefix sweep으로 확인했고, API 형태 관련 항목(prefill, switch 허용 여부)은 직접 요청해 검증했다. 정확도는 하나의 정답으로 확인 가능한 작업만 집계했다. 가격과 동작은 바뀔 수 있으므로 자체 usage 기록을 기준으로 다시 확인해야 한다.

← 블로그로 돌아가기