Claude Fable·Opus·Sonnet·Haiku 비교: 승급 기준 만들기

Claude 모델 선택을 한 번의 구매 결정으로 보면 곧 다시 고민하게 됩니다. 업무가 바뀌고, model ID와 가격이 바뀌고, tool과 prompt도 달라지기 때문입니다. 더 오래가는 해법은 업무군마다 기본 모델을 두고, 실패 로그가 임계값을 넘을 때만 인접 모델로 승급하는 것입니다.

2026년 8월 15일 기준의 시작점은 다음과 같습니다. schema나 규칙으로 결과를 잡아낼 수 있는 대량 작업은 Haiku 4.5, 일반적인 코드·분석·vision·tool use는 Sonnet 5, 실패 복구가 비싸고 오래 실행되는 작업은 Opus 5를 먼저 시험합니다. Fable 5는 Opus가 정해진 effort와 timebox 안에서 반복적으로 검수를 통과하지 못한 subset에 넣습니다. 모든 요청을 Fable로 보내는 것은 운영 규칙이 아니라 비용 문제를 숨기는 방법입니다.

API 단가와 Claude Code 사용량은 같은 숫자가 아니다

claude-fable-5, claude-opus-5, claude-sonnet-5, claude-haiku-4-5-20251001은 Anthropic API model ID입니다. Claude Code와 Claude chat은 여기에 파일 선택, tool, 권한, context 관리, 플랜 한도, usage credits와 제품 측 routing을 더합니다. Bedrock과 Google Cloud도 별도 endpoint와 가격 계약을 갖습니다.

따라서 API의 100만 token 가격으로 Claude Code 한 세션 비용을 바로 계산할 수 없습니다. API에 있는 모델이 내 구독 picker에 보인다고 가정해서도 안 됩니다. 아래 비교는 Anthropic 직접 API 계약이며, 실제 구매 전 계정·조직·지역의 이용 가능성과 한도를 따로 확인해야 합니다.

현재 네 모델의 계약부터 고정한다

Anthropic models overview의 현재 기준은 다음과 같습니다.

예전 pricing 문서에는 Sonnet 5를 9월부터 $3/$15로 올린다는 계획이 남아 있습니다. 그러나 8월 10일 수정된 Sonnet 5 발표는 $2/$10을 영구 가격으로 확정했고 최신 overview도 같은 값입니다. 계약 규모가 크다면 결제 직전 다시 확인하세요.

호출 단가만 보면 Haiku가 Sonnet의 절반, Fable이 Opus의 두 배입니다. 하지만 낮은 가격이 자동으로 낮은 작업 비용은 아닙니다. Haiku가 schema 오류로 세 번 재시도되고 사람이 결과를 수정한다면 한 번에 통과한 Sonnet보다 비쌀 수 있습니다. 반대로 중요한 migration에서 Fable이 사람 개입과 재작업을 크게 줄인다면 높은 token 단가를 정당화할 수 있습니다.

모델마다 “승급 알람”을 정한다

업무를 모델 이름으로 나누기보다 실패 형태로 나누면 경계가 선명해집니다.

Haiku → Sonnet: JSON/schema 위반, 누락 field, tool call 실패 또는 retry가 정한 비율을 넘을 때 승급합니다. 단, prompt가 불명확하거나 검수기가 잘못된 경우는 모델 변경 전에 입력을 고칩니다.

Sonnet → Opus: 다중 파일 작업이 반복해서 중단되거나, 장기 chain에서 조건을 잃거나, review 후 핵심 설계를 다시 쓰는 비율이 임계값을 넘을 때 승급합니다. 단순히 답변이 길다는 이유는 승급 조건이 아닙니다.

Opus → Fable: 같은 고난도 task에서 충분한 effort와 도구를 제공해도 여러 표본이 같은 rubric을 통과하지 못하거나, 사람의 구조적 개입이 줄지 않을 때만 Fable을 시험합니다. Fable 5 발표가 최고 능력 모델로 설명하더라도, 쉬운 작업의 상시 기본값이라는 뜻은 아닙니다.

강등도 자동화: Sonnet 작업 중 안정적으로 schema를 통과하는 subset은 Haiku canary로, Opus 작업 중 낮은 위험과 짧은 chain은 Sonnet canary로 보냅니다. 승급만 있고 강등이 없으면 시간이 지나며 모든 traffic이 비싼 모델로 몰립니다.

thinking 차이는 배포 호환성 문제다

Fable 5는 adaptive thinking이 항상 활성화됩니다. Opus 5와 Sonnet 5는 adaptive thinking이 기본이며 추론 깊이를 effort로 조절합니다. Haiku 4.5는 manual extended thinking을 지원하지만 adaptive는 아닙니다.

Haiku의 thinking: {type: "enabled", budget_tokens: N} 설정을 Sonnet 5에 그대로 복사하면 HTTP 400이 날 수 있습니다. Sonnet 5는 비표준 temperature, top_p, top_k도 지원하지 않습니다. 새 tokenizer 때문에 같은 prompt의 token 수가 Sonnet 4.6과 달라질 수 있어 비용·max_tokens·truncation도 다시 봐야 합니다.

migration guide를 따라 model ID, thinking, effort, sampling, output limit, cache, streaming, tool call, refusal와 fallback을 canary에서 확인하세요. model versioning 문서에 따르면 4.6 이후 날짜 없는 ID는 고정 snapshot이지 자동으로 갱신되는 latest가 아닙니다. ID 변경은 배포 이벤트로 기록해야 합니다.

대시보드에는 평균보다 실패 꼬리를 남긴다

전체 네 모델을 한 번에 붙이지 말고 인접 후보 두 개만 비교합니다. 반복 작업은 Haiku와 Sonnet, 일상 작업은 Sonnet과 Opus, 능력 한계 task는 Opus와 Fable입니다. 8~15개의 실제 task에 같은 input, tool, 권한, timebox, 중지 규칙과 검수 조건을 줍니다.

남길 데이터는 다음과 같습니다.

9번 빠르고 1번 복구 불가능한 경로는 평균 지연만 보면 좋아 보입니다. 고위험 업무에서는 P95, 최악 실패와 rollback 비용이 평균보다 중요합니다. 한 후보만 사람이 적극적으로 구제하지 말고 같은 종류의 수정 기회를 제공하세요.

최종 비용은 이렇게 계산합니다.

합격 작업 비용 = (모델 비용 + 사람 시간 + 재작업 비용) / 검수 통과 건수

Anthropic의 모델 선택 가이드도 실제 prompt와 데이터로 평가할 것을 권합니다. 여러 표본에서 비용 차이가 일반 변동과 전환 비용보다 커질 때만 기본 경로를 바꾸고, 소량 canary를 계속 남깁니다.

운영 규칙의 예는 단순합니다. Haiku는 schema/retry 임계값에서 Sonnet으로, Sonnet은 높은 실패 비용이나 긴 chain에서 Opus로, Opus는 충분한 effort 뒤에도 같은 rubric을 못 통과할 때 Fable로 승급합니다. 가격, tokenizer, tool, model ID 또는 업무 비중이 바뀌면 임계값을 다시 학습합니다.

선택 대상이 API 모델이 아니라 shell 권한, 구독, interface, 팀 위임을 포함한 개발 제품이라면 Claude Code와 Codex 워크플로 비교로 문제를 분리하는 편이 정확합니다.