Claude Fable 5 토큰 비용을 줄이는 가장 빠른 방법은 더 저렴한 모델로도 충분히 잘 처리할 수 있는 작업에 Fable을 계속 실행하지 않는 것입니다. 백만 토큰당 $10/$50인 Fable은 Sonnet 5보다 5배 비싸지만, 제 테스트에서는 두 모델 모두 같은 작업을 정확히 수행했습니다.
Fable 5의 지출이 실제로 어디에 쓰이는지
최적화하기 전에, 비용이 어디에서 새는지 살펴보세요. 일반적인 agentic 요청에서는 입력 토큰이 출력 토큰을 압도합니다. 단일 쿼리에는 80,000–140,000개의 입력 토큰(시스템 프롬프트, 도구 정의, 대화 기록, 파일 컨텍스트)이 포함될 수 있는 반면, 출력은 1,000–3,000개 토큰에 불과합니다. 출력은 토큰당 가격이 5배 더 비싸지만, 입력의 절대적인 양이 더 커서 보통 더 큰 비용 항목이 됩니다. 바로 그렇기 때문에 더 짧은 답변보다 캐싱과 컨텍스트 관리가 더 중요합니다.
아래의 모든 결정을 이끄는 가격은 다음과 같습니다:
| 모델 | 입력 ($/M) | 출력 ($/M) | 캐시된 입력 읽기 ($/M) |
|---|---|---|---|
| Claude Fable 5 | $10 | $50 | ~$1 (≈90% 할인) |
| Claude Opus 4.8 | $5 | $25 | ~$0.50 |
| Claude Sonnet 5 | $2 | $10 | ~$0.20 |
| Claude Haiku 4.5 | $1 | $5 | ~$0.10 |
프롬프트 캐싱은 캐시된 입력을 기본 요금의 대략 10분의 1 수준으로 낮추지만, 캐시에 쓰기에는 추가 요금이 부과됩니다($12.50/M for the 5-minute cache, $20/M for the 1-hour cache). 요금은 2026년 7월 17일 Anthropic의 공개 요금을 기준으로 검증되었습니다. Sonnet 5의 $2/$10은 2026년 8월 31일까지의 출시 기념 요금입니다.
우리는 Fable 5, Opus 4.8, 그리고 Sonnet 5에서 동일한 작업을 실행했습니다
이론은 — "가능할 때는 더 저렴한 모델을 사용하라" — 라고 말하기는 쉽지만, 수치 없이는 신뢰하기 어렵습니다. 그래서 저는 통제된 테스트를 실행했습니다. 세 모델 모두에 같은 프롬프트를 보냈습니다: *빈 입력과 정렬되지 않은 입력을 처리하는 Python merge_intervals 함수를 작성하고, assert 기반 단위 테스트를 세 개 포함하라.* 그런 다음 각 답변을 실행해 테스트가 실제로 통과하는지 확인했습니다.
세 가지 모두 모든 테스트를 통과한 올바른 코드를 생성했습니다. 차이는 전적으로 비용과 속도에 있었습니다.
| 모델 | 출력 토큰 | 지연 시간 | 호출당 비용 | 1,000회 호출당 비용 |
|---|---|---|---|---|
| Fable 5 | 265 | 12.3 s | $0.0190 | $19.01 |
| Opus 4.8 | 236 | 6.4 s | $0.0088 | $8.78 |
| Sonnet 5 | 267 | 3.9 s | $0.0038 | $3.82 |
동일한 입력(576 토큰), 거의 동일한 출력 길이, 동일한 정확도 — 그리고 가격은 5배 차이. Sonnet은 또한 세 배 더 빠르게 답했습니다.
이것은 작고 독립적인 작업이며, 벤치마크가 아닙니다 — 복잡한 추론 문제가 바로 Fable 5가 그 값을 하는 영역이고, 그 격차는 줄어들거나 역전될 수 있습니다. 하지만 핵심은 그대로입니다: 대부분의 세션을 채우는 일상적인 작업에서는 동일한 결과에 5배를 지불하고 있을 수 있습니다. 지연 시간 수치는 제3자 API 엔드포인트에서 가져온 것이므로, 공식 SLA라기보다 대략적인 참고치로 보아야 합니다.
레버 1: 모델을 작업에 맞추기
이것은 가장 높은 ROI를 제공하는 변경이며, 위의 테스트가 그 이유입니다. 작업 유형별로 라우팅하세요: 깊은 다단계 추론, 어려운 리팩터링, 모호한 사양에는 Fable 5를 유지하고; 보일러플레이트, 포맷팅, 간단한 수정, 대량의 단순 호출은 Sonnet 5 또는 Haiku 4.5로 보내세요. 확신이 없을 때는 더 저렴한 모델로 시작하고 결과가 틀렸을 때만 상위 모델로 전환하세요 — 저렴한 호출이 실패해도 Fable 호출의 일부에 불과한 비용만 듭니다.
실무자들이 계속 도달하는 한 가지 패턴: Fable 5가 계획하게 하고, 더 저렴한 모델이 실행하게 하라. Fable은 아키텍처를 작성하거나 작업을 단계로 나누고, Sonnet 5나 Haiku 4.5가 대부분의 타이핑을 맡는다. Cline 코딩 에이전트 뒤에 있는 팀은 Fable에 하루 동안 2,000달러 이상을 썼다고 보고했으며, 이후 더 저렴한 모델에 적대적 검토 루프를 결합하자 비슷한 — 때로는 더 나은 — 결과를 훨씬 더 낮은 비용으로 얻을 수 있음을 발견했다.
Claude Code에서 알아두면 좋은 실용적인 제약이 하나 있습니다. 채팅 중 세션 도중에는 활성 모델을 중간에 바꿀 수 없습니다. 우회 방법은 이를 평이한 언어로 요청하는 것입니다. 즉, Claude에게 작업은 직접 계획하되 구현은 더 저렴한 모델에 맡기라고 하면, 실행을 수행할 Sonnet 5 서브에이전트를 띄우고 비싼 모델은 계속 계획 역할에 머뭅니다. 이렇게 하면 가장 많은 토큰을 소모하는 작업 부분에서 Fable 수준의 작업 분해와 Sonnet 수준의 토큰당 비용을 얻을 수 있습니다.
단일 모델 내에서 effort setting은 더 세분화된 동일한 조절 수단이며, 제가 가장 먼저 사용하는 설정입니다. 일상적인 작업에는 low effort를 기본으로 사용하고, 결과가 실제로 잘못 나올 때만 한 단계 올리세요 — low는 Fable이 답변하기 전에 소모했을 reasoning tokens를 건너뛰며, 쉬운 작업에서는 품질 저하 없이 순수한 절감 효과만 제공합니다. 추가 reasoning이 답을 바꾸는 문제에는 high 또는 max를 사용하세요. Fable 5의 high 대 max effort tiers에 대한 우리의 분석은 그 경계가 어디에 있는지 보여주며, Sonnet 5 vs Fable 5는 어떤 작업을 안전하게 한 단계 낮출 수 있는지 다룹니다.
레버 2: 프롬프트 캐시를 보호하세요
입력이 토큰 수를 좌우하므로, 약 90%의 캐시 할인은 두 번째로 큰 레버입니다. 단, 캐시는 호출 간에 접두사가 바이트 단위로 동일하게 유지될 때만 도움이 됩니다. 시스템 프롬프트에서 앞부분의 토큰 하나를 바꾸거나 도구 정의의 순서를 바꾸면, 그 뒤의 모든 내용은 캐시 미스로 간주되어 정가로 청구됩니다.
캐시를 그대로 유지하려면:
- 안정적인 접두사를 고정하세요. 시스템 프롬프트와 도구 정의를 먼저 배치하고 세션 중간에 변경하지 마세요. 새 컨텍스트는 끝에 추가하세요.
- 요청 간 도구 순서를 섞지 마세요 — 도구 목록을 동적으로 다시 구성하는 에이전트는 캐시를 조용히 무효화합니다.
- 캐시 창 안에서 일괄 재사용하세요. 5분 캐시는 쓰기 비용이 저렴합니다. 관련 호출을 묶어서 만료되기 전에 도달하도록 하세요.
손익분기점은 빠릅니다: 5분 캐시 쓰기 비용은 일반 입력 토큰의 1.25배이며, 각 캐시된 읽기는 0.9배를 절감하므로, 같은 접두어를 대략 두 번 재사용하면 캐시 비용을 회수합니다 — 매 턴마다 전체 대화를 다시 보내는 어떤 에이전트에게도 이는 사소한 일이며, 이때 온전한 캐시는 반복되는 부분에서 $10/M을 지불하느냐 $1/M을 지불하느냐의 차이를 만듭니다.
레버 3: 컨텍스트를 덜 보내기
보내지 않는 모든 토큰은 어떤 요금제에서든 비용을 지불하지 않아도 되는 토큰입니다. 여기서의 성과는 화려하진 않지만 누적됩니다:
- 관련 없는 작업 사이에서는 지우세요. Claude Code에서
/clear를 사용하면 새로 시작되므로, 오래된 기록이 이후의 모든 메시지에 계속 따라붙지 않습니다. - 긴 세션은 압축하세요.
/compact는 지금까지의 대화를 요약합니다. "코드 샘플과 API 사용에 집중해" 같은 지침을 추가하면 무엇을 보존할지 알려줄 수 있습니다. - 탐색보다 문서를 제공하세요. 밀도 높은 사전 작성된 skill이나 버전이 고정된 문서 발췌본은, 에이전트가 검색하고 읽으며 같은 지식에 도달하게 두는 것보다 훨씬 비용이 적게 듭니다.
- PDF보다 Markdown을 선호하세요. PDF에는 모델에 필요하지 않은 레이아웃 토큰이 포함됩니다. 같은 내용의 일반 Markdown은 훨씬 더 간결합니다.
이들 중 어느 것도 요금을 변경하지는 않지만, 100k 토큰 컨텍스트에서는 매번 호출할 때마다 수천 개의 토큰을 줄여줍니다.
지렛대 4: 토큰당 요금 자체를 낮추기
위의 레버들은 사용한 토큰 수와 적용되는 티어를 줄여줍니다. 마지막 것은 토큰당 가격을 줄여줍니다. Anthropic의 자체 API에는 Fable 5에 대한 배치 또는 비동기 할인 티어가 없으므로, 표시된 요금이 실제 지불하는 요금입니다.
한 가지 옵션은 Claude 액세스를 정가보다 낮은 마크업으로 재판매하는 API aggregator입니다. 예를 들어 AIReiter는 Anthropic-API-compatible하며 Claude 모델을 공식 요금의 약 20% 수준으로 책정합니다. 즉, Fable 5는 백만 토큰당 $10/$50 대신 거의 $2/$10 수준이 됩니다. 다만 이러한 선택에는 모든 리셀러와 마찬가지로 트레이드오프가 있습니다. Anthropic을 직접 신뢰하는 것이 아니라 제3자의 routing과 uptime을 신뢰해야 하므로, latency-critical production paths보다는 대량의 비용 민감한 workloads에 더 적합합니다. 어떤 경로를 선택하든 rate는 다른 모든 것에 곱해지는 배수이므로, 한 번 정해 두고 매일 조정하는 token-volume levers에 집중하는 것이 좋습니다.
실제로 성과를 바꾸는 요인은 무엇인가
딱 한 가지 일만 한다면, Lever 1을 하세요 — 작업을 올바른 모델로 라우팅하는 것이 테스트가 측정한 차이이며, 그 외에는 비슷하게 따라올 것이 없습니다. 솔직한 순위는 다음과 같습니다:
1. 모델을 작업에 맞추기 — 잘못 배정된 작업에서 최대 약 5배. 가장 크고 오래 지속되는 효과. 2. 프롬프트 캐시 보호하기 — 반복 입력에서 최대 90% 절감, 이는 에이전트 루프에서 토큰의 대부분을 차지합니다. 3. 전달하는 컨텍스트 줄이기 — 토큰 사용량을 꾸준히 20–50% 절감하며, 모든 호출에 걸쳐 누적됩니다. 4. 토큰당 요율 낮추기 — 고정 배수; 한 번 설정하면 모든 항목에 혜택이 적용됩니다.
유혹적인 "exploits" — 프롬프트를 이미지로 인코딩하거나 커스텀 토크나이저를 사용하는 트릭들 — 은 다음 모델 업데이트에서 쉽게 깨지는 경향이 있습니다. 여기서의 네 가지 레버는 해킹이 아니라 습관입니다: 실제로 가격이 어떻게 구성되는지와 맞아떨어지기 때문에 계속 작동합니다.
자주 묻는 질문
Claude에서 토큰 비용을 줄이려면 어떻게 해야 하나요?
일상적인 작업에는 low로 노력 수준을 설정하고, 더 단순한 작업은 Sonnet 5 또는 Haiku 4.5로 라우팅하며, 캐싱이 적용되도록 프롬프트 접두어를 바이트 수준에서 안정적으로 유지하고, 작업 사이에는 컨텍스트를 지우거나 압축하세요. 가장 큰 절감 효과는 모델 선택과 노력 수준에서 나옵니다.
Fable 5는 토큰당 얼마인가요?
입력 토큰 100만 개당 $10, 출력 100만 개당 $50 — Opus 4.8($5/$25)보다 2배, Sonnet 5($2/$10, 2026년 8월 31일까지의 소개 가격)보다 5배입니다. 프롬프트 캐싱을 사용하면 캐시된 입력 읽기 비용이 100만 개당 약 $1로 낮아집니다.
왜 Fable 5 토큰이 그렇게 빨리 소진되나요?
일반적으로 과도하게 큰 컨텍스트(긴 이력이나 매번 모든 호출에 첨부되는 큰 파일), 매 턴마다 전체 컨텍스트를 다시 보내는 재시도 루프, 또는 더 저렴한 모델로 처리할 수 있는 작업을 Fable로 실행하는 경우입니다. 컨텍스트를 줄이고 작업을 적절히 라우팅하면 대부분 해결됩니다.
Fable 5에 프롬프트 캐싱은 가치가 있나요?
예, 큰 고정 프리픽스를 재사용할 때마다 캐시된 입력 비용이 기본 요금의 약 10%로 줄어듭니다. 이는 프리픽스가 호출 사이에 바이트 단위로 동일하게 유지될 때만 효과가 있으므로, 시스템 프롬프트와 도구 정의를 고정하세요.
노력 설정을 낮추면 품질이 저하되나요?
간단한 작업에서는 드물게 — low 또는 medium 노력은 작업에 필요하지 않은 추론 토큰을 건너뜁니다. 추가 추론이 답을 바꾸는 진짜 어려운 문제에는 high 또는 max를 유지하세요.
