Claude Fable 5.2 vs Opus 5.5: 코딩과 에이전트 작업 비교

이 네 가지 작은 코딩·도구 작업에서는 Fable 5.2의 비싼 값을 치를 이유가 없었습니다. Claude Fable 5.2와 Claude Opus 5.5 모두 29개 코드 검사를 전부 통과했고, 표준 요금 기준 추정 비용은 네 가지 합계로 Opus가 $0.031, Fable이 $0.146이었습니다. 더 어려운 추론이나 긴 에이전트 실행은 Opus를 더 높은 effort로 써 보고 부족할 때 Fable을 검토하십시오.

Fable 5.2와 Opus 5.5 한눈에 보기

Fable 5.2가 더 최신이지만 컨텍스트는 둘 다 1M 토큰이고 최대 출력은 128K 토큰으로 같습니다. 이번 테스트에서 실무적인 차이는 코드의 정확성이 아니라 토큰 사용량에서 나왔습니다.

Anthropic의 Fable 5.2 모델 페이지와 Opus 5.5 모델 페이지는 두 모델을 모두 사용 가능으로 표시하며, 텍스트와 이미지 입력을 지원합니다. Fable은 2026년 11월 9일, Opus는 2026년 9월 22일에 공개되었습니다. 기본 effort가 다르므로 비교할 때는 둘 다 medium으로 맞추십시오.

Anthropic의 모델 개요는 대부분의 작업에 Opus 5.5를 권합니다. Fable 5.2는 요구가 높은 추론과 긴 시간 이어지는 에이전트 작업, 또는 더 높은 effort의 Opus 5.5 평가로도 부족한 경우에 맞는 모델로 위치시킵니다. 이는 벤더의 설명이고, 이번 테스트가 다룬 것은 작은 작업 네 가지입니다.

Fable 5.2의 변경 사항은 Fable 5.2 변경점에, 단일 모델 리뷰는 Opus 5.5 리뷰에 정리했습니다.

네 가지 작업에 드는 비용

Anthropic의 공식 요금 페이지는 Fable 5.2를 100만 토큰당 입력 $8, 출력 $40으로, Opus 5.5를 $4와 $20으로 적고 있습니다(2026년 11월 12일 확인). Batch는 둘 다 절반이 되고 fast 모드는 둘 다 두 배가 됩니다.

채점한 네 가지 작업에서 Fable은 입력 3,439 토큰, 출력 2,954 토큰을 썼습니다. Opus는 2,421과 1,065를 썼습니다. 표준 요금으로 계산하면 다음과 같습니다.

• Fable: (3,439 × $8 + 2,954 × $40) ÷ 1,000,000 = $0.1457
• Opus: (2,421 × $4 + 1,065 × $20) ÷ 1,000,000 = $0.0310

이 값은 관측한 토큰으로 계산한 표준 요금 추정치이며, 청구서 금액도 OmniaKey 청구 금액도 아닙니다. Opus의 응답은 fast 속도를, Fable은 standard를 보고했습니다. Anthropic은 fast의 입력과 출력을 표준 요금의 두 배로 둡니다. 여기서는 둘 다 표준 요금으로 맞추었으므로, 이 숫자는 통제된 시간 비교나 청구 비교가 아닙니다.

표준 요금 기준 추정치(미국 달러):

네 가지 작업의 평균은 Fable이 $0.0364, Opus가 $0.0077이었고, Fable의 표준 요금 추정치는 합계로 $0.1147 더 높았습니다. 실제 판단 기준은 쓸 만한 작업 한 건당 비용, 즉 API 비용에 재시도와 검토 시간을 더한 값입니다. 실제 작업에서 실패가 많아 그 추가 비용이 정당해질 때만 위로 옮기십시오. 이번의 작은 작업 네 가지는 거기까지 가지 않습니다.

실제 소요 시간 합계는 Fable이 27.8초, Opus가 43.6초였습니다. Fable의 응답은 standard 속도를, Opus는 fast를 보고했고 speed는 어느 쪽도 지정하지 않았습니다. 이 값은 관찰 기록으로 읽고 속도 순위로 쓰지 마십시오.

Python 수정 두 가지: 둘 다 22/22 항목

두 수정 모두 짧고, 두 모델 모두 동작하는 함수를 돌려줬습니다. 이 실패 사례는 라이브러리 지식이 아니라 revision 처리와 페이지네이션의 끝 조건을 시험하므로 남겨 둘 만합니다.

사용량 합계: 새 실패가 옛 성공을 지워야 한다

옛 함수는 complete 이벤트를 모두 더했습니다. revision과 status를 보지 않아서, 재시도가 토큰을 두 번 세고 새 failed revision이 옛 complete를 지우지 못했습니다.

프롬프트의 핵심 규칙:

Keep only the highest revision for each event_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing.

가장 작은 재현은 이벤트 x의 revision 1이 complete이고 10토큰, 그 뒤에 같은 x의 revision 2가 failed이고 10토큰인 경우입니다. 맞는 합계는 0이고 옛 함수는 10을 돌려줍니다.

두 모델 모두 가장 높은 revision을 남기고, 같은 revision이면 입력에서 마지막 것을 골랐으며, failed로 이긴 항목을 건너뛰고, 토큰이 0인 사용자를 남기고, 입력을 바꾸지 않았습니다. 결과: 각 8/8 항목, 함수는 동등했습니다.

커서 페이지네이션: 같은 타임스탬프도 반복도 누락도 없이

옛 버전은 ts로만 정렬하고, cursor를 적용하기 전에 첫 페이지를 잘라 냈으며, 같은 타임스탬프를 <=로 받아들이고, limit을 검증하지 않고, 늘 next cursor를 돌려줬습니다. ts=4인 행이 둘이면 ID가 반복되거나 빠집니다.

프롬프트의 핵심 규칙:

Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid.

두 모델 모두 전부 고쳤습니다. (ts,id) 튜플로 정렬하고, cursor보다 엄격히 작은 행만 고르고, 자르기 전에 전체 목록을 거르고, 행이 남을 때만 next cursor를 돌려주고, True, False, 0, 101, 1.5, '2', None을 거부하는 검증을 넣었습니다. 결과: 각 14/14 항목이며, 타임스탬프가 겹친 행을 한 줄씩 훑는 확인도 포함합니다.

비동기 원장: 숫자는 같고 JSON 모양은 다르다

두 모델 모두 대사를 맞췄습니다. 순 예약액 $0.93, t3는 대기, t1과 t5는 완료, t3의 다음 단계는 poll_existing이었습니다.

문제에 붙인 합성 로그의 금액은 예시일 뿐 OmniaKey 가격이 아닙니다. 핵심 줄은 다음과 같습니다.

POST key=a => 201 task=t1 quote=0.40

POST key=a, identical body => 200 task=t1

GET t1 => SUCCEEDED

POST key=b => 201 task=t2 quote=0.40

GET t2 => FAILED

POST key=c => 201 task=t3 quote=0.13

Client stopped polling t3 after 120 seconds; last status PROCESSING

POST key=d => 201 task=t4 quote=0.13

GET t4 => CANCELED

POST key=e => 201 task=t5 quote=0.40

GET t5 => SUCCEEDED

계산은 0.40 + 0.13 + 0.40 = 0.93입니다. t2와 t4는 환불되고, t1과 t5는 소비되며, t3는 예약이 남습니다. 작업이 실패해서가 아니라 클라이언트가 폴링을 멈췄기 때문입니다.

마지막으로 관측한 상태가 SUCCEEDED인 작업만 세면 두 모델이 같은 값을 돌려줬습니다. Fable은 생 JSON을 돌려줬습니다. Opus는 JSON을 JSON 코드 펜스로 감쌌습니다. 프롬프트는 "Return ONLY JSON"이었으므로 Opus의 답변에 그대로 엄격한 json.loads를 적용하면 펜스를 벗겨 내기 전까지 실패합니다. 이는 형식만 어긋난 경우이고, 요청은 JSON schema도 구조화 출력 모드도 없는 순수 JSON 텍스트였습니다. 결과: 값은 둘 다 통과합니다. 자동화에 쓰려면 생 답변을 엄격한 파서로 검증하거나 구조화 출력으로 바꾸십시오. 관측된 어긋남은 한 건이며 일반적인 경향이 아닙니다.

두 턴 파일 작업: 읽기 한 번, 패치 한 번

fixture의 옛 remaining_quota는 모든 이벤트의 units를 뺐습니다. 각 id의 마지막 상태도 max(0, ...) 하한도 보지 않아서, failed나 canceled 작업도 할당량을 먹고, 같은 이벤트가 반복되면 두 번 차감됩니다.

작업은 다음과 같습니다.

Use read_file once to inspect quota.py, then return one Python code block containing only a corrected remaining_quota(limit, events) function.

두 모델 모두 quota.py에 read_file을 정확히 한 번만 호출했습니다. fixture가 돌아온 뒤 두 모델은 같은 패치 로직을 냈습니다. 각 id의 마지막 이벤트를 남기고, reserved나 succeeded일 때만 units를 더하고, max(0, limit - consumed)를 돌려줍니다. 결과: 각 7/7 항목이며, failed 뒤 reserved가 되는 경우와 상한을 넘는 경우도 포함합니다.

이것은 두 턴과 fixture 하나입니다. 모델이 맞는 파일을 요청해 고친다는 것은 보여 주지만, 긴 에이전트 실행을 다루지는 않습니다.

테스트 방법

2026년 11월 12일, 네 가지 작업을 claude-fable-5-2와 claude-opus-5-5에 보냈습니다. 경로는 OmniaKey의 Messages 엔드포인트입니다. 모델과 작업의 조합마다 새 대화와 콜드 캐시를 썼고, effort는 medium, max_tokens는 요청마다 4096, 시스템 프롬프트 없음, temperature와 top_p 미지정, 시도는 한 번이었습니다. 어느 모델을 먼저 보낼지는 작업마다 번갈아 정했습니다.

에이전트 작업에는 엄격한 read_file 도구 하나만 주고 tool_choice는 auto로 두었습니다. 나머지는 사용자 메시지 하나였습니다. 채점 스크립트는 각 Python 답변을 AST로 검사한 뒤 독립 프로세스에서 3초 제한 시간을 두고 실행했습니다. 사용량 8건, 커서 14건, 에이전트 7건으로 모델당 29개 코드 케이스입니다. 모든 요청은 한 번만 실행했습니다.

첫 원장 프롬프트는 FAILED/CANCELED 작업을 completed_task_ids에 넣을지 정하지 않았습니다. 모호했던 그 회차는 모델마다 명확히 한 프롬프트로 한 번씩 다시 실행했고, 마지막으로 관측한 상태가 SUCCEEDED인 작업만 셉니다. 원래 출력은 채점한 네 가지 합계에서 뺐습니다.

요청 12건은 모두 HTTP 200을 돌려줬고 요청한 모델 ID와 일치했으며, end_turn 또는 tool_use 뒤 end_turn으로 끝나 잘린 곳이 없었습니다. 둘 다 service tier는 standard였습니다. Fable은 speed를 standard로 보고하고 thinking 토큰 수를 따로 줬습니다. Opus는 speed를 fast로 보고하고 thinking 토큰 필드가 없었습니다. speed는 우리 쪽에서 지정하지 않았습니다. 출력 토큰에는 과금되는 thinking이 이미 포함되므로, Opus에 그 필드가 없다고 해서 thinking이 0이라는 뜻은 아닙니다.

같은 effort 문자열은 설정일 뿐 맞춰진 연산 예산이 아닙니다. 이번 실행은 effort를 medium으로 고정했습니다. 직접 하는 작업에서는 필요한 effort 수준을 모두 훑어 보십시오. 이것은 작은 fixture 테스트이고, 저장소 전체나 장시간 에이전트 벤치마크가 아닙니다. 다른 작업의 통과율을 예측하지도 않습니다. OmniaKey는 두 모델의 접근을 제공하며, 위 가격은 Anthropic의 공식 정가입니다.

Fable을 검토할 때

짧고 요구가 분명한 작업은 Opus 5.5로 시작하십시오. 29개 코드 검사는 Fable과 모두 같았고, Fable의 표준 요금 추정치는 Opus의 4.7배였습니다.

요구가 높은 추론이나 긴 도구 루프는 높은 effort의 Opus가 직접 맡긴 실제 작업에서 실패한 뒤에 Fable 5.2를 다음 후보로 두십시오. 이것은 Anthropic의 설명이고, 이번 실행이 다룬 것은 작은 작업 네 가지뿐입니다. 바꾸기 전에 실제로 실패한 작업 10~20건으로 시험하십시오.

Anthropic의 Fable 5.2 공개 글에는 벤더가 보고한 숫자가 하나 더 있습니다. Fable 5.2는 High에서 FrontierCode 2.0이 45.3%, Opus 5.5는 Max에서 45.5%였고, 작업 한 건당 비용은 대략 절반이었습니다. 글은 또 Fable 5.2가 Xhigh에서 49.1%에 이르러 시험한 공개 모델 가운데 가장 높았다고 밝힙니다. 이것은 Fable의 High와 Opus의 Max를 짝지은 비교로, 둘 다 medium이었던 이번 테스트와는 다른 비교입니다.

실제 프로젝트에서는 쓸 만한 작업 한 건당 API 비용에 재시도와 검토 시간을 더해 비교하십시오. 작고 이미 통과하는 작업이라면 Opus가 더 싼 기본 선택입니다.

Claude Code에서 둘 중 하나를 쓰려면 Claude Code 설정 가이드에 base URL과 키 설정이 있습니다. 모델 페이지: Claude Fable 5.2, Claude Opus 5.5.

자주 묻는 질문

Fable 5.2가 Opus 5.5보다 비싼 값을 할까요?

높은 effort의 Opus가 직접 맡긴 작업에서 실패한 뒤 Fable을 검토하고, Fable이 개선하는지 확인하십시오. 이번 실행으로는 어려운 작업의 결론을 낼 수 없습니다. 작은 작업 네 가지에서는 둘 다 29/29 항목을 통과했고, 표준 요금 추정치는 Fable이 $0.1457, Opus가 $0.0310이었습니다.

Fable 5.2와 Opus 5.5가 같은 코드 테스트를 통과했나요?

네. 사용량 8/8, 커서 14/14, 파일 패치 7/7을 둘 다 통과했습니다. 원장 답도 둘 다 맞았고, 차이는 형식 한 가지로 Opus가 JSON 코드 펜스를 붙인 것입니다.

코딩에는 Fable 5.2와 Opus 5.5 중 어느 쪽이 더 싼가요?

Anthropic 표준 정가로는 Opus 5.5입니다. 100만 토큰당 입력 $4, 출력 $20이고 Fable 5.2는 $8과 $40입니다. 이번 토큰 사용량으로는 Fable의 표준 요금 추정치가 Opus의 4.7배였고, 네 가지에서 $0.1457 대 $0.0310이었습니다.

Fable 5.2가 Opus 5.5보다 빠른가요?

이번 실행으로는 판단할 수 없습니다. 관측한 합계는 Fable이 27.8초, Opus가 43.6초였지만 Fable의 응답은 standard 속도, Opus는 fast를 보고했고 speed는 지정하지 않았습니다. 같은 speed 설정으로 다시 비교하십시오.

OmniaKey로 Claude Code에서 두 모델을 쓸 수 있나요?

네. 이번 실행에서 두 모델 ID를 모두 OmniaKey로 호출했습니다. Claude Code 설정 가이드에 base URL과 키가 있습니다. 연결한 뒤 클라이언트에서 모델 이름을 확인하십시오.

확인한 출처

• Anthropic: Claude Fable 5.2 모델 개요
• Anthropic: Introducing Claude Fable 5.2 and Mythos 5.2
• Anthropic: Claude Opus 5.5 모델 개요
• Anthropic: 모델 개요
• Anthropic: 요금

모두 2026년 11월 12일에 확인했습니다.