Claude 구독 한도 대비 프롬프트 캐싱 비용 실측 결과
I measured what prompt caching actually costs against Claude subscription limits
핵심 요약
Claude 구독 모델의 프롬프트 캐싱 비용을 실측하여 API 가격과 실제 구독 한도 차이를 분석함.
- 캐싱 비용 분석 — 구독 모델의 1시간 캐시 쓰기 비용이 API 정가(2배)보다 저렴한 1.2배 수준임을 확인함.
- 모델별 차이 — Opus와 Fable 모델 간 캐싱 효율과 구독 한도 적용 방식이 다름을 밝힘.
- 실측 방법론 — Claude Code CLI와 로컬 프록시를 사용하여 응답 헤더의 사용량 데이터를 정밀하게 측정함.
- 실무적 시사점 — 캐싱 비용이 낮아짐에 따라 세션을 유지하는 것이 콜드 스타트보다 경제적일 수 있음.
Anthropic은 API 사용량에 대한 토큰당 정확한 가격을 공개하고 있어. 기본 입력, 5분 캐시 쓰기 1.25배, 1시간 캐시 쓰기 2배, 캐시 읽기 0.1배, 출력 5배로 딱 정해져 있지. 이 수치들은 문서화도 잘 되어 있고 계산하기도 쉬워.
구독 플랜은 좀 다르게 돌아가. 사용량은 5시간 단위의 롤링 윈도우와 주간 윈도우를 기준으로 측정되는데, 이 측정 단위가 뭔지는 어디에도 안 나와 있어. 캐시된 토큰이 플랜 사용량 내에서 캐시되지 않은 토큰과 비교했을 때 어느 정도 비중을 차지하는지 명시한 공식 페이지도 없지. 프롬프트 캐싱 문서에는 API 배율만 설명되어 있고, 플랜 페이지에는 그냥 제한이 있다는 말과 고정된 메시지 개수는 없다는 말뿐이야.
구독 상태에서 캐시 사용을 최적화하려는 사람한테는 이 정보의 공백이 꽤 중요해. 1시간 TTL을 쓸지 말지, 세션을 계속 유지하는 게 가성비가 나올지, 긴 컨텍스트가 비싼 건지 같은 것들이 전부 공개되지 않은 수치에 달려 있거든. 그래서 내가 직접 측정해 봤어.
아래 모든 내용은 일반적인 Claude Code CLI를 통해 측정한 거야.
결과
Claude Fable 5.1 (최대 5배)
Fable은 공유 윈도우 외에도 모델별 주간 윈도우를 따로 가지고 있어. 응답 헤더에 anthropic-ratelimit-unified-7d_oi-utilization으로 뜨는데, Fable에 요청을 보낼 때만 나타나.
| token type | 5h window | 7d window | Fable weekly | Subscription ratio | API ratio |
|---|---|---|---|---|---|
| cache read | 1.24% | 0.064% | 0.143% | 0.028 +/- 0.003 | 0.025 |
| plain input | 44.0% | 2.26% | 5.08% | 1.00 (base) | 1.00 |
| 5m cache write | 51.9% | 2.66% | 5.99% | 1.18 +/- 0.06 | 1.25 |
| 1h cache write | 52.0% | 2.66% | 5.99% | 1.18 +/- 0.06 | 2.00 |
| output | 232% | 11.9% | 26.8% | 5.27 +/- 0.24 | 5.00 |
백분율은 100만 토큰당 해당 윈도우에서 소모되는 점유율이야.
1시간 캐시 쓰기가 핵심인데, API에서 청구하는 2배가 아니라 구독 측정기 기준으로는 캐시되지 않은 입력의 1.18배야. Fable에서는 두 TTL 모두 비용이 똑같아.
Claude Opus 5 (최대 20배)
| token type | 5h window | 7d window | Subscription ratio | API ratio |
|---|
