Claude Fable 5는 Anthropic이 일반 제공하는 모델 중 가장 고성능인 모델입니다. 장시간의 자율 에이전트(Autonomous Agent)나, 한 번에 복잡한 시스템을 구축해야 하는 난도가 높은 태스크에서 힘을 발휘합니다. 반면, 요금은 입력 100만 토큰당 $10, 출력 $50로, Opus 4.8의 약 2배, Sonnet 5의 3~5배에 달할 정도로 높습니다.

이 기사에서는 Fable 5를 "모든 태스크에 그대로 통과시키는" 것이 아니라, 하네스(Harness, 에이전트 실행 프레임워크)를 고안하여 비용 효율적으로 사용하는 설계 패턴을 정리합니다. 구체적으로는 오케스트레이터/워커(Orchestrator/Worker)의 분업, Advisor 도구, effort의 구분 사용, 캐시(Cache) 및 컨텍스트(Context) 축소, 비동기 서브 에이전트(Asynchronous Sub-agent)의 5가지입니다. 이와 함께 필수 주제로서 타 LLM과의 벤치마크 비교와 모델별 가격도 살펴보겠습니다.

계기는 Claude Platform 팀의 Lance Martin 씨가 X에서 공유했던 "Fable 5로 성능과 비용을 여러 eval로 측정해 보았다"라는 일련의 게시물입니다. 거기서 보인 "프론티어 지능을 사용하는 곳을 좁히면, 품질을 유지하면서 비용을 크게 낮출 수 있다"라는 사고방식을 실측값과 함께 정리합니다.

먼저 수치 취급에 대해 말씀드립니다. 본 기사의 벤치마크 및 비용 실측값은 Anthropic 공식, 각사 공시값, 제3자 집계 데이터를 모은 것으로, 동일한 환경에서 동일한 날에 다시 돌린 값은 아닙니다. 경향을 파악하는 자료로 읽어주시기 바랍니다. Fable 5 자체의 사양과 가격은 공식 문서에 준합니다.

먼저 대상을 확인합니다. Fable 5(모델 ID claude-fable-5)는 가장 까다로운 추론과 장기적인 에이전트 작업을 위해 설계된 Anthropic의 최상위 클래스 모델입니다. 컨텍스트 윈도우(Context Window)는 1M 토큰, 최대 출력은 128k 토큰입니다.

Fable 5에는 Opus 계열과 다른 API 동작이 몇 가지 있습니다. 하네스를 구성할 때 영향을 미치므로 미리 파악해 둡니다.

• 사고(Thinking)는 항상 켜져 있습니다. thinking 파라미터는 생략하거나 {type: "adaptive"}를 전달합니다. {type: "disabled"}나 budget_tokens를 보내면 400 에러가 발생합니다. 사고의 깊이는 output_config.effort (low / medium / high / xhigh / max)로 제어합니다.
• 가공되지 않은 사고 연쇄(Chain of Thought)는 반환되지 않습니다. display: "summarized"로 요약본만 받을 수 있습니다.
• 안전 분류기(Safety Classifier)가 거부할 경우, 에러가 아니라 stop_reason: "refusal"을 포함한 HTTP 200이 반환됩니다.
• 30일 데이터 유지가 필수이며, 제로 데이터 유지(ZDR, Zero Data Retention) 환경에서는 사용할 수 없습니다.

그리고 본론인 가격입니다. Fable 5의 높은 가격이 바로 하네스 설계의 동기가 됩니다.

이 표가 모든 출발점입니다. Fable 5는 똑똑하지만, 동일한 작업을 Sonnet 5에 흘려보내면 단가는 3~5분의 1, Haiku 4.5라면 10분의 1입니다. 그렇기에 "Fable 5의 지능이 정말로 효과적인 곳에만 사용하고, 그 외에는 저렴한 모델에게 대신하게 한다"라는 발상이 살아납니다.

단순하게 접근하면, 에이전트의 모든 단계(계획 수립, 파일 읽기, 테스트 실행, 포맷팅 등)를 Fable 5가 담당합니다. 이는 작동은 하지만, 단가가 높은 모델에게 잡무까지 전부 시키고 있는 상태입니다.

다음 그림은 단순한 사용법과 하네스 설계의 차이를 보여줍니다.

이 그림의 포인트는 Fable 5의 역할을 "고레버리지 추론(High-leverage Reasoning)"으로 좁힌 점입니다. 계획을 세우고, 무엇을 위임할지 결정하며, 돌아온 결과를 통합한다. 이 부분은 품질 차이가 출력에 명확히 나타나므로 Fable 5의 가격에 부합합니다. 반대로, 정해진 절차를 따라가기만 하는 기계적인 작업은 저렴한 모델로도 충분한 품질을 낼 수 있습니다.

사고방식을 한마디로 요약하면 다음과 같습니다.

높은 지능은 판단이 어려운 곳에만 사용합니다.

이후에는 그 "선별 방법"을 5가지 패턴으로 나누어 구체화하겠습니다.

가장 효과가 큰 것은 Fable 5를 오케스트레이터 (Orchestrator, 지휘 역할)로 두고, 실제 작업은 저렴한 모델인 워커 (Worker)에게 위임하는 구성입니다.

다음 도표는 그 역할 분담을 보여줍니다.

이 도표의 핵심은 Fable 5가 계획과 통합이라는 "머리를 쓰는 부분"에만 토큰을 사용하고, 양이 많은 기계적인 작업은 저렴한 모델이 흡수하고 있다는 점입니다. 난제는 Opus 4.8, 보일러플레이트 (Boilerplate)는 Sonnet 5, 단순 작업은 Haiku 4.5와 같이 업무의 무게에 따라 모델을 배분합니다.

Claude Code와 같은 에이전트 (Agent) 환경에서는 Fable 5를 오케스트레이터로 하여 Opus / Sonnet 서브 에이전트 (Sub-agent)로 위임함으로써, 품질을 떨어뜨리지 않고 토큰 비용을 5~10배 절감할 수 있었다는 집계도 있습니다.

실측 사례 중 하나가 웹 탐색 서비스인 BrowseComp입니다. 제3자 집계에 따르면, Fable 오케스트레이터 + Sonnet 워커 구성으로 Fable 단독 사용 대비 약 96%의 정확도를 46%의 비용으로 달성했다고 보고되었습니다. 비용을 문제당 기준으로 보면 다음과 같습니다.

정확도는 90.8%에서 86.8%로 약 4포인트 낮아지지만, 비용은 절반 이하입니다. "그 4포인트에 $22를 지불할 가치가 있는가"를 태스크 (Task)마다 판단할 수 있는 것이 이 분업의 장점입니다.

💡 구현 팁으로서, 오케스트레이터와 워커의

모델을 혼합하면 프롬프트 캐시 (Prompt Cache)가 작동하지 않습니다 (캐시는 모델 단위입니다). 메인 루프 (Main Loop)는 하나의 모델로 고정하고, 다른 모델의 작업은 서브 에이전트로 분리하면 캐시를 유지하면서 저렴한 모델을 사용할 수 있습니다.

분업을 더욱 세밀하게, 즉 한 번의 요청 (Request) 안에서 수행하는 것이 Advisor 툴 (Tool)입니다. 빠르고 저렴한 Executor (실행 역할)를 주인공으로 두고, 중요한 순간에만 고성능인 Advisor (조언 역할)에게 상담하게 합니다.

핵심은 방향성입니다. Advisor는 Executor 이상의 능력이 필요하므로, "저렴한 Sonnet 5가 Executor, 똑똑한 Fable 5가 Advisor"라는 조합이 됩니다. Executor가 대부분의 토큰을 생성하고, Advisor는 계획 상담 시에만 호출됩니다.

다음은 Advisor 툴의 선언 예시입니다 (설명을 위한 예시입니다).

response = client.beta.messages.create(
model="claude-sonnet-5", # Executor (저렴함·주역)
max_tokens=16000,
...

이 코드의 핵심 포인트는 세 가지입니다.

• 주역 (top-level의 model)은 저렴한 Sonnet 5입니다. 토큰의 대부분은 여기서 생성합니다.
• 상담역 (tool의 model)이 Fable 5입니다. 어려운 판단이 필요할 때만 내부적으로 호출됩니다.
• Advisor는 서버 측에서 동작하므로, tool_result를 직접 반환하는 루프는 필요하지 않습니다.

제3자 집계에 따르면, Sonnet 5 Executor + Fable 5 Advisor 구성으로 SWE-bench Pro에서 Fable 단독 성능의 약 92%를 63%의 가격으로 달성했다고 보고되었습니다. "9할의 성능을 6할의 가격으로"라는 비용 효율성은 하네스 (Harness)의 주인공을 어디에 두느냐에 따라 크게 달라짐을 보여줍니다.

Fable 5를 사용하는 상황에서도 output_config.effort를 통해 "생각하는 노력"을 조정하면 토큰을 절약할 수 있습니다. effort는 low / medium / high / xhigh / max의 5단계입니다.

다음 도표는 역할별 effort의 기준입니다.

이 도표의 핵심은 effort를 "역할에 맞춰 상하로 조절하는" 점입니다. 워커의 단순 작업까지 xhigh로 돌리면 저렴한 모델로 교체한 의미가 퇴색됩니다. 루틴 (Routine)한 처리는 low ~ medium으로 낮추고, 오케스트레이터의 계획이나 난제에 대해서만 high ~ xhigh로 높입니다. 이 조절만으로도 동일한 구성 내에서 불필요한 토큰을 줄일 수 있습니다.

또한 Fable 5에서는 일상적인 작업까지 높은 effort로 설정하면, 필요 이상으로 문맥을 수집하며 깊이 고민하는 경향이 있습니다. "태스크가 올바르게 완료되었음에도 시간이 너무 오래 걸린다"고 느껴질 때는, 우선 effort를 한 단계 낮춰보는 것이 간편한 해결책입니다.

토큰 자체를 줄이는 메커니즘 또한 비용 효율성과 직결됩니다. 에이전트가 길게 작동할수록 그 효과가 커집니다.

프롬프트 캐싱 (Prompt Caching): 안정적인 접두사(시스템 프롬프트, 고정된 도구 정의)를 맨 앞에 배치하면, 캐시 읽기 비용은 통상 입력 단가의 약 10% 수준으로 해결됩니다. 날짜나 UUID를 접두사에 섞으면 매번 캐시가 깨지므로, 변동 요소는 뒤쪽으로 배치해야 합니다. -
컨텍스트 편집 (Context Editing): 오래된 도구 결과나 사고 블록(thought blocks)을 삭제하여 이력을 가볍게 유지합니다(요약이 아닌 삭제). 긴 에이전트 루프에서 쌓인 불필요한 출력을 제거할 수 있습니다. -
Task Budgets (beta): 에이전트 루프 전체의 토큰 상한을 모델에게 전달하는 기능입니다. 모델은 카운트다운을 확인하며 우선순위를 정해 깔끔하게 작업을 마무리하려고 시도합니다. max_tokens (1회 응답의 강제 상한)와는 별개의 기능으로, 최소 20,000 토큰부터 설정할 수 있습니다.

다음은 Task Budget 지정 예시입니다 (설명을 위한 예시입니다).

with client.beta.messages.stream(
model="claude-fable-5",
max_tokens=128000,
...

이 코드의 핵심은 task_budget은 "모델에게 보여주는 예산"이고, max_tokens는 "강제적인 중단"이라는 차이점입니다. 예산을 미리 전달해 두면, Fable 5는 중간에 끊기는 것이 아니라 남은 토큰을 확인하며 스스로 페이스를 조절합니다.

Fable 5는 비동기(asynchronous)로 작동하는 서브 에이전트(sub-agent)를 다루는 데 능숙합니다. 지휘관이 대기 상태에 빠지지 않고 여러 워커(worker)를 병렬로 실행하며, 필요에 따라 중간에 상호작용할 수 있습니다.

다음 그림은 동기(synchronous, 하나씩 대기)와 비동기(asynchronous, 병렬 실행)의 차이를 보여줍니다.

이 그림의 핵심은 비동기 방식에서는 지휘관이 가장 느린 워커에게 발목을 잡히지 않는다는 점입니다. 제3자 집계에 따르면, 멀티 에이전트(multi-agent) 구성이 단일 에이전트를 파레토 지배(Pareto dominance, 정확도와 레이턴시가 동시에 개선됨)했다고 보고되었습니다. 에이전트를 3체 / 5체 / 10체로 늘리면 단일 에이전트 대비 2.2배 / 2.7배 / 2.7배의 가속화를 얻을 수 있는 반면, 토큰 비용은 증가합니다.

코딩 분야에서도 멀티 에이전트 버전인 ProgramBench에서 5체 팀이 단일 에이전트보다 7.9점 높았고, 숨겨진 테스트 60% 통과를 약 3.2배 빠르게 달성했다는 결과가 있습니다. 각 에이전트는 자신만의 Git 체크아웃(checkout) 환경에서 작업하며, 코드는 Git을 통해 공유하는 형태입니다.

이는 "속도를 위해 토큰을 추가할 것인가"에 대한 트레이드오프(trade-off)이므로, 비용을 최우선으로 한다면 병렬 수를 줄이고, 레이턴시를 최우선으로 한다면 늘리는 판단이 필요합니다.

비용 효율에 대해 이야기하기에 앞서, Fable 5가 "애초에 얼마나 강력한지"도 살펴보겠습니다. 코딩 관련 벤치마크에서 타 모델과 비교해 보겠습니다.

반복해서 말씀드리지만, 아래 수치는 벤더의 공칭값과 제3자 집계 데이터를 모은 것으로, 동일한 하네스(harness)와 동일한 날짜에 재실행한 결과가 아닙니다. 특히 SWE-bench Pro의 Fable 5 점수는 Anthropic 자체 스캐폴딩(scaffolding)에 의한 공칭값이므로, 독립 평가자들 사이에서 수치가 갈리고 있다(논쟁이 있다)는 점에 주의하십시오.

(출처: Anthropic 공식 및 각사 공칭값을 바탕으로 한 제3자 집계 [morphllm / Vellum / claude5.ai] 등. 동일 환경에서의 재실행 값이 아닙니다.)

이 표에서 알 수 있는 점은 Fable 5가 확실히 최상위 수치를 기록하고 있다는 점입니다. SWE-bench Verified는 95.0%라는 독립 확인된 집계도 있어, 실무적인 코드 수정에서는 독보적인 우위를 점하고 있습니다. 다만 SWE-bench Pro의 80.3%는 공칭값(nominal value)에 대한 논쟁이 있으므로, 실제 운용에서는 Opus 4.8(69.2)로도 충분히 강력하다는 점을 유념해야 합니다.

여기서 비용의 관점이 중요해집니다. 벤치마크의 절대값만 보면 Fable 5가 매력적이지만, "그 차이가 자신의 태스크에서 $10/$50를 지불할 가치가 있는가"를 매번 질문해야 합니다. 많은 정형 작업에서는 Sonnet 5나 Opus 4.8로도 품질이 충분하며, 차액이 더 크다는 것이 본 기사의 입장입니다.

모델별 가격을 다시 정리합니다.

Fable 5의 출력 $50는 Haiku 4.5의 출력 $5와 정확히 10배 차이입니다. 즉, 출력 토큰을 대량으로 생성하는 작업(코드 전체 생성, 긴 문장 정형화 등)일수록 저렴한 모델에게 맡겼을 때의 이점이 커집니다.

비용 효율 하네스(Cost-efficiency harness)의 효과를 앞서 살펴본 BrowseComp의 실측 데이터로 다시 한번 확인해 보겠습니다.

숫자가 보여주는 것은 하네스를 어떻게 구성하느냐에 따라 "성능의 90% 내외를 절반에서 60% 가격으로" 낼 수 있다는 것입니다. 프론티어 지능(Frontier intelligence)을 전면에 내세우는 것이 아니라, 요충지에 배치하는 것입니다. 이 한 수로 비용의 단위가 달라집니다.

마지막으로 Fable 5 특유의 운용상 주의사항을 한 가지 언급하겠습니다. Fable 5는 안전 분류기(safety classifier)를 가지고 있어, 연구 바이오나 고위험 사이버 영역에 가까운 요청을 거부할 수 있습니다. 거부는 에러가 아니라, stop_reason: "refusal"을 포함한 HTTP 200으로 반환됩니다.

폴백(Fallback)은 옵트인(opt-in) 방식입니다. 아무 조치도 취하지 않으면 거부된 상태 그대로 멈춥니다. 신규 코드에서는 서버 측의 fallbacks 파라미터(beta server-side-fallback-2026-06-01, 폴백 대상 claude-opus-4-8)를 기본값으로 설정해 두는 것을 권장합니다. 거부된 요청이 동일한 호출 내에서 Opus 4.8로 재실행되며, 과금 또한 적절히 전환됩니다.

response = client.beta.messages.create(
model="claude-fable-5",
max_tokens=16000,
...

이 코드의 핵심은 출력 전의 거부는 과금되지 않으며, 폴백된 부분은 Opus 4.8의 단가로 과금된다는 점입니다. 안전한 업무가 오탐(false positive)으로 인해 중단되는 것을 방지하면서도 비용을 예측 가능한 형태로 관리할 수 있습니다. response.content[0]을 바로 읽으면 거부 시 인덱스 에러(index error)로 인해 프로그램이 중단될 수 있으므로, stop_reason을 먼저 체크하는 로직을 넣어두어야 합니다.

이 기사에서 가장 중요한 점은 "Fable 5의 지능은 판단이 어려운 곳에만 배치한다"는 한 가지 원칙입니다. 모든 태스크를 $10/$50 모델로 처리하는 것이 아니라, 계획과 통합은 Fable 5가, 실제 작업은 저렴한 모델이 담당하는 분업 체계로 전환하는 것만으로도 많은 워크로드의 품질을 유지하며 비용을 절반 이하로 줄일 수 있습니다.

실행 순서로는 먼저 오케스트레이터(Orchestrator)/워커(Worker) 분업을 시도하는 것이 효과가 큽니다. 그다음, 1개 요청 내에서 세밀하게 제어하고 싶다면 Advisor 도구를 사용하십시오. 여기에 노력(effort)의 차등 배분, 프롬프트 캐싱(Prompt caching), 컨텍스트 편집(Context editing), 태스크 예산(Task Budget)을 결합하면 비용을 더욱 절감할 수 있습니다. 속도가 필요한 국면에서는 비동기 서브 에이전트(Asynchronous sub-agent)를 통해 토큰을 대가로 레이턴시(Latency)를 구매하십시오.

마지막으로 주의사항입니다. 본 기사의 벤치마크(Benchmark)와 비용 실측값은 제3자 집계이며, SWE-bench Pro와 같이 수치가 갈리는 경우도 있습니다. 최종적으로는 자신의 태스크(Task)에서 Fable 5와 저렴한 모델을 실제로 구동하여, 정확도·토큰·레이턴시(Latency)를 측정한 후 구성을 결정하는 것이 가장 확실합니다. 우선 하나의 워크플로우(Workflow)에서 "Fable 단독"과 "오케스트레이터 구성(Orchestrator configuration)"을 나란히 놓고 측정해 보시기 바랍니다.