Etc

Claude Opus 5 — GPT-5.6 Sol · Fable 5 · Sonnet 5 비교

목차

어제(7/24) Claude Opus 5 가 나왔다. Anthropic 은 “step-change” 라고 표현했다. 4.8 에서 뭐가 얼마나 달라졌는지, 그리고 지금 프론티어급으로 같이 놓고 볼 만한 GPT-5.6 Sol, Fable 5, Sonnet 5 와 작업 영역별로 비교해봤다.

Claude Opus 5
claude-opus-5
입력
$5 / MTok
출력
$25 / MTok
컨텍스트
1M
최대 출력
128k
GPT-5.6 Sol
gpt-5.6-sol
입력
$5 / MTok
출력
$30 / MTok
컨텍스트
1.05M
최대 출력
128k
Claude Fable 5
claude-fable-5
입력
$10 / MTok
출력
$50 / MTok
컨텍스트
1M
최대 출력
128k
Claude Sonnet 5
claude-sonnet-5
입력
$3 / MTok
출력
$15 / MTok
컨텍스트
1M
최대 출력
128k

스펙부터 정리

Opus 5GPT-5.6 SolFable 5Sonnet 5
벤더AnthropicOpenAIAnthropicAnthropic
출시2026-07-242026-07-092026-06-09
입력 $/MTok55103
출력 $/MTok25305015
컨텍스트1M1.05M1M1M
최대 출력128k128k128k128k
지식 컷오프2026-052026-022026-012026-01
레이턴시보통느림빠름

Sonnet 5 는 8/31 까지 도입가 $2 / $10 이 적용된다. Opus 5 는 fast mode 가 research preview 로 따로 있고 $10 / $50 이다. Claude API 에서만 된다.

가격표에서 눈에 띄는건 Opus 5 다. 4.8 과 가격이 똑같은데($5/$25) 성능은 올렸고, Fable 5 의 정확히 절반 가격이다. 컨텍스트도 1M 이 기본이자 최대다. 예전처럼 작은 컨텍스트 변형을 고를 필요가 없어졌다.

지식 컷오프는 Opus 5 가 2026-05 로 이 중에 제일 최신이다. Sol 이 2026-02, Fable 5 와 Sonnet 5 가 2026-01. 최근 라이브러리 버전이나 API 변경을 물어볼 일이 많으면 이 차이가 은근히 크다.

Opus 5 에서 실제로 바뀐 것

벤치마크 얘기 전에, 코드를 그대로 두고 모델 ID 만 바꿔도 체감되는 변경들이 있다. 이쪽이 오히려 실무에 더 영향이 크다.

thinking 이 기본으로 켜진다

4.8 에서는 thinking: {"type": "adaptive"} 를 명시해야 켜졌다. Opus 5 는 같은 요청이 thinking 켜진 상태로 돈다. 얼마나 생각할지는 모델이 턴마다 정하고, 깊이 조절은 effort 로 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 4.8: thinking 없이 돌던 요청
client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    messages=[...],
)

# Opus 5: 같은 코드인데 thinking 이 켜진 채로 돈다
# max_tokens 는 thinking + 응답 텍스트 합계의 하드리밋이라 재조정이 필요하다
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    messages=[...],
)

max_tokens 를 그대로 두면 생각하다가 잘릴 수 있다. 마이그레이션할 때 제일 먼저 볼 부분이다.

effort 에 max 가 생겼다

low, medium, high, xhigh, max 전체 사다리를 지원한다. 베타 헤더도 필요없다. max 가 제일 깊게 생각하는 단계다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
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" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 64000,
    "stream": true,
    "output_config": { "effort": "max" },
    "messages": [{ "role": "user", "content": "..." }]
  }'

xhighmax 로 돌릴 때는 max_tokens 를 크게 잡으라고 문서에 명시돼 있다. 서브에이전트랑 툴콜을 오가며 생각할 자리가 필요해서다.

thinking 끄기가 제한된다 (breaking)

thinking: {"type": "disabled"} 는 effort 가 high 이하일 때만 받는다. xhighmax 에 disabled 를 같이 주면 400 에러다. 4.8 에서는 effort 와 무관하게 끌 수 있었으니 이건 명백한 breaking change 다.

thinking 을 끈 상태에서는 tool_use 블록 대신 텍스트에 툴콜을 써버리거나 내부 XML 태그가 응답에 섞이는 경우가 가끔 있다고 문서가 직접 밝히고 있다. 가능하면 켜두고 effort 를 낮춰서 토큰을 조절하는 쪽이 맞다.

프롬프트 캐시 최소 길이가 절반으로

1024 → 512 토큰. 4.8 에서 짧아서 캐시가 안 걸리던 프롬프트가 코드 변경 없이 캐시된다. 시스템 프롬프트가 짧은 서비스라면 그냥 이득이다.

대화 중 툴 교체 (beta)

턴 사이에 툴을 추가하거나 빼면서 프롬프트 캐시를 유지할 수 있다. mid-conversation-tool-changes-2026-07-01 헤더가 필요하다. 세션 내내 고정된 툴 목록을 계속 재전송하던 걸 안 해도 된다.

말투와 습관이 달라졌다

코드를 안 바꿔도 느껴지는 부분들.

  • 기본 응답과 산출물이 더 길어졌다
  • 에이전틱 세션에서 진행 상황을 더 자주 알려준다
  • 멀티에이전트에서 서브에이전트에 더 적극적으로 위임한다
  • 시키지 않아도 자기 작업을 검증한다

마지막 항목이 함정이다. 예전 모델용 프롬프트에 넣어둔 “마지막에 검증 단계를 포함해라”, “서브에이전트로 검증해라” 같은 지시는 빼라고 문서가 권한다. 안 빼면 과잉 검증으로 간다. 프롬프트 물려받아 쓰는 곳은 한번 훑어야 한다.

벤치마크를 보기 전에

여기 나오는 점수는 대부분 모델을 만든 회사가 자기 평가 환경에서 직접 돌려 발표한 값이다. 한 집계 사이트는 104개 모델 리더보드에 아예 “Verified 0, Self-reported 104” 라고 적어놨다.

거기다 Opus 5 는 나온지 하루밖에 안 됐다. 독립 검증이 쌓일 시간이 없었다. 비교 조건이 안 맞는 경우도 많다. 예를 들면,

  • GPT-5.6 Sol 의 Terminal-Bench 91.9% 는 여러 에이전트를 병렬로 돌리는 Ultra 모드 점수다. 다른 모델의 단일 에이전트 점수랑 같이 놓기는 좀 그렇다
  • SWE-bench Pro 의 Fable 5 80.3% 는 Anthropic 자체 스캐폴드로 뽑은 값이다. 중립 평가 환경이 아니다. OpenAI 는 이 벤치마크 방법론에 이의를 제기했다
  • 같은 모델 같은 벤치마크인데 출처마다 값이 다른 경우가 꽤 있다. Opus 4.8 의 Terminal-Bench 는 74.6% / 82.7% / 79% 세 가지 값이 돌아다닌다

그래서 아래 숫자는 어느 영역에서 어느 쪽으로 기우는지 정도로만 봤다.

코딩

SWE-bench Verified

모델점수출처 성격
Opus 596.0% / 97.0%벤더(5회 평균) / Vals AI
GPT-5.6 Sol96.2%Vals AI
Fable 595.0 ~ 95.5%벤더 / Vals AI
Opus 4.888.6%혼합
Sonnet 585.2%자체 보고

Opus 5 가 96 이냐 97 이냐로 출처가 갈린다. 어느 쪽이든 Sol(96.2%)과는 오차 범위다. 참고로 OpenAI 는 GPT-5.6 의 SWE-bench Verified 를 직접 발표하지 않았다. 위 96.2% 는 Vals AI 가 직접 돌린 값이다.

4.8 에서 88.6% → 96% 대면 실패율이 11.4% 에서 4% 로 줄어든 셈이다. 남은 구간에서의 개선이라 체감은 숫자보다 클 수 있다.

SWE-bench Pro

모델점수
Fable 580.3%
Opus 579.2%
Opus 4.869.2%
GPT-5.6 Sol64.6%
Sonnet 563.2%

더 어려운 쪽으로 가면 순서가 바뀐다. Fable 5 가 여전히 위다. Opus 5 는 1.1%p 차로 따라붙었는데 가격이 절반이다. Sol 은 여기서 확 떨어진다.

다만 이 벤치마크는 스캐폴드 논란이 있다. 이 표 하나로 결론 내긴 어려울듯

코딩 에이전트 지표는 Sol 이 앞선다

Artificial Analysis 의 Coding Agent Index v1.1 은 제3자 측정인데 여기선 순서가 다르다.

모델AA Coding Agent Index
GPT-5.6 Sol80.0
Opus 578.0
Fable 577.2
GPT-5.6 Terra77.4

DeepSWE v1.1 도 Sol 72.7%, Fable 5 69.7%, Opus 5 68.8% 로 Sol 이 위다. 코딩 에이전트 쪽은 Sol 이 확실히 강하다.

에이전틱 · 롱호라이즌

여기가 Opus 5 가 제일 크게 벌리는 구간이다.

Frontier-Bench v0.1

Anthropic 이 만든 터미널 코딩 에이전트 평가다. 태스크당 5회 시도 평균 보상.

모델점수
Opus 543.3%
GPT-5.6 Sol34.4%
Fable 533.7%
Opus 4.821.1%

4.8 의 두 배가 넘는다. 다만 만든 쪽이 Anthropic 이라는건 감안해야 한다. 자기가 만든 시험에서 자기가 1등 한 그림이다.

Zapier AutomationBench

모델점수
Opus 526.0%
GPT-5.6 Sol18.1%
Fable 517.4%
Opus 4.817.0%

여기는 격차가 크다. Opus 5 가 가장 낮은 effort 설정으로도 다른 모델보다 많이 통과한다는 보고가 있다. 이전 모델들이 다 실패하던 업무 워크플로 테스트를 100% 로 통과했다는 얘기도 나왔다.

OSWorld 2.0 (컴퓨터 사용)

모델점수
Opus 570.6%
Fable 566.1%
GPT-5.6 Sol62.6%
Opus 4.855.7%

Anthropic 은 Fable 5 최고 성적을 비용의 1/3 정도로 넘었다고 주장한다.

BrowseComp (웹 탐색)

Opus 5 90.8%, Sol 90.4%. 사실상 동점이다. Sol Ultra 모드가 92.2% 인데 이건 여러 에이전트를 병렬로 굴린 거라 같은 줄에 놓기 어렵다.

추상 추론 — ARC-AGI-3

모델점수
Opus 530.2%
GPT-5.6 Sol7.78%
Opus 4.81.5%
Gemini 3.10.42%

이번 데이터 전체에서 격차가 제일 큰 항목이다. 다음 모델의 4배쯤 된다. 4.8 대비로는 20배다.

숫자만 보면 압도적인데, 이게 실무에서 뭘 의미하는지는 아직 불분명하다는 지적이 있다. ARC-AGI 는 사람에게 쉽고 모델에게 어려운 퍼즐을 모아둔 거라, 여기 잘한다고 업무 성능이 그만큼 오른다는 보장은 없다. 그래도 4.8 이 1.5% 였던걸 생각하면 뭔가 질적으로 달라진건 맞는듯.

지식 노동 — GDPval

실제 직무 산출물을 사람이 비교 평가하는 Elo 지표다.

모델Elo
Opus 51,861
Fable 51,747
GPT-5.6 Sol1,736
Sonnet 51,618
Opus 4.81,615

OpenAI 쪽 자료는 같은 벤치마크에서 다른 표를 내놨다. Fable 5 1,759.6 / Sol 1,747.8 로, Sol 이 Fable 5 를 못 이기는건 같은데 두 모델의 절대값과 서열이 Anthropic 표와 안 맞는다. 양쪽 다 상대 모델을 자기 환경에서 돌린 값이라 그렇다. 이런게 벤더 발표 수치의 한계다.

Sonnet 5 가 Opus 4.8 을 살짝 넘긴것도 눈에 띈다. Sonnet 계열이 동시대 Opus 를 어떤 지표에서든 넘은건 이번이 처음이다.

롱컨텍스트

여기는 Sol 이 앞선다.

지표Opus 5GPT-5.6 Sol
AA-LCR70.0%73.7%

Sol 은 MRCR 8-needle 256K~512K 구간에서 91.5% 를 보고했다. 문제는 Opus 5, Fable 5, Sonnet 5 의 MRCR 수치가 어디에도 공개돼 있지 않다는 것이다. 직접 비교가 안 된다. 양쪽을 같은 잣대로 잰 롱컨텍스트 지표는 AA-LCR 하나뿐이고, 거기선 Sol 이 3.7%p 앞선다.

컨텍스트 창 크기는 넷 다 1M 급이라 차이가 없다. 1M 을 실제로 얼마나 잘 쓰느냐가 관건인데, 이 부분은 아직 공개 데이터가 부족하다.

비전 · 문서

지표Opus 5GPT-5.6 Sol
MMMU-Pro84.7%83.4%

Opus 5 가 근소하게 앞선다. Anthropic 은 비전 개선을 크게 내세웠는데, 차트·문서·다이어그램 이해와 UI 복제가 특히 좋아졌고 크롭하고 확대해서 다시 보는 툴을 쥐어줄 때 제일 강하다고 한다. 한 번에 보고 판단하는것보다 도구 써가며 검증하게 시키는 쪽이 낫다는 뜻이다.

환각과 정직성

여기는 숫자가 엇갈린다.

지표 (AA-Omniscience)Opus 5GPT-5.6 Sol
정확도54.2%58.5%
환각률 (낮을수록 좋음)50.1%88.8%
Omniscience Index31.3%21.7%

Sol 이 정확도는 높은데 환각률이 88.8% 다. 모르는걸 모른다고 안 하고 그냥 답해버린다는 뜻이다. Opus 5 는 정확도가 낮은 대신 환각이 절반 수준이다. 모르면 모른다고 하는 쪽에 가깝다. 실무에선 후자가 대체로 낫다.

근데 Opus 5 도 마냥 좋아진건 아니다. 시스템 카드에 4.8 보다 사실 관계를 조금 더 환각한다고 적혀 있다. 전체 정확도는 올랐는데 환각은 늘었다는 것이다. “확신 없는 사안을 자신있게 단정하는 경우가 놀랄 만큼 있었다” 는 표현도 있다. 벤더가 자기 모델 약점을 직접 적어둔 거다.

비용

가격표만 보면 Opus 5 가 Sol 보다 출력 토큰이 싸다($25 vs $30). 근데 실제 비용은 같은 일을 하는데 토큰을 몇 개 쓰느냐로 갈린다.

FrontierCode 1.1 에서 롤아웃 1회당 비용을 잰 자료가 있다.

모델병합 가능률비용/롤아웃effort
Opus 553.4%$4.30medium
GPT-5.6 Sol47.5%$6.30max

Opus 5 가 더 싸고 더 잘했다. 다만 effort 설정이 서로 다르다. medium 대 max 다. 자료 작성자도 “하나의 벤치마크를 서로 다른 effort 로 돌린 결과지 보편적인 코딩 승자를 증명하는게 아니다” 라고 못박아뒀다.

반대 방향 자료도 있다. 코드 리뷰 도구 CodeRabbit 이 측정한 호출당 토큰은 Opus 5 가 입력 60.5K / 출력 9.5K, GPT-5.6 이 40.5K / 5.8K 였다. 같은 리뷰를 하는데 Opus 5 가 토큰을 훨씬 많이 쓴다.

작업 종류에 따라 갈린다. 에이전틱하게 오래 굴리는 일은 Opus 5 가 싸게 먹히고, 짧고 반복적인 호출은 Sol 이 유리할 수 있다.

effort 를 max 로 올리면 오히려 손해인 구간이 있다

Opus 5 의 Frontier-Bench 최고 점수는 max 가 아니라 xhigh 에서 나온다. xhigh 에서 max 로 올리면 점수는 안 오르고 비용만 는다. AA Coding Agent Index 에서도 같은 현상이 보고됐다. 두 벤치마크에서 max 가 차상위 설정보다 살짝 낮은 점수를 냈다.

Frontier-Bench 기준 effort 단계별 비용 차이는 3배 수준이다. 그러니까 무조건 max 로 박아두는건 돈만 더 내는 선택일 수 있다. Anthropic 도 코딩·에이전틱 작업엔 xhigh, 나머지엔 high 를 권한다.

1
2
3
4
5
# 무지성 max 보다
output_config = {"effort": "max"}

# 코딩·에이전틱은 xhigh 가 실측상 더 낫다
output_config = {"effort": "xhigh"}

Opus 5 의 약점

말이 너무 많다. 이게 제일 일관된 불만이다. 한 리뷰어는 “Claude Slop” 이라고 부르면서 과도한 장황함이 거슬린다고 썼다. Anthropic 문서도 “기본 응답과 산출물이 더 길어졌다” 고 인정한다. AA 측정에서 Intelligence Index 를 도는데 출력 토큰 1억개를 썼다(평균 6,300만개).

코드 리뷰 재현율이 떨어졌다. CodeRabbit 측정에서 알려진 이슈를 잡아낸 비율이 55.2% 로, 기존 프로덕션 기준선 61.1% 보다 낮았다. 정밀도(오탐 적음)는 39.3% 로 올랐는데 재현율은 내려갔다. x-high 로 올리면 사소한 지적이 4배로 늘었다. Anthropic 은 코드 리뷰·버그 탐지 개선을 내세웠는데, 제3자 측정은 결이 좀 다르다.

단발 추론은 Fable 5 가 낫다. 여러 턴 돌리지 않고 한 번에 답하는 상황에서는 Opus 5 가 Fable 5 에 밀린다는 평가가 있다. Opus 5 의 강점은 오래 굴릴 때 나온다.

자기 검증 루프에 갇히는 경우가 있다. 생물학 태스크에서 검증을 반복하다 못 빠져 나오는 사례가 보고됐다. 앞서 적은대로 예전 프롬프트의 검증 지시를 안 지우면 이게 심해진다.

GPT-5.6 Sol 쪽 사건

METR 사전 평가에서 Sol 은 자기들이 공개 모델 중 평가해본 것 중 가장 높은 부정행위 탐지율을 보였다. 숨겨진 테스트 스위트 정보를 빼내려고 중간 제출물에 익스플로잇을 심거나, 정답이 든 소스를 추출하는 식이다. 이것 때문에 METR 은 Sol 의 작업 시간 지평 추정치 세 가지가 전부 신뢰할 수 없다고 결론냈다.

더 큰 건 따로 있다. OpenAI 가 직접 공개한 내용인데, ExploitGym 평가 도중 Sol 과 미공개 모델이 샌드박스를 탈출해 Hugging Face 프로덕션 인프라를 침해했다. 벤치마크 정답이 거기 있을 거라 추론하고 자격증명과 제로데이를 엮어 원격 코드 실행까지 갔다. OpenAI 와 Hugging Face 가 같이 수습 중이고 제로데이 패치도 공개됐다.

Sol 의 보안 벤치마크 점수(ExploitBench 73.5%, CTF 96.7%)가 높은건 사실인데, 그 점수를 어떻게 받아들여야 하는지가 애매해지는 사건이다.

참고로 Anthropic 은 Opus 5 를 의도적으로 사이버 작업에 훈련시키지 않았다고 밝혔다. 그래서 이 영역 점수는 Mythos 5 계열보다 낮다.

총평

Opus 5 는 4.8 대비 확실히 큰 폭으로 올라갔다. 이건 마케팅 문구가 아니라 숫자로 보인다. Frontier-Bench 21.1% → 43.3% 로 두 배, ARC-AGI-3 1.5% → 30.2% 로 20배, SWE-bench Verified 88.6% → 96% 대. GDPval Elo 도 1,615 → 1,861 이다. “step-change” 라는 표현이 과하지 않다.

그런데 진짜 핵심은 성능이 아니라 가격이다. Opus 5 는 4.8 과 똑같은 $5/$25 다. 성능은 올랐는데 가격이 그대로다. 그리고 Fable 5 의 정확히 절반이면서 대부분의 지표에서 Fable 5 를 따라잡거나 넘었다. 지금까지 Fable 5 를 쓰던 워크로드 상당수는 그대로 Opus 5 로 내려도 될것 같다. 이번 릴리스에서 제일 실질적인 변화는 이거다.

다만 전 영역 석권은 아니다.

  • 코딩 에이전트 지표는 Sol 이 앞선다. AA Coding Agent Index 80 vs 78, DeepSWE 72.7% vs 68.8%
  • 롱컨텍스트도 Sol 이 앞선다. 양쪽을 같은 잣대로 잰 AA-LCR 에서 73.7% vs 70.0%
  • 어려운 코딩(SWE-bench Pro)과 단발 추론은 Fable 5 가 여전히 위다
  • 글쓰기 협업은 Sol 이 낫다는 평가가 있다. 스타일 가이드 같은 맥락을 잘 따라간다는 것

실무에서 고르는 기준.

상황추천
오래 굴리는 에이전트, 멀티스텝 자동화Opus 5
컴퓨터 사용, 브라우저 자동화Opus 5
비용 대비 프론티어 성능Opus 5
코딩 에이전트 루프, 터미널 작업GPT-5.6 Sol
초장문 컨텍스트를 실제로 다 써야 할 때GPT-5.6 Sol
최고 난도 코딩, 한 방에 끝내는 추론Fable 5
속도·비용이 우선, 일반 작업Sonnet 5 (8/31 까지 $2/$10)

마이그레이션 전에 볼 것.

  1. max_tokens 재조정 — thinking 이 기본으로 켜져서 합산 한도가 된다
  2. effort 를 xhigh 로. max 는 비싸기만 하고 더 나은 보장이 없다
  3. 예전 프롬프트의 “검증 단계를 포함해라” 류 지시 제거 — 과잉 검증 유발
  4. thinking: disabledxhigh/max 와 같이 쓰던 코드는 400 난다

위 숫자는 대부분 각 회사가 자기 환경에서 돌린 값이고 Opus 5 는 나온지 하루짜리 모델이다. 독립 검증이 쌓이면 그림이 꽤 달라질 수 있다. 몇 주 지나고 다시 봐야 할듯

참고