Claude Fable 5는 Mythos와 뭐가 다를까 2026 실무자가 먼저 볼 지점

Posted on by

2026년 6월 9일 Anthropic은 Claude Fable 5와 Claude Mythos 5를 발표했다. Fable 5는 일반 사용 가능한 Mythos급 모델이고, Mythos 5는 Project Glasswing 승인 고객에게 제한 제공되는 같은 계열의 고위험 영역 완화 모델이다.

이 발표를 보면 손이 먼저 간다. “Mythos급”, “가장 강한 일반 출시 모델”, “며칠짜리 장기 작업” 같은 표현이 한 줄에 같이 붙어 있다. 개발자라면 일단 마이그레이션 한 번 맡겨보고 싶고, 운영자라면 동시에 청구서와 감사로그가 떠오른다. 뇌는 박수치는데 지갑과 보안팀은 이미 회의실 예약하는 느낌이다.

그래서 이 글은 Fable 5 성능 자랑 요약이 아니다. 공식 발표와 API 문서를 바탕으로, Fable 5를 Opus 4.8 대신 언제 써볼 만한지, Mythos 5와 뭐가 다른지, 첫 실무 테스트 전에 어떤 조건을 확인해야 하는지 정리한 글이다. 2026년 9월 기준으로는 Fable 5.1/Mythos 5.1 업데이트와, 제 로컬 에이전트 워크플로에서 실제로 측정한 토큰 구조까지 함께 반영했다.

지금 결론

Claude Fable 5는 “일반 사용자가 접근 가능한 Mythos급 모델”로 보면 된다. Anthropic 설명에 따르면 Fable 5와 Mythos 5는 같은 underlying model을 공유하지만, Fable 5는 사이버보안, 생물학, 화학, 건강처럼 오남용 위험이 큰 영역에서 안전 분류기와 fallback을 붙인 버전이다. Mythos 5는 그 제한이 일부 완화된 형태로 Project Glasswing 파트너 등 승인 고객에게만 제공된다.

실무에서는 Fable 5를 모든 Claude 작업의 기본값으로 바꾸기보다, 긴 코드베이스 조사, 대규모 마이그레이션 계획, 복잡한 문서 분석, 비전 포함 리서치처럼 “긴 작업에서 더 좋은 판단이 돈값을 하는 경우”에 먼저 붙이는 편이 낫다. 반대로 짧은 요약, 단순 Q&A, 저위험 반복 작업은 Opus 4.8이나 Sonnet 계열이 더 현실적일 수 있다.

이 글은 아직 Fable 5 실사용 후기라기보다, 공식 발표 이후의 도입 전 점검표에 가깝다. 이미 Claude Code, API, MCP, 사내 자동화, 문서 분석 파이프라인을 굴리고 있고 “이제 Fable 5로 올려도 되나?”를 묻는 사람에게 맞다. 반대로 Claude를 가끔 채팅으로만 쓰는 사람이라면 가격표와 플랜 조건만 먼저 봐도 충분하다.

Fable 5와 Mythos 5 차이

공식 발표에서 가장 중요한 문장은 이름보다 분리 방식이다. Anthropic은 Fable 5를 safe for general use로 만든 Mythos-class 모델이라고 설명하고, Mythos 5는 Fable 5와 같은 underlying model이지만 일부 영역에서 safeguards가 lifted된 모델이라고 설명한다. 이름이 예쁜데, 구조는 꽤 딱딱하다. 일반 도로용 Fable, 제한 구역 작업용 Mythos에 가깝다.

항목 Claude Fable 5 Claude Mythos 5
접근 범위 일반 사용 가능 Project Glasswing 등 승인 고객 제한
성격 safeguards가 붙은 Mythos급 모델 같은 계열에서 일부 safety classifier 완화
주요 대상 고난도 코딩, 지식 업무, 비전, 장기 에이전트 작업 사이버 방어, 중요 인프라, 제한된 연구·방어 작업
API ID claude-fable-5 claude-mythos-5
컨텍스트 1M token 기본 1M token 기본
최대 출력 128k tokens 128k tokens
가격 입력 $10 / 출력 $50 per MTok 입력 $10 / 출력 $50 per MTok

여기서 핵심은 Mythos 5가 “더 좋은 유료 플랜”이 아니라는 점이다. 일반 개발자가 오늘 바로 골라 쓰는 모델은 Fable 5다. Mythos 5는 보안과 생명과학처럼 오남용 가능성이 큰 영역에서 검증된 파트너에게 제한 제공되는 모델이다.

이 차이는 글감으로도 중요하지만, 운영 문서로는 더 중요하다. 팀 내부에서 “우리도 Mythos 써보자”라는 말이 나오면 먼저 access model부터 확인해야 한다. 대부분의 팀은 Mythos 5가 아니라 Fable 5를 기준으로 PoC를 설계해야 한다.

왜 일반 출시인데도 조심해야 하나

Anthropic은 Fable 5가 지금까지 일반 제공한 모델 중 가장 강력하다고 말한다. 동시에 safeguard 없이 이런 모델을 내놓으면 사이버보안 같은 영역에서 심각한 피해에 악용될 수 있다고도 적었다. 그래서 Fable 5는 일부 요청에서 다음으로 강한 모델인 Claude Opus 4.8의 응답으로 fallback될 수 있다.

공식 발표 기준 이 safeguards는 보수적으로 조정되어 있고, 평균적으로는 세션의 5% 미만에서 트리거된다고 설명된다. 숫자만 보면 작아 보인다. 하지만 실무에서는 그 5%가 중요한 작업에 걸릴 수 있다. 보안 감사, 취약점 분석, 생명과학 리서치, 내부 정책 검토처럼 민감한 작업은 “성능 좋은 모델을 쓴다”보다 “어떤 요청이 거절되거나 fallback되는가”를 먼저 봐야 한다.

API 문서도 이 지점을 분명히 한다. Fable 5가 요청을 거절하면 Messages API는 HTTP 에러가 아니라 stop_reason: "refusal"이 포함된 성공 응답을 반환할 수 있다. 즉 기존 코드가 “200이면 성공”으로만 짜여 있으면 이상한 상태가 된다. 모델은 정중히 거절했는데 파이프라인은 “성공했네?” 하고 다음 단계로 넘어갈 수 있다. 자동화한테 빈 도시락 들려 보내는 셈이다.

Opus 4.8 대신 언제 써볼까

Fable 5의 장점은 짧은 답변보다 긴 작업에서 더 커진다. Anthropic은 Fable 5가 소프트웨어 엔지니어링, 지식 업무, 비전, 과학 연구에서 강하고, 작업이 길고 복잡할수록 기존 모델 대비 리드가 커진다고 설명했다. AWS도 장기 실행, 복잡한 지식 업무, 비전 기반 작업, self-verification을 차별점으로 잡았다.

그래서 첫 후보는 대규모 코드베이스 이해다. 예를 들어 “이 저장소에서 권한 체크가 흩어진 지점을 찾아라”, “레거시 모듈을 새 구조로 옮기려면 어떤 순서가 안전한가”, “테스트가 없는 위험 파일을 우선순위로 나눠라” 같은 작업은 Fable 5의 장점과 맞는다. 이 작업들은 답 하나보다 조사, 판단, 근거 정리가 중요하다.

두 번째 후보는 문서와 표, 차트가 섞인 리서치다. Fable 5는 비전과 문서 기반 reasoning이 강화된 모델로 안내된다. PDF, 표, 차트, 스크린샷, UI 이미지가 섞인 업무에서 “읽고 요약해줘”를 넘어서 “근거를 비교하고 의사결정표로 바꿔줘”가 필요하면 테스트할 만하다.

세 번째 후보는 장기 에이전트 작업이다. 다만 여기에는 조건이 붙는다. Fable 5가 더 오래 버틸 수 있다는 말은, 잘못된 권한을 오래 들고 있을 수도 있다는 뜻이다. 긴 작업을 맡길수록 작업 예산, tool 권한, 중단 조건, 로그 요약, 사람이 보는 checkpoint가 더 중요해진다. 100만 줄 코드를 AI로 40일에 만든 하네스 엔지니어 사례처럼, 장기 작업의 성패는 모델 성능보다 중단과 복구 설계에서 갈리는 경우가 많다.

아직 Opus 4.8이 나은 경우

모든 작업에 Fable 5를 붙이면 기분은 좋다. 문제는 비용과 운영 조건이다. Fable 5는 입력 $10, 출력 $50 per million tokens로 안내되어 있다. 캐시 읽기는 $1, 캐시 쓰기는 $12.50(5분)·$20(1시간)이다. 더 저렴한 Opus 계열과 바꿔 쓸지 판단할 때는 두 모델의 요금 페이지를 같은 날짜 기준으로 직접 대조해야 한다. 단가는 개정되는 항목이라 글에 박아두면 금방 낡는다.

짧은 요약, 단순 코드 설명, 일반 문서 초안, 작은 버그 수정, 이미 테스트가 잘 갖춰진 수정은 Opus 4.8이나 더 낮은 비용 모델로 충분할 수 있다. 특히 사람이 직접 검수할 작은 작업이라면 가장 비싼 모델을 쓰는 것이 항상 이득은 아니다. 모델 선택은 자존심 배틀이 아니라 손익계산이다.

또 하나는 데이터 보관 조건이다. API 문서 기준 Claude Fable 5와 Claude Mythos 5는 Covered Models로 지정되어 30-day data retention이 적용되고, zero data retention에서는 사용할 수 없다. 보안·법무·고객계약상 zero data retention이 필요한 팀이라면 이 조건 하나로도 Fable 5를 바로 쓰기 어렵다.

구독 플랜도 확인이 필요하다. Anthropic 발표는 2026년 6월 9일부터 6월 22일까지 Pro, Max, Team, seat-based Enterprise 플랜에 Fable 5가 추가 비용 없이 포함되고, 6월 23일부터는 사용량 크레딧이 필요하다고 안내했다. 이 기간은 capacity에 따라 연장될 수 있지만, 발표 시점 기준으로는 “무료처럼 보이는 테스트 기간”과 “이후 과금 방식”을 분리해서 봐야 한다.

개발자가 봐야 할 API 변화

첫 번째는 adaptive thinking이다. API 문서에 따르면 Claude Fable 5와 Claude Mythos 5에서는 adaptive thinking이 항상 켜져 있고, thinking: {"type": "disabled"}는 지원되지 않는다. 기존 모델에서 thinking을 끄거나 수동 budget으로 제어하던 코드는 migration 전에 확인해야 한다.

두 번째는 raw chain of thought가 반환되지 않는다는 점이다. 문서 기준 raw thinking content는 never returned이고, thinking.display는 기본적으로 "omitted"다. 필요한 경우 "summarized"로 사람이 읽을 수 있는 thinking summary를 받을 수 있지만, 원문 사고 과정 자체를 가져오는 방식은 아니다.

세 번째는 refusal과 fallback 처리다. Fable 5는 요청과 생성 중 safety classifiers를 실행하고, 거절 시 stop_reason: "refusal"을 줄 수 있다. beta fallback parameter나 SDK middleware를 통해 다른 모델로 retry할 수 있지만, 이때 billing과 prompt-cache credit 동작까지 같이 봐야 한다. 거절을 어디서 잡아 어떤 종료 코드로 내릴지는 모델 문제가 아니라 인터페이스 설계 문제에 가깝고, 이 부분은 AI 에이전트 자동화가 더 깨지게 만드는 CLI 설계에서 정리한 원칙과 같은 맥락이다.

네 번째는 tokenizer 변화다. Release notes는 Fable 5와 Mythos 5가 Claude Opus 4.7부터 도입된 tokenizer를 사용하고, Opus 4.7 이전 모델 대비 같은 텍스트가 대략 30% 더 많은 token으로 잡힐 수 있다고 안내한다. 긴 프롬프트를 쓰는 팀은 모델 ID만 바꿔 놓고 비용이 왜 튀는지 고민하지 말고, token counting API로 먼저 재측정하는 편이 낫다.

첫 PoC는 이렇게 잡는 게 낫다

Fable 5 첫 테스트는 “우리 서비스 전체를 고쳐줘”가 아니라 “닫힌 범위에서 어렵지만 검증 가능한 작업”이어야 한다. 모델이 강해질수록 첫 작업을 크게 잡고 싶어지는데, 운영에서는 반대로 해야 한다. 강한 모델일수록 작은 실험에서도 배울 게 많다.

테스트 항목 권장 기준 이유
작업 범위 한 repo의 한 모듈 또는 한 문서 묶음 비용과 검수 범위 제한
권한 read-only 또는 patch 초안 장기 작업의 사고 반경 축소
출력 의사결정표, migration plan, diff 후보 사람이 검토하기 쉬움
예산 total_tokens, cached_read_tokens, new_input_tokens, output_tokens 4개를 분리 기록 캐시 절감이 총비용에 얼마나 반영되는지 확인
반복 구간 모든 호출에서 되풀이되는 프롬프트 블록 목록화 캐시 후보 식별
실패 처리 refusal, fallback, 중단 조건 로깅 “200 성공” 착시 방지
데이터 zero retention 필요 없는 샘플 Covered Model 조건 대응

예산 항목을 토큰 총량 하나로만 기록하면 5.1 시대에는 거의 쓸모가 없다. 같은 총량이라도 캐시 읽기 비중이 얼마냐에 따라 청구서가 달라지기 때문이다. 반복 구간을 먼저 목록화해두면 캐시 히트율을 우연에 맡기지 않고 설계로 만들 수 있는데, 이 구조 자체에 대한 정리는 사내 AI 에이전트가 비슷한 구조로 수렴하는 이유에서 따로 다뤘다.

제가 운영하는 워크플로에서는 첫 작업을 코드 수정이 아니라 “조사 보고서”로 시작한다. 예를 들어 기존 에이전트 워크플로에서 권한이 넓은 tool, 로그가 빈 구간, fallback이 필요한 단계, 긴 컨텍스트가 실제로 도움이 되는 지점을 찾아보게 한다. 이건 Fable 5의 장점인 장기 추론을 쓰면서도, 실패했을 때 실제 시스템을 망가뜨리지 않는다.

두 번째 작업부터 patch 초안으로 넓힌다. 이때도 branch, diff, test command, rollback note를 한 묶음으로 남겨야 한다. Fable 5가 더 좋은 코드를 만든다 해도 “좋아 보이는 변경”과 “운영 가능한 변경”은 다르다.

2026년 9월 업데이트: Fable 5.1로 무엇이 달라졌나

이 글을 처음 쓴 2026년 6월 이후 Anthropic은 Claude Fable 5.1과 Claude Mythos 5.1을 출시했다. 가장 실무에 바로 영향을 주는 변화는 성능 자랑이 아니라 비용 구조다. VentureBeat 보도 기준으로 Fable 5.1은 prompt cache read 비용을 5.1 이전 대비 75% 낮췄다. 이 75%라는 숫자는 제가 Anthropic 공식 문서에서 직접 확인한 값이 아니라 보도에서 인용한 값이므로, 계약이나 예산 문서에 넣을 때는 요금 페이지로 한 번 더 확인하는 편이 안전하다.

이 변화는 앞서 정리한 “Fable 5는 비싸서 짧은 작업엔 안 맞는다”는 판단을 부분적으로 흔든다. 같은 시스템 프롬프트나 긴 컨텍스트를 반복해서 재사용하는 워크플로, 예를 들어 같은 코드베이스를 여러 번 조회하는 에이전트 루프나 같은 문서 뭉치를 여러 질문에 재사용하는 리서치 파이프라인이라면, cache read 구간의 비용이 줄어들어 총비용 계산이 달라질 수 있다.

다만 이 절감은 cache read에만 적용되고, 신규 입력 토큰과 출력 토큰 단가($10 / $50 per MTok)는 그대로다. 즉 “5.1이니까 전체적으로 싸졌다”가 아니라 “반복 조회 구간만 싸졌다”로 이해해야 한다. 그리고 여기서 대부분의 팀이 한 번 미끄러진다. 캐시 절감률과 총비용 절감률을 같은 숫자로 착각하는 것이다.

고정 바닥 실측: 캐시 절감률은 총비용 절감률이 아니다

업계어부터 풀고 가자. 고정 바닥은 에이전트를 한 번 호출할 때마다 무조건 다시 지불하는 컨텍스트를 말한다. 사람말로 바꾸면 “매번 새 직원 앉혀놓고 사내 규정집 전권을 처음부터 다시 읽히는 비용”이다. 회의는 3분인데 출근 서류 작성이 40분인 회사를 떠올리면 된다. 그래서 확인할 건 하나다. 우리 파이프라인에서 호출마다 반복 낭독되는 문서가 정확히 몇 바이트인가.

2026년 9월 15일, 제가 운영하는 morning-briefing-team 워크플로를 v1.15.2에서 v2.2.0으로 개조하면서 이 값을 실제로 쟀다. 서브에이전트 호출을 13~16개에서 3개로 줄였고, WebSearch도 21~23회에서 7회 이하로 줄였다. 호출 수를 5분의 1로 깎았으니 토큰도 그만큼 줄어들 거라고 사전에 120K 정도를 예상했다.

실측은 338,924 토큰이었다. 추정 대비 약 2.8배다. 세 콜의 내역은 HQ 91,321, 워커 A 121,654, 워커 B 125,949였다. 호출 수를 아무리 줄여도 콜당 90~126K의 바닥이 그대로 따라붙은 것이다.

바닥의 정체는 WebSearch가 아니라 자동 로딩되는 규칙 문서였다. CLAUDE.md 9,848바이트, .claude/CLAUDE.md 7,795바이트, .claude/rules/*.md 12개 65,586바이트, 사용자 프레임워크 문서 69,967바이트로 합계 153,196바이트. 이 덩어리가 서브에이전트 호출마다 한 번씩 다시 실린다. 토큰 비용의 지배항은 검색 횟수가 아니라 호출 횟수 × 고정 바닥이었다.

여기서 Fable 5.1 캐시 절감을 다시 보면 해석이 달라진다. 이 고정 바닥은 모든 호출에서 문자 그대로 동일한 블록이므로 prompt cache의 이상적인 후보다. 반대로 말하면, 캐시로 단가가 내려가도 이 블록은 호출 수만큼 계속 반복해서 청구된다. 캐시 읽기가 75% 싸졌다는 말과 총비용이 75% 싸졌다는 말 사이에는 호출 횟수라는 곱셈이 하나 끼어 있다.

그래서 Fable 5로 에이전트 루프를 올릴 계획이라면 순서를 이렇게 잡는 게 낫다. 먼저 호출 개수를 줄이고, 그다음 호출마다 반복되는 블록을 캐시 가능한 형태로 고정하고, 마지막에 모델 단가를 비교한다. 이 순서를 뒤집어서 모델부터 바꾸면, 청구서를 보고 나서야 곱셈의 존재를 알게 된다. 저는 사전 추정을 2.8배 빗나가고 나서야 알았다.

실수 TOP

첫 번째 실수는 Fable 5를 Mythos 5처럼 말하는 것이다. Fable 5는 일반 사용 가능한 Mythos급 모델이지만, safeguards가 붙어 있다. Mythos 5는 제한 접근 모델이다. 이 둘을 섞어서 설명하면 독자도 헷갈리고, 팀 내부 PoC 범위도 이상해진다.

두 번째 실수는 fallback을 장애처럼만 보는 것이다. Fable 5의 fallback은 단순 장애가 아니라 안전 설계의 일부다. 문제는 제품 코드가 이 상태를 어떻게 처리하느냐다. refusal을 에러로 볼지, 사용자에게 설명할지, Opus 4.8로 재시도할지, 특정 작업은 사람 검토로 넘길지 미리 정해야 한다.

세 번째 실수는 가격만 보고 판단하는 것이다. Fable 5는 단가가 비싸지만, 긴 작업에서 검수 시간을 줄이면 이득일 수 있다. 반대로 단순 작업에 붙이면 비싼 자동완성기가 된다. 모델 가격보다 총비용을 봐야 한다. 총비용에는 token, 실행 시간, 사람 검수, 재시도, 실패 복구가 들어간다. 5.1 이후에는 여기에 cache read 비율까지 추가로 봐야 한다.

네 번째 실수는 1M context를 창고처럼 쓰는 것이다. 1M context는 강력하지만, 모든 로그와 문서를 다 때려 넣으라는 뜻은 아니다. 긴 컨텍스트일수록 소스 경계, 우선순위, task budget, compaction, tool result clearing 같은 운영 기법이 더 중요해진다. 컨텍스트가 커지면 기억력은 좋아지지만, 방 청소를 안 해도 된다는 뜻은 아니다.

다섯 번째 실수는 매 호출마다 전체 프롬프트를 새로 싣는 것이다. 위 실측처럼 153,196바이트짜리 규칙 묶음이 호출마다 통째로 다시 올라가면, 캐시 단가가 아무리 내려가도 절감 여지를 스스로 버리는 셈이다. 에이전트나 반복 파이프라인을 만들기 전에 “모든 호출에서 똑같이 반복되는 부분이 무엇인가”를 체크리스트로 먼저 뽑고, 그 블록을 프롬프트 앞쪽에 고정 배치해 캐시 경계를 만들어두는 편이 낫다.

내 기준 정리

Claude Fable 5는 2026년 현재 “긴 작업을 맡기는 방식”을 한 단계 끌어올리는 모델로 볼 만하다. 특히 코드베이스 전체 조사, 문서 기반 판단, 비전 포함 분석, 장기 에이전트 작업에서는 테스트 가치가 크다. 하지만 일반 사용 가능하다는 말이 곧 운영 준비가 끝났다는 뜻은 아니다.

팀에서 바로 할 일은 모델 찬양문을 쓰는 게 아니라 세 가지 표를 만드는 것이다. 첫째, 어떤 작업을 Fable 5로 올릴지 정하는 escalation 표. 둘째, refusal과 fallback을 어떻게 처리할지 정하는 API 표. 셋째, 비용과 데이터 보관 조건을 검토하는 운영 표다. 5.1 이후에는 여기에 호출 횟수와 cache read 비율을 같이 추적하는 항목도 추가하는 편이 낫다.

제 결론은 이렇다. Fable 5는 “기본 모델 교체”보다 “고난도 작업용 상위 레인”으로 먼저 도입하는 게 좋다. Opus 4.8을 일상 작업의 안정 레인으로 두고, Fable 5는 긴 조사와 높은 판단 비용의 작업에 올린다. Mythos 5는 일반 팀의 사용 모델이 아니라, Project Glasswing 같은 승인 흐름의 제한 모델로 분리해서 이해한다.

AI 모델이 강해질수록 좋은 프롬프트보다 좋은 운영표가 더 중요해진다. 단가표는 공급사가 정하지만, 호출 횟수와 반복 블록은 우리가 정한다. 실측해보면 후자 쪽이 청구서를 더 많이 흔들었다.

FAQ

Claude Fable 5는 Claude Mythos 5와 같은 모델인가?

공식 발표 기준으로는 같은 underlying model을 공유하지만, Fable 5에는 일반 사용을 위한 safeguards가 붙어 있다. Mythos 5는 일부 safeguards가 완화된 형태로 Project Glasswing 등 승인 고객에게 제한 제공된다. 실무적으로는 Fable 5를 일반 사용 가능 모델, Mythos 5를 제한 접근 모델로 나누는 게 안전하다.

Claude Fable 5는 언제부터 사용할 수 있나?

Anthropic 발표와 API 문서 기준 Claude Fable 5는 2026년 6월 9일부터 Claude API, Claude Platform on AWS, Amazon Bedrock, Vertex AI, Microsoft Foundry에서 사용할 수 있다. 구독 플랜에서는 2026년 6월 9일부터 6월 22일까지 Pro, Max, Team, seat-based Enterprise에 포함되고, 6월 23일부터는 usage credits가 필요하다고 안내됐다.

가격은 얼마인가?

Claude Fable 5와 Claude Mythos 5 모두 입력 $10 per million tokens, 출력 $50 per million tokens로 안내되어 있다. 캐시는 읽기 $1, 쓰기 $12.50(5분)·$20(1시간) per million tokens다. Opus 4.8 계열과 비교할 때는 두 모델의 요금 페이지를 같은 날짜 기준으로 나란히 확인하는 편이 안전하다. 다만 Fable 5.1부터는 prompt cache read 비용이 낮아졌다고 보도됐으므로, 같은 컨텍스트를 반복 조회하는 워크플로는 총비용이 달라질 수 있다.

Fable 5.1의 캐시 절감은 어떤 워크플로에서 가장 효과가 클까?

호출마다 동일한 블록이 반복 적재되는 구조일수록 효과가 크다. 제 워크플로 실측으로는 서브에이전트 호출을 13~16개에서 3개로 줄인 뒤에도 콜당 90~126K의 고정 바닥이 남았고, 그 정체는 CLAUDE.md와 규칙 문서 합계 153,196바이트였다. 이런 블록은 캐시 후보로 가장 이상적이다. 반대로 매번 새 문서를 넣는 일회성 분석은 캐시 절감 효과가 거의 없다.

캐시 비용이 75% 줄면 총비용도 75% 줄어드나?

아니다. 캐시 절감은 반복 구간의 단가에만 적용되고, 고정 바닥은 호출 수만큼 계속 반복된다. 제 실측에서는 사전 추정 120K 대비 실제 338,924 토큰이 나왔고, 약 2.8배 차이의 원인은 검색 횟수가 아니라 호출당 바닥이었다. 캐시를 켜기 전에 호출 개수부터 세는 편이 낫다.

1M context가 있으면 긴 문서를 전부 넣어도 되나?

가능하다고 해서 항상 좋은 것은 아니다. Fable 5와 Mythos 5는 1M token context window와 128k max output을 지원하지만, 긴 컨텍스트는 비용과 검수 부담도 같이 키운다. 중요한 문서, source map, 작업 목표, 제외 범위를 정리해서 넣는 편이 낫다.

Fable 5가 거절하면 API 오류로 처리되나?

문서 기준 Fable 5가 요청을 decline하면 Messages API는 successful HTTP 200 응답 안에 stop_reason: "refusal"을 반환할 수 있다. 그러므로 기존 파이프라인은 HTTP status만 보지 말고 stop reason과 category를 확인해야 한다. 필요하면 fallback parameter나 SDK middleware로 다른 모델 재시도를 설계할 수 있다.

Fable 5.1은 Fable 5와 완전히 다른 모델인가?

아니다. Anthropic 발표 기준 5.1은 5의 업데이트 버전이며, 가장 크게 보도된 실무 변화는 prompt cache read 비용 75% 절감이다. 신규 입력·출력 토큰 단가는 5와 동일하게 유지된다.

zero data retention이 필요한 회사도 쓸 수 있나?

API 문서 기준 Claude Fable 5와 Claude Mythos 5는 Covered Models로 지정되어 30-day data retention이 적용되고, zero data retention에서는 사용할 수 없다. 고객 계약, 내부 보안 정책, 법무 조건상 zero retention이 필수인 조직은 도입 전에 이 조건을 확인해야 한다.

공식 출처

관련 글