2026년 6월 11일 JST 시점에서, Anthropic의 공식 발표, Claude API Docs, 이행 가이드, stop reason / fallback 문서, 데이터 보유 정책, Amazon Bedrock의 모델 카드를 확인했습니다.

Claude Fable 5를 단순히 "Opus보다 똑똑한 신규 모델"로만 보는 것은 위험합니다. API를 통합하는 측면에서 중요한 것은, 장시간 에이전트 (Long-running Agent)를 위한 능력과 동시에, refusal, fallback, always-on thinking, 30일 데이터 보유, 요금, 플랫폼 간 차이가 한꺼번에 늘어난다는 점입니다.

이 기사에서는 Fable 5를 프로덕션 제품이나 사내 에이전트에 도입하기 전에, 코드와 운영 측면에서 확인해야 할 포인트를 체크리스트로 정리합니다.

Fable 5는 "모든 요청을 교체하는 모델"이 아니라, 고난도·장시간·검증 루프가 포함된 태스크에 한정하여 사용해야 하는 모델입니다.

Fable 5는 Claude API, Claude Platform on AWS, Amazon Bedrock, Vertex AI, Microsoft Foundry에서 일반 제공됩니다. 반면, Mythos 5는 Project Glasswing의 승인된 고객 대상입니다.

원문: "most capable widely released model"

일본어 번역: 「널리 제공되는 모델 중에서 가장 성능이 뛰어난 모델」

공식 문서상의 스펙은 1M token context window, 최대 128k output tokens, 가격은 $10 / $50 per 1M tokens입니다. 이는 긴 사양서, 거대한 코드베이스, 조사부터 구현까지 아우르는 에이전트에게 매력적입니다. 단, 단발성 요약, 짧은 FAQ, 가벼운 분류에 사용하면 가격 차이에 부합하지 않을 수 있습니다.

추천하는 방법은 처음부터 다음과 같이 라우팅을 나누는 것입니다.

Fable 5에서 가장 깨지기 쉬운 부분은 API 에러 처리입니다. Fable 5의 안전 분류기 (Safety Classifier)가 응답을 거부할 경우, HTTP 상태 코드는 200 그대로 유지되면서, 응답 본문의 stop_reason이 refusal이 됩니다.

원문: "stop_reason: \"refusal\" as a successful HTTP 200 response"

일본어 번역: "stop_reason: \"refusal\"를 성공한 HTTP 200 응답으로 반환한다"

즉, try/catch만으로는 잡아낼 수 없습니다. 응답을 받은 후의 분기 처리가 필요합니다.

type ClaudeStopReason =
| "end_turn"
| "max_tokens"
...

특히 스트리밍 (Streaming)에서는 중간까지 출력된 후에 거부되는 케이스도 있습니다. 그 경우, 부분 출력물은 완성된 결과물로 취급하지 않고 폐기합니다.

Fable 5의 refusal는 대부분의 경우 다른 Claude 모델로 재실행할 수 있습니다. 다만, fallback 구현 방식은 플랫폼마다 다릅니다.

원문: "There are three ways to retry"

일본어 번역: "재시도에는 3가지 방법이 있다"

운영 로그에는 최소한 다음 내용을 남겨야 합니다.

{
"requested_model": "claude-fable-5",
"served_model": "claude-opus-4-8",
...

이 내용을 남기지 않으면, 나중에 "Fable 5에서 품질이 나온 것"인지, 아니면 "Opus 4.8로 fallback(우회)된 결과"인지를 구분할 수 없습니다.

Fable 5에서는 adaptive thinking이 항상 활성화되어 있습니다. thinking: {"type": "disabled"}는 지원되지 않으며, thinking의 깊이는 effort로 조정합니다.

원문: "adaptive thinking is the only thinking mode"

한국어 번역: "adaptive thinking이 유일한 thinking mode"

마이그레이션 가이드에서 중요한 점은, max_tokens가 답변 문장뿐만 아니라 thinking을 포함한 출력 전체의 상한선으로 작용한다는 것입니다. Opus 4.8에서 thinking 없이 작동하던 프로세스를 그대로 Fable 5로 변경하면, 동일한 max_tokens 설정이라도 체감 성능이 달라집니다.

const request = {
model: "claude-fable-5",
max_tokens: 16000,
...

먼저 high를 기본값으로 설정하고, 다음 지표들을 모니터링하면서 medium 또는 xhigh로 전환합니다.

• 출력 완료까지의 시간
• thinking tokens를 포함한 출력 토큰 수
• tool use 횟수
• 인간 리뷰에서의 재작업률 (rework rate)
• fallback / refusal 발생률

Fable 5의 가격은 입력 100만 토큰당 $10 / 출력 100만 토큰당 $50입니다. 마이그레이션 가이드에서는 Opus 4.8의 $5 / $25와 비교하여 두 배의 단가로 취급하고 있습니다.

원문: "priced at $10 per million input tokens"

한국어 번역: "입력 100만 토큰당 10달러"

Fable 5의 가치는 단 한 번의 응답이 조금 더 나은 것이 아니라, 인간이 몇 시간에서 며칠씩 걸리는 업무를 적은 횟수의 왕복(round-trip)으로 끝낼 수 있는가에 있습니다. 따라서 비교 단위는 1회 요청(request)이 아니라 1개 작업(job)으로 설정해야 합니다.

구독 사용자의 경우, 공식 발표를 통해 6월 22일까지는 추가 비용 없는 기간이며, 6월 23일부터는 사용 크레딧제로 전환된다는 안내가 있습니다. 평가를 진행한다면 이 날짜를 넘기기 전에 대표 태스크로 비교를 마쳐두어야 합니다.

Mythos-class 모델은 Fable 5를 포함하여 30일간의 데이터 보관이 필요합니다. 이는 기술적 선택의 문제가 아니라 계약 및 컴플라이언스(compliance) 확인 사항입니다.

원문: "retained for 30 days"

한국어 번역: "30일 동안 보관됨"

지원 문서에 따르면, ZDR을 설정한 Claude Console workspace, ZDR을 전제로 하는 Claude Enterprise / Claude Code, AWS Bedrock, Google Cloud Agent Platform, Microsoft Foundry를 통한 이용에도 영향을 미친다고 설명되어 있습니다. 마이그레이션 가이드에서도 조건을 충족하지 않는 조직의 Fable 5 요청은 400 invalid_request_error를 반환합니다.

될 수 있다고 여겨집니다.

도입 전에 다음과 같은 routing policy (라우팅 정책)를 미리 만드는 것이 현실적입니다.

model_routing_policy:
claude_fable_5:
allow:
...

Amazon Bedrock의 모델 카드에는 Fable 5의 context window (컨텍스트 윈도우), max output tokens (최대 출력 토큰), always-on adaptive thinking (상시 적응형 사고), stop_reason: "refusal" (중단 사유: 거부), prompt caching (프롬프트 캐싱), region (리전) / service tier (서비스 티어) 등이 정리되어 있습니다.

원문: "handle stop_reason: \"refusal\" as a primary response path"

한국어 번역: "stop_reason: \"refusal\"를 주요 응답 경로로 처리한다"

API 사양의 겉모습은 비슷해 보일지라도, 실제 운영 환경에서는 다음과 같은 점이 달라집니다.

• server-side fallback (서버 측 폴백) 사용 가능 여부
• retained data (보유 데이터)가 어떤 환경에 남는지
• regional availability (리전별 가용성) / cross-region routing (교차 리전 라우팅) 허용 가능 여부
• prompt cache (프롬프트 캐시)의 최소 토큰 수가 동일한지
• batch (배치)나 managed agent (관리형 에이전트) 사용 시 제약 사항이 있는지

멀티 클라우드에서 동일한 앱을 구동하는 경우, model = "claude-fable-5"라는 한 줄만 공통화하기보다는 platform adapter (플랫폼 어댑터)로 분리하는 것이 더 안전합니다.

• Fable 5로 업그레이드하기 위한 작업 조건을 정의했는가
• 모든 성공 응답에서 stop_reason을 확인하고 있는가
• refusal을 HTTP 에러가 아닌 일반 분기로 처리하고 있는가
• stop_details.category를 로그에 남기고 있는가
• fallback 전후의 requested_model / served_model을 기록하고 있는가
• 플랫폼별로 fallback 구현을 나누어 두었는가
• thinking: {"type": "disabled"}를 보내지 않는가
• max_tokens를 thinking (사고 과정)을 포함하여 재설계했는가
• effort (노력도)를 작업별로 측정하고 있는가
• 30일 데이터 보유와 ZDR (Zero Data Retention) 계약의 정합성을 확인했는가
• 작업 1단위로 Opus 4.8 / Fable 5의 비용과 재작업(rework)을 비교했는가

짧은 작업에서는 단가 차이만 눈에 띕니다. 우선은 시간이 오래 걸리고, 단계가 많으며, 리뷰 부하가 높은 작업으로 한정하십시오.

Fable 5에서 refusal (거부)는 운영 환경에서 발생할 수 있는 정상적인 분기입니다. catch가 아니라 응답 파서 (response parser)로 잡아내야 합니다.

사용자에게는 답변이 전달되었더라도, 실제로는 Opus 4.8이 답변했을 가능성이 있습니다. 이를 평가 로그에 남기지 않으면 Fable 5의 효과 측정이 무너집니다.

Fable 5의 도입 여부는 기술적인 문제보다 데이터 보유 조건에 의해 결정될 수 있습니다. 계약, 법무, 보안 리뷰를 뒤로 미루지 않는 것이 안전합니다.

Claude Fable 5는 장시간 에이전트나 대규모 코드 마이그레이션에 강한 반면, API 사용자에게 새로운 책임을 부여하는 모델입니다.

도입 전 살펴봐야 할 포인트는 벤치마크 순위가 아닙니다. refusal, fallback, always-on thinking, 30일 보유, 작업 1단위의 비용 대비 효과를 측정할 수 있는지 여부입니다. 이 부분을 먼저 구축한 뒤 Fable 5로 라우팅한다면, 강력한 모델을 '비싼 실험'이 아닌 재현 가능한 운영 개선으로 만들 수 있습니다.

• https://www.anthropic.com/news/claude-fable-5-mythos-5
• https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
• https://platform.claude.com/docs/en/release-notes/overview
• https://platform.claude.com/docs/en/about-claude/models/migration-guide
• https://platform.claude.com/docs/en/build-with-claude/handling-stop-reasons
• https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback
• https://support.claude.com/en/articles/15425996-data-retention-practices-for-mythos-class-models
• https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-fable-5.html