AIREITER어떤 모델이 기본값이 될지는 결국 워크로드에 달려 있습니다. 범위가 분명하고 출력량이 많은 작업이라면 Claude Opus 5가 더 안전한 출발점이고, 장시간 실행되는 에이전트나 크고 반복적으로 재사용되는 컨텍스트라면 Claude Fable 5.1을 시험해볼 가치가 있습니다. 다만 Fable 5.1의 눈에 띄는 비용 절감은 입력·출력 단가가 낮아서가 아니라 캐시 읽기 비용이 저렴하기 때문에 가능합니다.
Fable 5.1과 Opus 5 중 무엇을 고를지는 워크로드부터 봐야 한다
대부분의 팀이라면 Opus 5로 시작하고, 더 깊은 추론이 필요한 작업에는 effort를 높인 뒤, 그래도 요구사항을 충족하지 못하는 어려운 작업만 Fable 5.1로 보내는 방식이 현실적입니다. Anthropic의 Fable 5.1 문서도 비슷한 방향을 제시합니다. 대부분의 워크로드에는 Opus 5부터 사용하고, 높은 effort로 설정한 Opus 평가에서도 요구 수준에 미치지 못할 때 Fable 5.1로 전환하라는 안내입니다.
| 주요 제약이… | 먼저 사용할 모델 | 이유 |
|---|---|---|
| 짧거나 범위가 제한된 요청 | Opus 5 | 입력·출력 단가가 Fable 5.1의 절반입니다. |
| 출력량이 많은 프로덕션 트래픽 | Opus 5 | Fable의 낮은 캐시 읽기 단가는 생성 토큰 비용까지 낮춰주지 않습니다. |
| 사양이 명확한 멀티파일 코딩 | Opus 5 | 비용이 낮아 반복 재시도와 높은 effort 설정을 감당하기 쉽습니다. |
| 장시간 실행되며 도구를 사용하는 에이전트 | Fable 5.1—평가 후 | Anthropic이 공개한 에이전트·도구 사용 비교에서 Fable이 앞섭니다. |
| 여러 턴에 걸쳐 대규모 컨텍스트를 반복 재사용하는 작업 | Fable 5.1—비용 모델링 후 | 캐시 읽기 가격이 Opus 5의 절반입니다. |
| 폴백이 중요한 프로덕션 라우터 | Opus 5 우선 | Fable 5.1은 thinking block과 대화 기록 처리 방식이 달라집니다. |
핵심은 적절한 effort와 비용으로 사용하는 Opus 5와, 적합한 컨텍스트 구조와 신뢰성 기준에서 사용하는 Fable 5.1을 비교하는 것입니다.
Fable 5.1과 Opus 5는 실제로 무엇이 다른가
Claude Fable 5.1은 까다로운 추론과 장시간 실행되는 에이전트 작업을 겨냥한 Anthropic의 상위 모델입니다. Claude Opus 5는 진지한 코딩과 에이전트, 전문적인 업무를 더 낮은 비용으로 처리하는 모델로 포지셔닝되어 있습니다. 두 모델 모두 컨텍스트 윈도우는 100만 토큰, 최대 출력은 128,000토큰으로 동일합니다. 따라서 Fable 5.1의 차별점은 공개된 컨텍스트 한도가 더 크다는 데 있지 않고, 장시간 이어지는 실행 흐름에 있습니다.
| 사양 | Claude Fable 5.1 | Claude Opus 5 |
|---|---|---|
| API 모델 ID | claude-fable-5-1 | claude-opus-5 |
| 컨텍스트 윈도우 | 100만 토큰 | 100만 토큰 |
| 최대 출력 | 128,000토큰 | 128,000토큰 |
| 입력 모달리티 | 텍스트 및 이미지 | 텍스트 및 이미지 |
| 출력 모달리티 | 텍스트 | 텍스트 |
| Thinking | 적응형, 항상 활성화 | Effort로 제어하는 추론 |
| Effort 설정 | low, medium, high, xhigh, max | 설정 가능한 effort 단계 |
| Anthropic의 포지셔닝 | 까다로운 추론과 장시간 실행되는 에이전트 | 대부분의 워크로드와 진지한 코딩 |
| 출시 상태 | 활성/latest; 2026년 9월 1일 출시 | 활성 Opus 모델; 2026년 7월 24일 출시 |
배포 환경별 모델 ID와 사용 가능 여부는 Fable 5.1 모델 페이지와 Claude Opus 5 제품 페이지에서 확인하는 것이 좋습니다.
Fable 5.1의 벤치마크 성적은 강력하지만 모든 작업에 그대로 적용되지는 않는다
Anthropic이 공개한 벤치마크 표에서는 두 모델의 결과가 모두 공개된 모든 항목에서 Fable 5.1이 Opus 5를 앞섭니다. 다만 해당 결과는 벤더가 직접 수행한 평가입니다. 따라서 출시 시점의 평가 결과를 보여주는 유용한 근거로 볼 수는 있지만, 프로덕션 성능을 보장하는 자료는 아닙니다.
| Anthropic 평가 | Fable 5.1 | Opus 5 | Fable 5.1의 우위 |
|---|---|---|---|
| Terminal-Bench-Science 0.1 | 52.6% | 29.0% | 23.6포인트 |
| Terminal-Bench 4.0 | 55.8% | 52.3% | 3.5포인트 |
| GDPval-AA v2 | 1,853 Elo | 1,824 Elo | 29 Elo |
| OSWorld 2.0, strict | 41.7% | 39.6% | 2.1포인트 |
| Humanity’s Last Exam, with tools | 65.0% | 63.6% | 1.4포인트 |
| AutomationBench | 31.4% | 26.9% | 4.5포인트 |
| CursorBench 3.2.0 | 73.4% | 70.0% | 3.4포인트 |
Anthropic은 프로덕션 안전장치를 활성화했으며, 일부 개입으로 인해 점수가 0점 처리되거나 작업이 폴백 모델로 전달될 수 있었다고 설명합니다. 또한 Terminal-Bench-Science 0.1에서 모델별 표준 오차가 약 3.5~4.5%포인트라고 밝혔습니다. 따라서 23.6포인트 차이는 Humanity’s Last Exam에서의 1.4포인트 차이보다 더 의미 있게 해석할 수 있습니다.
제3자 평가인 CodeRabbit의 평가에서는 105개의 알려진 이슈 포인트가 포함된 45개 작업을 대상으로 Fable 5.1의 재현율이 61.0%, 정밀도가 37.3%로 나타났습니다. Opus 5는 재현율 55.2%, 정밀도 39.3%였습니다. 두 모델 모두 처리된 댓글 수는 166개였지만, 평가를 진행한 측은 두 모델의 설정이 달랐다고 경고했습니다.
“Fable 5.1은 전문 리뷰어에 가깝다.” — 평가 결과에 대한 CodeRabbit의 설명 (CodeRabbit)
API 가격을 보면 실사용 기준의 비교가 달라진다
캐시되지 않은 입력과 출력은 Fable 5.1이 Opus 5보다 두 배 비싸지만, 캐시 읽기 비용은 절반입니다. 이 구조는 길고 반복적인 에이전트 세션에서 손익분기점을 만들 수 있지만, 모든 Fable 5.1 요청이 더 저렴해진다는 뜻은 아닙니다.
다음 요금은 Anthropic의 최신 API 가격 문서에 따른 것으로, 토큰 100만 개당 미국 달러 기준입니다.
| 과금 항목 | Claude Fable 5.1 | Claude Opus 5 |
|---|---|---|
| 기본 입력 | $10.00 | $5.00 |
| 5분 캐시 쓰기 | $12.50 | $6.25 |
| 1시간 캐시 쓰기 | $20.00 | $10.00 |
| 캐시 읽기 | $0.25 | $0.50 |
| 출력 | $50.00 | $25.00 |
| 배치 입력 / 출력 | $5.00 / $25.00 | $2.50 / $12.50 |
Fable 5.1의 입력·출력 가격은 Fable 5와 동일합니다. 광고에서 말하는 비용 절감의 핵심은 캐시 읽기 단가입니다. Fable 5.1은 토큰 100만 개당 $0.25로, Fable 5의 $1.00에서 낮아졌습니다. Anthropic은 일반적인 워크로드에서 약 25%, 에이전트 사용 비중이 높은 워크로드에서는 최대 약 45%의 비용 절감을 예상하지만, 이는 워크로드별 추정치이지 모든 요청에 적용되는 할인율은 아닙니다.
턴 단위로 계산해보면 차이가 더 분명해집니다. 캐시된 컨텍스트를 C, 새로 들어오는 입력을 I, 출력을 O라고 하며 각각 단위는 토큰 100만 개로 두겠습니다. 캐시 쓰기 비용을 제외하면 Fable 5.1의 비용은 10I + 0.25C + 50O, Opus 5의 비용은 5I + 0.50C + 25O입니다.
Fable의 저렴한 캐시 읽기 비용이 더 높은 새 입력·출력 단가를 상쇄하려면 다음 조건을 만족해야 합니다.
0.25C > 5I + 25O
새 프롬프트가 2,000토큰이고 응답이 1,000토큰이라면 I = 0.002, O = 0.001입니다. 읽기 비용만 놓고 Fable이 유리해지려면 캐시된 컨텍스트가 대략 140,000토큰을 넘어야 합니다. 캐시 쓰기 비용까지 포함하면 손익분기점은 더 멀어집니다.
따라서 짧은 정보 추출, 분류, 재작성, 일회성 코딩 요청을 가격만 보고 Fable 5.1로 올릴 이유는 크지 않습니다. 할인할 수 있는 재사용 프리픽스가 거의 없거나 아예 없고, 생성되는 토큰마다 Opus 5의 두 배 요금이 부과되기 때문입니다.
실제 워크플로에서는 모델별 역할을 어떻게 나눌까
실무에서의 구분 기준은 범위가 제한된 실행과 장시간 이어지는 작업 지속성입니다. 작업 사양이 명확하거나 출력량이 많다면 Opus 5를 선택하기 쉽습니다. 반대로 에이전트가 계획을 유지하고, 도구를 반복 사용하며, 실패에서 복구하고, 여러 턴에 걸쳐 대규모 컨텍스트를 이어가야 한다면 Fable 5.1이 더 흥미로운 후보가 됩니다.
코딩 에이전트는 벤치마크 순위보다 완료된 작업을 기준으로 보자
일반적인 저장소 작업이라면 Opus 5를 먼저 시험하는 편이 좋습니다. 범위가 정해진 버그 수정, 명확한 리팩터링, 코드 리뷰처럼 비용을 낮춰 재시도하거나 effort를 높이는 것이 중요한 작업에 특히 적합합니다. 반면 여러 파일을 동시에 수정하는 작업, 마이그레이션, 시스템 수준의 디버깅, 응답이 느려지더라도 마지막 단계의 실패 비용을 줄여야 하는 비동기 코딩 세션이라면 Fable 5.1을 파일럿으로 검토할 수 있습니다.
커뮤니티 반응을 보면 운영상 리스크도 서로 다르게 나타납니다. 대규모 r/ClaudeCode 토론에서 사용자 u/CyCoCyCo는 다음과 같이 적었습니다.
“제가 성공을 거둔 유일한 방법은 목표 프롬프트를 만들게 한 다음 처음부터 끝까지 실행하도록 하는 것이었습니다.” — Reddit의 u/CyCoCyCo
이는 프롬프트 작성과 워크플로에 대한 불만을 보여주는 사례이지, Opus 5가 모든 코드베이스에서 실패한다는 증거는 아닙니다. 같은 토론에 참여한 다른 사용자들은 컨텍스트가 길고 복잡한 작업에서 지시가 흐려지거나, 수정 과정에서 새로운 결함이 생기는 문제를 언급했습니다.
Fable 5.1에 대한 불만은 다른 양상입니다. 한 출시 관련 토론에서는 토큰이나 할당량이 유난히 빠르게 소진된다는 사용자 보고가 나왔습니다. 일화적인 경험에 해당하며 모든 구독 요금제에 공통으로 적용되는 한도를 입증하는 것은 아니지만, 파일럿 기간에는 결과 품질만 보지 말고 사용량도 함께 추적해야 하는 이유가 됩니다.
코딩 에이전트를 파일럿할 때는 다음 항목을 기록하는 것이 좋습니다.
- 사람의 개입 없이 완료된 작업 수
- 모델이 성공을 보고한 뒤 다시 발견된 버그나 회귀
- 전체 입력 토큰, 캐시 입력 토큰, 출력 토큰
- 총 소요 시간과 도구 호출 횟수
- 사람이 수정하는 데 걸린 시간과 마지막 단계에서 실패한 실행의 비용
리서치와 문서 중심 작업에서는 Fable의 근거가 더 분명하다
매우 많은 문서, 반복적인 도구 호출, 시각적 차트, 여러 단계의 리서치, 수차례 수정해도 견고해야 하는 결과물을 다루는 작업이라면 Fable 5.1이 더 유력한 후보입니다. Anthropic 역시 문서, 스프레드시트, 슬라이드, 다이어그램, 표, 장시간 실행되는 리서치 작업을 Fable 5.1의 주요 용도로 제시합니다.
Opus 5도 동일한 100만 토큰 컨텍스트 용량을 제공하며, Anthropic은 복잡한 문서와 정교한 에이전트를 처리할 수 있는 모델로 설명하고 있습니다. 작업이 상당한 분량의 결과물을 생성하는 단일 분석이라면 Fable의 캐시 이점보다 Opus의 낮은 단가가 더 중요할 수 있습니다. Fable의 벤치마크 우위를 프로덕션 요구사항으로 보기 전에 실제 작업을 대표하는 샘플로 먼저 평가해보는 편이 안전합니다.
컴퓨터 사용과 업무 자동화는 전체 실행 흐름으로 평가해야 한다
Anthropic의 OSWorld와 AutomationBench 항목에서는 Fable 5.1이 Opus 5보다 앞섭니다. 하지만 이런 작업은 단일 답변이 아니라 일련의 행동을 평가합니다. 브라우저 에이전트나 업무 프로세스 자동화 에이전트라면 모델이 올바른 최종 상태에 도달하는지, 복구가 얼마나 자주 필요한지, 한 번의 행동 실패가 이후 전체 실행을 무효화하는지를 확인해야 합니다.
이때 봐야 할 기준은 단순한 토큰 100만 개당 비용이 아니라 완료된 결과 하나를 얻는 데 드는 비용입니다. 긴 워크플로에서 반복 재시도를 줄여주는 모델은 단가가 높아도 경제적일 수 있습니다. 반대로 최종 상태에 도달하기 전에 사용량 예산을 소진하는 모델은 그렇지 않습니다.
전환 전에 반드시 확인해야 할 통합 세부사항
Fable 5.1의 마이그레이션 문서에는 강제 도구 사용, thinking block, 대화 기록 검증과 관련된 변경 사항이 설명되어 있습니다. 자체 메시지 라우터를 사용하는 팀이라면 기본 모델을 바꾸기 전에 이 부분을 반드시 시험해야 합니다.
| 변경 사항 | 발생할 수 있는 문제 | 마이그레이션 대응 |
|---|---|---|
| 강제 도구 사용 | tool_choice: {"type":"any"} 또는 특정 도구를 지정하는 선택이 HTTP 400을 반환할 수 있습니다. | 명확한 도구 지시와 함께 auto를 사용하거나, 적절한 경우 구조화된 출력을 사용합니다. |
| Thinking block 호환성 | 이전 모델은 Fable 5.1의 thinking block을 읽을 수 없으며, 폴백 턴에서 해당 블록이 삭제될 수 있습니다. | 모델 전환과 폴백 경로를 점검합니다. |
| 대화 수정 | 이전 메시지, 시스템 프롬프트, 도구 목록을 수정하면 이후 thinking block이 무효화될 수 있습니다. | 기록을 추가 전용으로 취급하거나 지원되는 턴 단위 제어 방식을 사용합니다. |
| Thinking 설정 | Fable 5.1은 적응형 thinking을 사용하며, Opus 5와 같은 방식으로 thinking을 비활성화할 수 없습니다. | Effort 설정으로 지출을 제어하고 토큰 사용량을 다시 테스트합니다. |
혼합 모델 라우터에서는 폴백 관련 세부사항이 특히 중요합니다. Fable 5.1 요청은 추론 컨텍스트를 유지하며 계속 진행할 수 있지만, Opus 5로 폴백하면 Fable 5.1의 thinking block을 읽을 수 없습니다. 라우터가 이를 조용히 삭제하면 폴백 모델이 계획을 다시 세우면서 지연 시간과 토큰 사용량이 늘어날 수 있습니다. 실제 서비스와 유사한 대화 기록으로 정상 경로와 실패 경로를 모두 테스트해야 합니다.
거창한 모델 주장보다 작은 평가 하나가 낫다
두 모델에 동일한 프롬프트, 도구, 컨텍스트, effort 정책, 수용 테스트를 적용해야 합니다. 그렇지 않으면 모델 비교가 아니라 테스트 하네스 비교가 될 수 있습니다.
- 범위 제한 작업: 범위가 정해진 버그 수정, 정보 추출, 구조화된 글쓰기, 코드 리뷰를 실행합니다. 유용한 결과물, 수정에 걸린 시간, 비용을 기록합니다.
- 장시간 실행 작업: 멀티파일 기능 구현, 마이그레이션, 리서치 작업, 브라우저 워크플로를 실행합니다. 최종 상태 도달 여부, 복구, 회귀, 총 소요 시간을 기록합니다.
- 캐시 중심 작업: 안정적인 시스템 프롬프트, 도구 세트, 저장소 또는 문서 프리픽스를 반복 사용합니다. 캐시 적중률과 캐시 쓰기·출력을 포함한 전체 청구액을 기록합니다.
Opus 5는 실제 배포할 effort 단계에서 시작해야 합니다. 그런 다음 Fable 5.1로 넘어가기 전에 Opus의 effort를 높인 경우도 테스트해보세요. Fable은 최소한 medium과 high를 시험하는 편이 좋습니다. 모델이 달라지면 같은 effort 이름이 같은 동작을 의미한다고 가정해서는 안 됩니다. Anthropic은 effort 설정이 추론 깊이와 비용 사이의 균형을 조절한다고 설명하며, 제3자 테스트에서는 추론 수준을 높였다고 해서 전체 코드 리뷰 결과가 자동으로 좋아지지는 않았습니다.
Fable 5.1과 Opus 5 FAQ
코딩에는 어느 모델이 더 나은가?
Anthropic이 공개한 Terminal-Bench와 CursorBench 결과에서는 Fable 5.1이 Opus 5를 앞섭니다. 하지만 대부분의 범위 제한형·비용 민감형 코딩 작업에서는 Opus 5부터 시작하는 편이 현실적입니다. Fable의 더 높은 완료 품질이 가격과 지연 시간을 상쇄하는지는 실제 저장소를 대표하는 평가로 판단해야 합니다.
Fable 5.1은 API 가격이 두 배여도 사용할 가치가 있는가?
기본적으로 그렇다고 보기는 어렵습니다. 입력·출력 단가는 Opus 5의 두 배인 반면 캐시 읽기는 절반 가격입니다. 따라서 대규모 컨텍스트를 반복적으로 재사용하고 출력량은 상대적으로 적은 워크로드에서 Fable의 비용 효율성이 나타날 수 있습니다.
Fable 5.1의 컨텍스트 윈도우가 더 큰가?
아닙니다. Anthropic은 두 모델 모두 컨텍스트 윈도우 100만 토큰, 최대 출력 128,000토큰으로 안내합니다. Fable의 차이는 공개된 윈도우 크기가 아니라 장시간 이어지는 추론과 에이전트 실행에 초점을 맞춘 포지셔닝입니다.
전환하기 전에 Opus 5의 effort를 높여야 하는가?
그렇게 하는 편이 좋습니다. Anthropic의 모델 가이드도 Fable 5.1로 이동하기 전에 더 높은 effort의 Opus 5를 평가하라고 권장합니다. 모든 요청을 최고 effort로 실행하기보다는, 추가 토큰 비용과 품질 향상을 비교해야 합니다.
Fable 5.1에서 Opus 5로 안전하게 폴백할 수 있는가?
폴백 자체는 구현할 수 있지만 대화 상태가 그대로 호환된다고 가정해서는 안 됩니다. 이전 모델은 Fable 5.1의 thinking block을 읽을 수 없고, Fable 5.1의 기록 검증 방식은 이전 턴을 수정하는 라우터에서 문제를 드러낼 수 있습니다. 실제 도구 스키마와 메시지 기록을 사용해 폴백을 테스트해야 합니다.
개발자는 어디에서 Fable 5.1과 Opus 5를 사용할 수 있는가?
Anthropic은 두 모델 모두 Claude 요금제와 자체 플랫폼, 클라우드 마켓플레이스 통합을 통한 개발자 액세스에서 제공한다고 안내합니다. 정확한 모델 ID와 사용 가능 여부는 제공업체에 따라 달라질 수 있으므로, Fable 5.1 문서나 Opus 5 제품 페이지에서 배포 환경별 식별자를 확인해야 합니다.
실무에서의 선택은 영구적인 업그레이드가 아니라 라우팅 규칙에 가깝다
| 판단 기준 | Opus 5 사용 | Fable 5.1 사용 |
|---|---|---|
| 혼합 트래픽의 기본 모델 | 예 | 평가 후에만 |
| 짧은 일회성 요청 | 예 | 가격상 이점 없음 |
| 출력량이 많은 생성 작업 | 예 | 대체로 아님 |
| 대규모 캐시 프리픽스 | 신중하게 비교 | 비용상 이점 가능 |
| 장시간 자율 코딩 | 먼저 파일럿 | 유력한 후보 |
| 범위가 엄격히 제한된 리팩터링 | 대체로 적합 | Opus가 수용 테스트를 통과하지 못할 때 |
| 브라우저 또는 다단계 자동화 | 먼저 파일럿 | 벤치마크상 유력 |
| 커스텀 폴백 라우터 | 더 단순한 기준 모델 | 마이그레이션 테스트 필요 |
Opus 5를 기준선으로 유지하고, 동일한 범위 제한형·장시간 실행 작업 세트에서 두 모델을 모두 테스트하세요. 그 결과 1달러당 완료된 작업량이 개선될 때만 Fable 5.1로 라우팅하는 방식이 적절합니다.
모델별 비용 세부사항은 Claude Fable 5.1 API 가격에서, 전체 모델 정보는 Claude Opus 5에서 확인할 수 있습니다.