Claude Opus 5의 공개 이후, 「Fable 5를 모든 고난도 태스크에 계속 사용할 것인가」, 「일상적인 복잡한 태스크는 Opus 5로 전환해도 괜찮은가」라는 판단이 필요해졌습니다.

이 비교에서 중요한 것은 벤치마크 순위만이 아닙니다. 요금, 데이터 보유, fallback, 재시도, 인간에 의한 수정까지 포함하여, 합격한 결과물을 하나 얻기 위한 비용을 살펴볼 필요가 있습니다.

• 공개 사양을 통해 세울 수 있는 운용 가설은, Opus 5를 일상적인 고난도 태스크의 기본(default) 후보로, Fable 5를 장시간·고모호도·실패 비용이 큰 태스크의 승격 후보로 두는 것입니다. Opus 5의 공식 Token 단가는 Fable 5의 절반이지만, 실제 태스크 비용까지 반드시 절반이 되는 것은 아닙니다.

• 30일간의 데이터 보유 요건이나 fallback 처리는 벤치마크보다 먼저 모델을 후보에서 제외하게 만들 수 있습니다.

• Claude API로 복잡한 Coding Agent나 장시간 태스크를 구동하고 있는 사람

• Opus 5와 Fable 5 중 어느 쪽을 표준 루트로 할지 검토 중인 사람

• Token 단가가 아니라, 재시도나 인적 수정을 포함한 총비용을 비교하고 싶은 사람

• requested model과 response model을 구분하여 평가 로그에 남기고 싶은 사람

이 기사는 2026년 7월 25일 시점의 Anthropic 공식 사양과 제3자 평가를 정리한 것입니다.

Opus 5와 Fable 5에 동일한 태스크를 보낸 자사 독립 실측이 아닙니다. 따라서 본문의 「기본 후보」, 「승격 후보」는 공개 사양으로부터 세운 검증 전의 운용 가설입니다.

또한, 서로 다른 벤치마크, effort, Agent harness, fallback 설정의 스코어를 일렬로 나열하여 「종합적인 승자」를 결정하지는 않습니다.

여기서 가장 주의해야 할 점은, 동일한 1M Context와 128K 출력을 가지고 있더라도, 같은 제품이 아니다라는 점입니다.

가격, Latency, Thinking 제어, 데이터 보유, 안전 분류기(Safety classifier)의 동작이 다르기 때문에, Context 길이만으로 대체 가능성을 판단할 수 없습니다.

공식 가격만 보면, Opus 5의 Input / Output 단가는 Fable 5의 정확히 절반입니다.

한편, Artificial Analysis의 Intelligence Index 태스크에서는 Opus 5 max의 평균 비용이 $2.03...

fallback을 포함한 Fable 5가 $2.75라고 보고되었습니다. 이 차이는 약 26%이며, 50%가 아닙니다.

이는 공식 가격이 틀렸다는 의미가 아닙니다. 실제 태스크(Task)에서는 다음 요소들이 총비용을 변화시키기 때문입니다.

• 사용한 Input / Output Tokens
• Prompt cache의 write와 hit
• effort에 따른 출력 Token량의 차이
• Tool call과 외부 서비스 비용
• 실패한 시도와 재실행
• fallback 이후 실제로 응답한 모델
• 사람이 수정, 확인, 재지시하는 데 사용한 시간

그림 1: Token 단가에서 accepted task cost까지 사이에는 워크플로우(Workflow) 고유의 변수가 있습니다

제3자 평가 수치 또한 해당 harness와 설정에서의 결과입니다. 자사의 Repository나 Agent workflow에 그대로 외삽(Extrapolation)할 수는 없습니다.

모델 비교에서는 1회의 API 요금이 아니라, 합격 조건을 충족한 결과물을 하나 얻기까지의 총비용을 사용합니다.

accepted_task_cost
= Σ(api_token_cost + cache_cost + tool_cost) # 실패분을 포함한 모든 시도
+ human_fix_minutes × hourly_rate / 60

여기서 말하는 "accepted"는 출력이 반환되었다는 것을 의미하지 않습니다. 예를 들어 Repository-level의 Bug Fix라면, 적어도 다음 조건을 먼저 고정해야 합니다.

• 원래의 결함을 재현할 수 있음
• 수정 후 원래의 실패 케이스가 통과됨
• 기존 테스트에 회귀(Regression)가 없음
• 변경 범위가 요구사항을 초과하지 않음
• Reviewer가 설명과 diff를 확인할 수 있음

합격하지 못한 시도의 Token, Tool, 대기 시간, 인적 수정 비용도 최종적인 accepted task cost에 포함합니다.

그림 2: 계약상의 제약을 확인한 후, 동일한 합격 조건으로 모델을 승격시키는 판단 플로우(Flow)입니다

이 플로우의 목적은 Fable 5를 "항상 최강이니까 사용한다"거나, Opus 5를 "반값이라서 고정한다"는 것이 아닙니다.

태스크의 실패 비용과 계약상의 제약을 먼저 살펴보고, 동일한 합격 조건으로 비교하는 것이 목적입니다.

최소 비교 단위로서 실제 Repository에 있는 Bug Fix를 하나 선택합니다.

• 동일한 commit, Prompt, Tool, 권한, Timeout, 테스트를 준비한다
• 먼저 합격 조건과 변경 금지 범위를 작성한다
• Opus 5에서는 effort를 명시하고, 적어도 1개의 기준 결과를 얻는다
• 미합격, 재작업(rework)이 크거나, 또는 실패 대가가 높은 경우 Fable 5를 동일 조건에서 테스트한다
• 최종 출력뿐만 아니라, 실패한 시도, Tool call, 인공적 개입도 집계한다

비교 중에 Prompt나 Tool을 변경한 경우에는 별도의 조건으로 기록합니다. 조건을 도중에 변경한 채로 모델 차이로 집계하면, routing 판단을 그르치게 됩니다.

이하는 결과가 아니라 비교 시 채워 넣기 위한 템플릿입니다.

{
"task_id": "",
"requested_model": "",
...

특히 requested_model과 response_model은 구분합니다.

fallback에 의해 다른 모델이 응답한 경우, 그 결과를 requested model의 성능으로 계산해서는 안 됩니다. 또한, 성공한 마지막 시도만을 남기면 재시도 비용이 사라지게 됩니다.

• 양쪽 Route에서 동일 조건의 first call, usage, Latency, 과금을 확인한 결과
• Repository-level Coding, 장시간 Agent, Image-to-HTML에서의 반복 시험 결과
• fallback이 실제로 발생했을 때의 response model과 품질 차이
• 자사의 태스크에서 Fable 5의 추가 비용이 재작업 감소를 통해 회수 가능한지 여부

공개 사양과 벤치마크는 시도해 볼 태스크를 고르는 재료는 될 수 있습니다. 하지만 Production routing을 확정하는 증거는 되지 않습니다.

Opus 5의 등장으로 인해 Fable 5가 불필요해진 것은 아닙니다. 달라진 점은, Fable 5를 모든 복잡한 태스크 (task)의 기본값 (default)으로 설정할 필요성이 사라졌다는 것입니다.

먼저 Opus 5를 일상적인 고난도 태스크의 후보로 측정하고, 장시간 소요·고모호도·실패 비용이 큰 작업만을 Fable 5로 승격시키는 방식입니다. 이 가설을 토큰 (Token) 단가가 아닌 수락된 태스크 비용 (accepted task cost)으로 검증하는 것이 실무적입니다.

처음 비교를 시작한다면, 공개 벤치마크 (benchmark)를 재현하기보다는 팀에서 재작업 비용 (rework cost)이 가장 높은 실제 태스크를 하나 선정하는 것이 판단하기 쉽습니다.