Claude Fable 5 캐싱: 계약은 그대로, 비용은 Opus 4.6의 2.9배

이제 Synthorai gateway에서 claude-fable-5를 사용할 수 있습니다. Claude 계열 모델에 캐싱을 적용하고 있다면 캐싱과 TTL 계약은 그대로 이어집니다. cache_control marker, 5분과 1시간 TTL, 쓰기 할증, 높은 읽기 할인율이 모두 같습니다. 캐싱 코드는 문자열 하나만 바꾸면 됩니다.

예산에서 주의할 부분은 캐시 동작 방식이 아니라 비용입니다. Fable 5의 token 가격은 Opus의 2배이고, 같은 영어 텍스트도 Opus 4.6보다 약 45% 많은 token으로 계산됩니다. Opus 4.8과 같은 post-4.6 tokenizer를 사용하기 때문입니다. 이 두 배율은 곱해집니다. 이 글에서는 관련 수치를 모두 측정했습니다.

마이그레이션 전에 확인해야 할 비캐시 제약도 하나 있습니다. Fable 5는 zero data retention으로 실행할 수 없습니다. 제공되는 모든 cloud에서 30일간의 데이터 보존이 필수입니다.

TL;DR

• Claude Fable 5는 Anthropic의 캐싱 계약을 그대로 유지합니다. cache_control marker, 5분과 1시간 TTL, 약 1.25x/2x의 쓰기 할증이 같고, warm read는 no-cache 가격의 약 6%로 측정됐습니다.
• 같은 텍스트가 Fable 5와 Opus 4.8에서는 9,619 token, Opus 4.6에서는 6,614 token으로 계산됩니다. 45% 더 많습니다.
• Fable 5의 정가는 input $10/M, output $50/M으로 Opus 등급의 2배입니다.
• 따라서 같은 prompt의 비용은 Opus 4.6의 2.9배입니다. 2026-06-10 측정 기준으로 1.45배의 token 수에 2.0배의 가격이 곱해집니다.

아래의 모든 수치는 2026-06-10에 https://synthorai.io/의 Anthropic-native /v1/messages를 대상으로 측정했습니다. 안정적인 약 6.6–9.6K-token 영어 system prompt를 사용하고, max_tokens를 작게 설정한 뒤 한 번씩 순차 실행했습니다. 비용은 gateway의 usage.cost field에서 읽었습니다. 다른 환경에도 적용할 수 있는 값은 token 수, 쓰기 할증, 읽기 할인, 모델 간 비용 같은 비율입니다. 절대 비용은 prompt 크기에 따라 달라집니다. 수치를 인용하기 전에 자체 prompt로 다시 측정하세요.

사용 가능 여부

import os
from anthropic import Anthropic

anth = Anthropic(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/",   # SDK appends /v1/messages
)

msg = anth.messages.create(
    model="claude-fable-5",             # the only line that changes
    max_tokens=512,
    system=[
        {"type": "text", "text": SYSTEM_PROMPT,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": question}],
)
print(msg.usage)   # input_tokens, cache_creation_input_tokens, cache_read_input_tokens, cost

claude-opus-4-6을 claude-fable-5로 바꾸면 됩니다. 캐싱 경로의 다른 부분은 수정할 필요가 없습니다. Fable 5는 1M-token context window를 지원하는 Anthropic-native 모델입니다. 동작상 주의할 점이 하나 있습니다. reasoning model이므로 기본적으로 thinking token을 생성합니다. 단순히 “reply OK”라고 요청한 테스트에서도 output_tokens_details.thinking_tokens > 0이 반환됐지만, Opus 4.6/4.8은 0을 반환했습니다. 이에 맞춰 output token 예산을 잡아야 합니다. cache_control의 동작 방식은 캐싱 튜토리얼에서 다룹니다. 캐시가 필요한 이유와 구조는 시리즈 1편에서 설명합니다.

핵심: Fable 5는 새 tokenizer를 사용한다

Opus 계열의 token 수는 4.7 세대에서 크게 늘었습니다. 4.6에서 약 6.6K token이던 같은 영어 텍스트가 4.8에서는 약 9.6K token으로 계산됩니다. Fable 5도 새 tokenizer 쪽에 속합니다. 같은 텍스트를 입력하면 Opus 4.8과 정확히 같은 token 수가 나옵니다.

같은 system prompt가 Fable 5에서는 Opus 4.6보다 약 45% 많은 token으로 계산됩니다. 9,619 / 6,614 = 1.45입니다. 마이그레이션 전에 가장 먼저 파악해야 할 수치입니다. 비용, 캐시 적용이 가능한 최소 1,024 token, 호출당 예산이 모두 token을 기준으로 계산되기 때문입니다.

측정 결과를 그대로 설명한 것입니다. 같은 텍스트의 token 수는 Fable 5와 Opus 4.8에서 같았고, Opus 4.6보다 약 45% 많았습니다. 이 결과는 4.7 세대에 도입된 tokenizer/vocabulary 변경과 가장 잘 맞습니다. 4.6 이하에서 이전한다면 다시 측정하세요. 4.7/4.8에서 이전한다면 같은 수준을 예상하면 됩니다.

캐싱 동작: 계약은 바뀌지 않았다

각 모델에서 no-cache, cold-write, warm-read 순서로 같은 테스트를 실행했습니다. 할인 구조는 처음부터 끝까지 같습니다. Fable 5는 cache_control을 지원하며, 동일한 usage field인 cache_creation_input_tokens, cache_read_input_tokens, ephemeral_5m / ephemeral_1h bucket을 반환합니다.

세 모델 모두 다음 두 가지가 같습니다.

• 쓰기 할증은 5m에서 약 1.25x, 1h에서 약 2x입니다. 최초 cold call로 5분짜리 entry를 만들 때는 no-cache 가격의 약 1.25x, 1시간짜리 entry는 약 2x가 듭니다. 한 번만 hit가 발생해도 손익분기점을 넘습니다.
• 읽기 할인율은 약 90% 이상입니다. Fable 5의 warm cache read는 no-cache 호출 비용의 약 6%였습니다. 약 94% 할인으로, Anthropic이 문서에 명시한 cached-read 비용 구조인 약 90% 할인과 비슷하거나 조금 더 좋습니다. TTL과 관계없이 읽기 비용은 크게 할인됩니다.

비율은 모든 모델에서 거의 같습니다. Opus 4.7에서 4.8로 바뀌었을 때처럼, Fable 5의 더 높은 절대 비용은 캐시 비용 구조가 아니라 가격과 token 수에서 발생합니다. 다음 절에서 자세히 다룹니다.

TTL 동작: 두 시간 구간 모두 지원

Fable 5는 다른 Claude 모델과 마찬가지로 두 가지 TTL을 지원합니다. 기본값은 sliding 방식의 5분이고, 선택적으로 1시간을 지정할 수 있습니다. 호출마다 고유한 prefix를 사용해 각 TTL을 따로 테스트했습니다. 이전 entry가 결과에 영향을 주지 않도록 한 뒤 usage object에서 올바른 bucket인 cache_creation.ephemeral_5m_input_tokens 또는 ephemeral_1h_input_tokens가 보고되는지 확인했습니다.

# 1-hour TTL — same marker syntax on Fable 5 as on the Opus line
"cache_control": {"type": "ephemeral", "ttl": "1h"}

1시간 쓰기는 no-cache의 약 2x로, 5분 쓰기의 약 1.25x보다 비쌉니다. 읽기는 TTL과 관계없이 큰 폭으로 할인됩니다. Opus 4.6/4.8과 같습니다. Opus에서 실시간 chat에는 5m, 사람이 중간에 개입해 대기 시간이 생기는 agent에는 1h를 사용했다면 Fable 5에서도 그대로 유지하면 됩니다.

비용 구조: 2x 가격 x 1.45x token

Fable 5의 실질적인 차이는 비용입니다. 비용을 높이는 요인이 두 가지이고, 서로 곱해집니다.

1. 정가는 Opus 등급의 2배입니다.

2. 같은 텍스트도 4.6보다 token이 약 45% 많습니다. 앞에서 설명한 tokenizer 변경 때문입니다.

두 값을 곱하면 같은 영어 prompt의 비용이 크게 늘어납니다. 각 모델에 같은 system prompt를 한 번씩 실행하고 gateway의 usage.cost로 측정했습니다.

같은 tokenizer를 사용하는 Opus 4.8과 비교하면 Fable 5는 정확히 2x입니다. 가격 차이만 반영됩니다. Opus 4.6과 비교하면 tokenizer 변경과 가격 인상이 겹쳐 같은 prompt의 비용이 약 2.9x가 됩니다. 캐시 할인율은 같지만, 할인이 적용되는 절대 기준 비용이 4.6보다 약 2.9x 큽니다. 호출당 예산을 4.6 기준으로 잡았다면 다시 계산해야 합니다.

실무적으로는 캐시 적용이 가능한 최소 1,024 token 기준도 다시 확인해야 합니다. Anthropic은 일정 크기 이상의 prefix만 캐시합니다. 4.6에서 기존 tokenizer 기준으로 이 하한선 바로 아래에 있던 prompt가 Fable 5에서는 약 45% 많은 token으로 계산되어 기준을 넘을 수 있습니다. 기존 token 수에 맞춘 크기 추정치는 반대로 어긋날 수도 있습니다. 실제 tokenizer와 다를 수 있는 local tokenizer로 추정하지 말고, live response의 cache_creation_input_tokens / cache_read_input_tokens를 항상 확인하세요.

마이그레이션 체크리스트, Opus → Fable 5

• ✅ 캐싱 코드는 그대로 사용할 수 있습니다. cache_control marker, 최대 4개인 breakpoint 수, ttl: "1h", usage field 이름이 모두 같습니다.
• ✅ TTL 선택도 그대로 유지할 수 있습니다. 실시간/session workload에는 5m, 호출 간 간격이 길거나 중간에 대기하는 agent에는 1h를 사용하면 됩니다.
• ✅ 할인 구조도 같습니다. 읽기는 약 90% 이상 할인되며, 쓰기는 5m에서 약 1.25x, 1h에서 약 2x입니다.
• ⚠️ 절대 비용 기준으로 예산을 다시 잡아야 합니다. Fable 5는 token당 비용이 Opus의 약 2x이고, 같은 prompt의 비용은 Opus 4.6의 약 2.9x입니다. 할인율은 같지만 할인이 적용되는 기준 비용은 다릅니다.
• ⚠️ 4.6 이하에서 이전한다면 token 수를 다시 측정하세요. 같은 텍스트에서 약 45% 증가할 수 있습니다. 4.7/4.8에서 이전한다면 비슷한 수준을 예상하면 됩니다.
• ⚠️ 기본 thinking token을 비용에 반영하세요. Fable 5는 기본적으로 reasoning token을 생성하며, output 요금인 $50/M이 적용됩니다. 필요하지 않다면 thinking을 제한하거나 비활성화하세요.

결론

이미 Claude에서 캐싱을 사용 중인 팀이라면 claude-fable-5는 통합하기 쉽습니다. 캐싱과 TTL 관련 interface가 모두 그대로이므로 새로 익히거나 코드를 다시 작성할 필요가 없습니다. 하지만 Opus 4.6에서 예산까지 그대로 옮길 수는 없습니다. token 가격이 2x이고 tokenizer 변경으로 token 수가 약 45% 늘어 같은 prompt의 비용이 약 2.9x가 됩니다. live usage object로 수치를 확인하고, 기본 thinking token이 필요한지 결정한 뒤 새 token 수에 맞춰 cache breakpoint를 잡으세요.

prompt 구조, hit rate 디버깅, TTL을 고려한 패턴까지 포함한 전체 캐싱 방법은 prompt caching 전체 가이드, 시리즈 첫 글인 KV Cache와 TTL의 동작 방식, 실행 가능한 Python 튜토리얼에서 확인할 수 있습니다.

FAQ

Fable 5를 사용하려면 cache_control 코드를 바꿔야 하나요? 아니요. marker 문법, breakpoint 제한, TTL 옵션이 Opus 계열과 같습니다. model field만 바꾸면 되고 캐싱 경로의 다른 부분은 수정할 필요가 없습니다.

Fable 5에서 캐시 읽기 할인율이 바뀌었나요? 아니요. warm read 비용은 no-cache input 가격의 한 자릿수 비율로, 약 90% 이상 할인됩니다. Fable 5에서는 약 94% 할인으로 측정됐으며, Anthropic이 문서에 명시한 cached-read 비용 구조와 일치합니다.

Fable 5는 1시간 TTL을 지원하나요? 네. {"type": "ephemeral", "ttl": "1h"}는 Opus와 정확히 같은 방식으로 동작합니다. 1시간 쓰기 비용은 no-cache의 약 2x, 5분 쓰기는 약 1.25x입니다. 두 경우 모두 읽기 비용은 크게 할인됩니다.

같은 prompt인데 Fable 5가 Opus 4.6보다 훨씬 비싼 이유는 무엇인가요? 두 배율이 곱해지기 때문입니다. Fable 5의 token당 정가는 2x이고, 같은 영어 텍스트도 약 45% 많은 token으로 계산됩니다. post-4.6 tokenizer를 사용하기 때문입니다. 두 요인을 합치면 같은 prompt의 비용은 약 2.9x가 됩니다. 캐시 할인율은 바뀌지 않았습니다.

Fable 5를 Opus 4.8 대신 바로 사용할 수 있나요? 캐싱/TTL interface와 token 수 기준으로는 가능합니다. token 수가 같으므로 차이는 2x 가격과 Fable 5의 기본 thinking token입니다. 직접 실행하지 않은 성능 benchmark는 제공하지 않습니다. 품질과 reasoning 관련 내용은 Anthropic의 model card를 참고하세요.

검증: 모든 token 수, 비용, 쓰기 할증, 읽기 할인 수치는 2026-06-10에 공식 anthropic SDK를 사용해 https://synthorai.io/에서 측정했습니다. single tenant 환경에서 한 번씩 순차 실행했습니다. 비용은 gateway의 usage.cost field에서 읽었으며, 모델 간 비율과 할증/할인 비율은 해당 측정 비용으로 계산했습니다. 계정별 promotion과 무관한 수치입니다. 할인/할증 비율은 Anthropic Prompt Caching 문서와 대조했습니다. 테스트에서 warm-read latency인 TTFT는 network jitter의 영향이 커 신뢰하기 어려워 제외했습니다. 실제 수치는 prompt, region, load에 따라 달라질 수 있습니다.

← 블로그로 돌아가기