Claude Opus 5 vs Claude Fable 5: Fable에 2배 비용을 낼 가치가 있을까?
$5 / $25에 출시했고 코딩, 컴퓨터 사용, knowledge work 평가에서 Fable 5를 앞서거나 근접한 결과를 공개했습니다. 동시에 Fable 5는 여전히 널리 제공되는 Claude 중 최고 성능 모델로 설명됩니다.Claude Opus 5 vs Fable 5 한눈에 보기
| 기준 | Claude Opus 5 | Claude Fable 5 | 운영 의미 |
|---|---|---|---|
| 포지션 | 복잡한 agentic coding용 일상 프리미엄 | 널리 출시된 Claude 중 최고 능력 | Opus로 시작하고 가치가 있을 때만 Fable |
| 공식 가격 | $5 / $25 per MTok | $10 / $50 per MTok | Fable 토큰 비용 2배 |
| Context / 출력 | 1M / 128K | 1M / 128K | 용량만으로 구분되지 않음 |
| 상대 지연 | Moderate | Slower | 대화형 프리미엄 기본은 Opus가 적합 |
| Thinking | Adaptive 기본, high 이하에서 비활성화 가능 | Adaptive 항상 활성 | Opus가 저추론 작업 제어에 유리 |
| 근거 | 코딩, 자동화, 문제 해결에서 강한 출시 결과 | Anthropic 최고 능력 경로 | 개별 benchmark가 실작업 평가를 대체하지 않음 |
| 안전 / 보존 | Anthropic은 Fable보다 classifier 개입이 적다고 설명, 일반 접근 보존 요건 없음 | 추가 classifier, 30일 보존, ZDR 미지원 | 거버넌스가 품질보다 먼저 경로를 결정할 수 있음 |
먼저 Opus 5로 보내고, 검증 실패·낮은 확신·매우 높은 작업 가치가 있을 때만 Fable 5로 올리세요.
Claude 앱, 코딩 에이전트, API를 구분하세요
“Opus 5인가 Fable 5인가”에는 실제로 세 가지 결정이 숨어 있습니다.
| 사용 면 | 실제 결정 | 시작점 |
|---|---|---|
| Claude 앱 | 한 번의 대화나 어려운 단일 작업에 쓸 모델 | 먼저 Opus, 비용보다 최대 능력이 중요할 때만 Fable |
| Claude Code 등 코딩 에이전트 | 계획, 구현, 디버깅, 리뷰 분담 | 실행은 Opus, 측정된 escalation·계획·리뷰만 Fable |
| API 또는 agent platform | Default, 예산, 관측, rollback 설계 | 모델 하나를 고정하지 말고 작업군별 routing |
이 글은 운영 API와 agent 팀에 초점을 둡니다. 앱의 모델 선택과 구독 한도는 바뀔 수 있으므로 운영 architecture의 근거로 삼지 않습니다.
Opus 5가 Fable의 가치 판단을 바꾼 이유
Anthropic에 따르면 Opus 5는 CursorBench 3.2 max effort에서 Fable 5 최고점의 0.5%p 이내이며 작업당 비용은 약 절반입니다. OSWorld 2.0에서는 Fable 최고 결과를 약 3분의 1이 조금 넘는 비용으로 앞섰고 Frontier-Bench v0.1에서도 선두입니다.
| 근거 | 지지하는 결론 | 증명하지 못하는 것 |
|---|---|---|
| Anthropic Frontier-Bench / CursorBench | 특정 coding harness에서 Opus가 동등하거나 우수할 수 있음 | 모든 저장소와 tool stack 승리 |
| Anthropic OSWorld 2.0 | 테스트된 PC 작업에서 비용 효율 우수 | 모든 agent에서 더 빠르고 저렴 |
ARC Prize: high ARC-AGI-3 30.16% | 7월 24일 기준 검증된 최고점 | Fable 직접 비교. 공개 표에 Fable 점수 없음 |
| Anthropic 모델 가이드 | Fable은 최고 능력 경로 | 최고 tier가 최적 default |
이제 입증 책임은 Fable에 있습니다. 각 작업군에서 추가 가치를 보여야 합니다.
운영 결정을 바꾸는 기술 사양
| 항목 | Claude Opus 5 | Claude Fable 5 | Routing 의미 |
|---|---|---|---|
| Anthropic 포지션 | 복잡한 agentic coding과 기업 업무의 시작 모델 | 널리 제공되는 최고 능력 모델 | Opus를 먼저 검증 |
| 공식 토큰 가격 | Input $5 / Output $25 per MTok | Input $10 / Output $50 per MTok | Fable은 처음부터 2배 |
| Context / 최대 출력 | 1M / 128K tokens | 1M / 128K tokens | 한도는 같아도 긴 trace 신뢰성은 따로 평가 |
| 신뢰 가능한 knowledge cutoff | 2026년 5월 | 2026년 1월 | 최신 개발 지식은 Opus가 유리할 수 있음 |
| 상대 latency | Moderate | Slower | 대화형 loop는 Opus부터 |
| Thinking / effort | Adaptive 기본, low~max | Adaptive 항상 활성, effort 제어 | 같은 effort로 비교 |
| 공개 보존 조건 | 일반 접근에 모델별 조건 없음 | 30일 보존, ZDR 없음 | 품질 테스트 전에 거버넌스가 제외할 수 있음 |
더 최신인 cutoff는 저장소 사실, retrieval, 외부 검증을 대신하지 않습니다. 같은 1M context도 긴 trace 안의 제약을 찾아 적용하는 신뢰성까지 같다는 뜻은 아닙니다.
Opus 5를 기본으로 둘 작업
저장소 규모 구현·디버깅·리뷰, 도구와 subagent가 포함된 장시간 agent, 브라우저 자동화, 금융·법률·과학 분석, 지연도 중요한 long context, 모든 요청에 Fable 비용을 지불할 수 없는 프리미엄 트래픽은 Opus 5부터 시작합니다.
low부터 max까지 effort를 이용해 여러 프리미엄 lane을 만들 수 있습니다. high에서 시작해 승인율이 유지되는 곳만 낮추고 xhigh/max는 최난도 작업에 남기세요. 실패한 low + retry는 한 번에 성공한 high보다 비쌀 수 있습니다.Fable 5가 여전히 프리미엄을 벌 수 있는 경우
수시간·수일 agent, 분해가 어려운 frontier research, 강한 Opus 시도 후에도 미해결인 계획, 독립 2차 frontier 검토가 사람의 리뷰를 줄이는 고가치 산출물, replay에서 Fable 승인율이 명확히 높은 작업군에는 Fable을 유지하세요.
단순히 “어렵다”는 조건으로는 부족합니다. 검증 실패, 낮은 확신, 수렴하지 않는 tool loop, 매우 높은 작업 가치, 측정된 과거 Fable 우위를 사용하세요.
코딩과 에이전트 작업을 나누는 방법
| 워크로드 | 권장 default | Fable을 시험할 때 | 주요 지표 |
|---|---|---|---|
| 저장소 규모 구현 | Opus 5 | Test 실패가 계속되거나 architecture 재설계가 필요 | Test 통과, 수정 횟수, 범위 밖 변경 |
| Bug 원인 분석 | Opus 5 | 가설이 반복해서 무너짐 | 첫 번째 올바른 root cause, 회귀 |
| Code review | Opus 5 | 고위험 merge에 독립 리뷰가 필요 | True/false positive, 사람 리뷰 시간 |
| Multi-agent 계획 | Opus 5 | 긴 trace가 반복적으로 이탈 | Replan, subtask 충돌, 상태 손실 |
| Subtask 실행 | Opus 또는 저비용 route | 검증 가능한 실패 뒤에만 | 승인 subtask 비용, retry율 |
| Browser / computer use | Opus 5 | 핵심 단계가 복구되지 않음 | 완료율, 복구율, 작업 수 |
| 장문 research | Opus 5 | 고가치 결과에 독립 반론이 필요 | Citation 정확성, 누락, 검증 시간 |
초기 커뮤니티 의견에는 계획·어려운 조사·최종 리뷰를 Fable이 맡고 구현과 tool 실행을 Opus가 맡는 구성이 있습니다. 이는 검증할 가설이지 확립된 보편 동작이 아닙니다.
2배 가격표보다 승인 작업당 비용
| 모델 | Input | Output | 5분 Cache Write | Cache Read |
|---|---|---|---|---|
| Claude Opus 5 | $5 / MTok | $25 / MTok | $6.25 / MTok | $0.50 / MTok |
| Claude Fable 5 | $10 / MTok | $50 / MTok | $12.50 / MTok | $1 / MTok |
승인 작업당 비용 =
input + cache write + cache read + output
+ retry + fallback + 사람 리뷰
/ 승인된 결과C, Fable 한 번을 2C라고 둡니다.승인 작업당 모델 비용 = 시도 비용 ÷ 첫 시도 승인율
모델 비용만으로 Fable이 이기는 조건:
Fable 승인율 ÷ Opus 승인율 > Fable 비용 ÷ Opus 비용
따라서: Fable 승인율 > 2 × Opus 승인율| 시나리오 | Opus 승인율 | Fable 승인율 | Opus 승인 결과 비용 | Fable 승인 결과 비용 | 결과 |
|---|---|---|---|---|---|
| 대량 구현 | 80% | 90% | 1.25C | 2.22C | Fable이 약 78% 높음 |
| 어려운 debugging | 60% | 90% | 1.67C | 2.22C | Fable이 약 33% 높음 |
| Opus가 불안정한 좁은 군 | 45% | 95% | 2.22C | 2.11C | Fable이 조금 더 저렴할 수 있음 |
실제 thinking, output, tool call 양은 다를 수 있습니다. 그래도 Opus 승인율이 50%를 넘으면 Fable의 작은 향상만으로 2배 단가를 회수하기 어렵습니다. Retry, 사람 시간, 실패 손실을 크게 줄이는 작업군이라면 Fable이 총비용에서 이길 수 있습니다.
EvoLink 경로 가격은 Anthropic 정가와 다를 수 있으므로 배포 예산에는 모델 페이지의 실시간 가격을 사용하세요.
Safeguards, 데이터 보존, fallback
Anthropic은 Fable 5에 추가 classifier와 거부 동작, 30일 보존, Zero Data Retention 미지원을 문서화합니다. Opus 5는 classifier 개입이 약 85% 적을 것으로 예상하며 일반 접근 보존 요건이 없다고 설명합니다.
이는 채널별 사실입니다. 계약, 리전, 실제 경로를 확인하고 자동 fallback에서는 requested model과 returned model을 따로 기록하세요.
| 필드 | 필요한 이유 |
|---|---|
| Requested model | 사용자 또는 router의 최초 선택을 보존 |
| Served model | 실제 결과를 생성한 모델 식별 |
| Effort와 output budget | 두 호출의 비교 가능성 확인 |
| Refusal과 classifier | 정책 거부와 품질 실패 구분 |
| Fallback 이유와 chain | 경로가 바뀐 지점과 이유 설명 |
| 단계별 tokens와 latency | 전체 경로 비용 계산 |
| 최종 승인 결과 | “출력이 있음”을 성공으로 세지 않음 |
데이터 거버넌스는 품질 비교보다 먼저 Fable을 제외할 수 있습니다. Provider 조건을 실제 gateway, region, 계약에 맞춰 확인하세요.
권장 운영 라우팅
| 워크로드 | Default | Escalation | Fallback |
|---|---|---|---|
| 정형 추출 | Sonnet 또는 검증된 저비용 route | 검증 실패 후 Opus | 기존 fast route |
| 어려운 코딩 | 측정된 effort의 Opus 5 | 실패/낮은 확신에서 Fable | Opus 4.8 등 |
| 장시간 agent | Opus 5 | frontier trace를 Fable로 | checkpoint 재개 |
| 고가치 분석 | Opus + 근거 검증 | Fable 독립 2차 평가 | 사람 리뷰 |
| 정책 민감 작업 | 승인된 route | 승인된 경우만 | 명시적 거부 처리 |
EvoLink에서는 모델 선택을 라우팅 계층에 두세요. 하나의 client와 API key로 default, escalation, fallback, rollback을 관리할 수 있습니다.
Opus만 사용
자동 test, 구조화 validation, 안정된 사람 rubric이 Opus의 승인 기준 통과를 보여 줄 때 적합합니다. 다른 premium model을 추가하기 전에 effort부터 조정하세요.
Opus 기본, 검증 실패 후 Fable
Failed test, invalid tool, 반복 loop, 명시적 낮은 확신, 또는 Fable 우위가 이미 측정된 작업군을 trigger로 삼습니다. 작업당 Fable 호출 수를 제한하고 사람 확인 경계를 유지하세요.
Fable로 계획·리뷰, Opus로 실행
Fable에는 짧은 계획, architecture 결정, 독립 review만 요청하고 필요한 context만 Opus에 전달합니다. 추가 latency와 중복 tokens보다 재작업 감소가 큰지 측정하세요.
두 개의 독립 결과
불일치 자체가 유용한 영역에만 사용합니다. Review에서는 모델 이름을 숨기고 중재 rubric을 먼저 정의하세요. 두 모델의 동의를 정답의 증거로 간주하면 안 됩니다.
EvoLink에서 Claude Opus 5 평가하기공정한 평가와 롤아웃
- 성공, 비싼 실패, frontier 사례를 포함한 50~200개 작업을 준비합니다.
- tools, 권한, repo, context, timeout, retry를 동일하게 둡니다.
- model ID, effort, 출력 예산, latency, tokens, tool 유효성, 거부, fallback, 리뷰 시간을 기록합니다.
- 정확성, 범위, 완료도, 수정량을 blind 평가합니다.
- 작업군별 승인 작업당 비용을 계산합니다.
- 기준을 통과한 군에만 Opus를 default로 둡니다.
- 증가 가치가 premium을 넘는 군만 Fable로 올립니다.
- 실제 트래픽 검증 전에는 기존 route를 유지합니다.
최소한 다음 필드를 기록하세요.
task_id, task_class
requested_model, served_model, effort
input / cache-write / cache-read / output tokens
latency, tool calls, invalid tool calls
refusal, fallback chain
automatic checks, blind human score
repair minutes, accepted전체 평균만 제시하지 말고 워크로드군별로 결과를 공개하세요. 전체에서 진 모델도 좁은 production lane에서는 가치가 있을 수 있습니다.
Fable 트래픽을 Opus로 안전하게 옮기는 방법
| 단계 | 할 일 | 다음 단계 기준 |
|---|---|---|
| 1. Historical replay | 성공, 비싼 실패, 긴 trace, frontier를 50~200개 준비 | 실제 tools, context, 권한, 승인 기준 포함 |
| 2. Matched test | Tools, timeout, retry, effort, output budget 동일하게 유지 | 작업군별 비교가 가능 |
| 3. Shadow | Fable 운영과 함께 Opus를 user path 밖에서 실행 | Safety, format, tool blocker 없음 |
| 4. Canary | 적합한 작업군의 10%~25%를 Opus로 이동 | 승인율, review, p95가 한도 내 |
| 5. Workload 확대 | 통과한 작업군만 확대 | 승인 작업당 비용이 기존 route보다 나음 |
| 6. Escalation / rollback | Fable 우위가 입증된 군 유지 | 모든 작업군이 이전 policy로 복귀 가능 |
Replay 전에 기준을 정하세요. 첫 시도 승인율이 크게 떨어지지 않아야 하고 invalid tool이 늘면 안 됩니다. Retry와 수정 시간이 token 절감을 없애지 않아야 하며 p95, refusal/fallback 귀속, 고가치 실패의 별도 검토도 기준에 포함해야 합니다.
첫 성공 batch 뒤에 Fable route를 지우지 마세요. 목표는 단방향 이전이 아니라 versioned reversible policy입니다.
팀별 시작안과 남은 불확실성
| 팀 | 시작 정책 | 이유 |
|---|---|---|
| 소규모 제품 팀 | Opus만, Fable 수동 escalation | 운영을 단순하게 유지하며 비상 경로 보존 |
| Coding-agent platform | Opus default, 작업군별 Fable | Routing과 observability가 핵심 기능 |
| 기업 knowledge workflow | Opus, 선택적 Fable 2차 review | 사람 시간과 거버넌스가 benchmark 순위보다 중요 |
| 고위험 research | 일부에만 독립 이중 review | 불일치와 감사 가능성이 추가 비용을 정당화 |
| 대량 automation | Fable 전에 Opus 또는 저비용 route | 자동 validation으로 retry가 저렴 |
출시 직후에는 같은 effort로 비교한 독립 근거가 제한적입니다. 초기 경험담은 prompt, harness, subscription surface가 다르고 provider availability와 latency도 바뀔 수 있습니다. 대응 평가가 나오거나 보존 규정, 자체 workload 구성이 바뀌면 정책을 다시 검토하세요.
몇 개 graph로 보편적 승자를 정하거나, retry와 review를 비용에서 빼거나, 한 모델에 더 많은 tool을 주거나, fallback 응답을 Fable 성과로 세는 평가를 피해야 합니다.
최종 권장
저비용 route -> Opus 5 default -> Fable 5 escalation
\-> 검증된 fallback과 rollback출처
- Anthropic: Introducing Claude Opus 5
- Anthropic: What's new in Claude Opus 5
- Anthropic: Models overview
- Anthropic: Introducing Claude Fable 5 and Claude Mythos 5
- Anthropic: Claude API pricing
- ARC Prize: Claude Opus 5 verified results
- RuBench: fallback attribution analysis
- Claude Code discussion: Opus 5 vs Fable first impressions
FAQ
Claude Opus 5가 Claude Fable 5보다 좋은가요?
항상 그렇지는 않습니다. Opus는 여러 평가에서 앞서거나 근접하고 절반 가격이지만, Fable은 최고 능력 모델로 남습니다.
Fable 5는 2배 가격의 가치가 있나요?
추가 승인 결과, retry 감소, 사람 리뷰 절감이 2배 토큰 가격을 상쇄할 때만 그렇습니다.
코딩 에이전트에는 어떤 모델이 좋나요?
Opus 5부터 시작하고 검증에 실패한 frontier 사례나 Fable 우위가 측정된 군만 올리세요.
Opus 5가 benchmark에서 Fable을 이겼나요?
Anthropic은 일부 승리와 일부 근접 결과를 발표했습니다. ARC Prize는 Opus ARC-AGI-3를 검증했지만 대응 Fable 점수는 없습니다.
둘 다 1M context를 지원하나요?
네. 최대 동기 출력도 128K입니다. 그래도 실제 long trace를 별도로 replay해야 합니다.
어떤 모델이 더 빠른가요?
Anthropic은 Opus를 moderate, Fable을 slower로 표시합니다. effort, 출력, tools, route에 따라 달라집니다.
하나의 EvoLink 통합으로 둘 다 사용할 수 있나요?
네. model ID를 routing policy에 두고 같은 통합에서 default, escalation, fallback을 관리할 수 있습니다.
Default를 바꾸기 전에 무엇을 측정해야 하나요?
첫 시도 승인율, tool 유효성, retry, 거부, fallback, 출력 tokens, 소요 시간, 사람 수정, 승인 작업당 비용입니다.
Fable이 계획하고 Opus가 실행할 수 있나요?
네. 계획은 짧게 만들고 필요한 context만 넘긴 뒤, 추가 latency와 tokens를 포함한 총 승인 작업당 비용으로 판단하세요.
Fable 요청이 fallback되지 않았는지 어떻게 확인하나요?
Requested model, served model, 거부 category, fallback chain을 기록하세요. HTTP 200만으로 Fable이 응답했다고 증명할 수 없습니다.
