작성자 Matt Connor
Claude 프롬프트 캐싱 손익분기점 계산 및 비용 절감 분석
Claude 프롬프트 캐싱은 쓰기 1.25배, 읽기 0.1배 비용이 발생합니다. 5분 캐시 설정 시 두 번째 요청부터 비용 절감이 시작되며, 1시간 캐시는 세 번째 요청부터 이득입니다. API 호출 시 발생하는 구체적인 비용 구조와 손익분기점 도출 과정을 상세히 설명합니다.
프롬프트 캐싱이 비용을 절감하기 전에 발생하는 비용
프롬프트 캐싱을 사용하면 Claude가 매 호출마다 프롬프트 앞부분을 다시 읽는 대신 재사용할 수 있습니다. 이 결정은 모델의 기본 입력 가격에 적용되는 두 가지 배율에 따라 달라집니다. 2026년 8월 기준으로, 캐시 쓰기 비용은 5분 유지 시 기본 입력 가격의 1.25배, 1시간 유지 시 2배입니다. 캐시 읽기 비용은 0.1배입니다. 이러한 배율은 전체 모델 목록에 동일하게 적용되므로, 토큰당 가격이 변경되어도 아래의 손익분기점은 변하지 않습니다.
이 방식은 현재의 추가 요금과 미래의 할인 사이의 교환입니다. 접두사를 저장하기 위해 한 번 추가 비용을 지불합니다. 이후 정확히 동일한 바이트로 시작하는 모든 요청은 해당 부분에 대해 일반 입력 가격의 10분의 1만 지불합니다. 유지 시간 내에 재사용되지 않는 접두사는 25퍼센트의 추가 비용만 낭비하게 됩니다.
손익분기점, 대수학 한 줄 요약
캐싱하지 않고 접두사(prefix)를 전송할 때의 기본 입력 비용을 B라고 합니다. 캐싱을 사용하지 않으면 N번의 요청 비용은 N 곱하기 B입니다. 5분 캐시를 사용하면 첫 번째 요청은 1.25B로 접두사를 쓰고, 나머지 N 빼기 1번의 요청은 0.1B로 읽습니다. 두 값을 같다고 두면 0.9N = 1.15가 되어 N = 1.28입니다. 즉, 두 번째 요청부터는 캐싱하지 않는 것보다 이미 저렴합니다.
1시간 캐시의 2배 쓰기 비용으로 동일하게 계산하면 0.9N = 1.9가 되어 N = 2.11입니다. 긴 캐시는 손익분기점에 도달하려면 두 번의 읽기가 필요하며, 이것이 기본값으로 선택되지 않는 이유입니다.
아래 차트는 2026년 8월 기준 100만 토큰당 5달러인 Claude Opus 5의 20,000 토큰 접두사에 대한 가격을 보여줍니다. 100만 토큰당 3달러 모델의 경우 모든 수치에 0.6을 곱하면 됩니다. 곡선의 형태는 변하지 않습니다.
The data behind this chart
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]단일 요청의 비용은 캐싱하지 않을 경우 $0.10이며, 캐싱할 경우 $0.125이므로 일회성 프롬프트를 캐싱하는 것은 순손실입니다. 두 번째 요청부터 5분 캐시는 $0.20 대비 $0.135가 됩니다. 1시간 캐시는 해당 시점에 $0.20 대비 $0.21로 여전히 비용이 높으며, 세 번째 요청이 되어서야 캐싱하지 않은 비용을 넘어섭니다: $0.30 대비 $0.22. 20번의 요청이 발생하면 격차는 $2.00 대비 $0.315가 됩니다.
캐시 적중(hit)은 항목을 갱신하기도 하므로, 게시된 가격표에서 해당 열을 캐시 적중 및 갱신(cache hits and refreshes)이라고 부릅니다. 따라서 트래픽이 많은 엔드포인트는 5분짜리 항목을 읽기 가격으로 무기한 유지하며, 1시간짜리 수명은 트래픽에 실제 공백이 있을 때만 2배의 쓰기 비용을 상쇄할 가치가 있습니다.
낮은 적중률이 초래하는 비용
실제 트래픽에서는 캐시 미스가 발생합니다. 캐시를 통과하지 못했음에도 중단점(breakpoint)을 포함하는 요청은 쓰기 작업으로 간주되므로, 비용을 적중률의 함수로 모델링하는 것이 정확합니다. 아래 차트는 각각 20,000 토큰의 프리픽스를 포함하는 1,000건의 요청에 대한 비용을 보여줍니다.
The data behind this chart
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]적중률이 0퍼센트일 때 지불하는 비용은 $100.00가 아닌 $125.00이며, 1시간 캐시를 사용하면 비용이 $200.00로 두 배가 됩니다. 1.25 - 1.15h = 1 방정식을 풀면 5분 캐시는 적중률 약 22퍼센트부터 비용 절감 효과가 나타나기 시작하며, 이것이 25퍼센트에서 $96.25가 표시되는 이유입니다. 동일한 계산을 2배의 쓰기 작업에 적용하면 1시간 캐시의 손익분기점은 약 53퍼센트가 되므로, 50퍼센트 적중률에서는 여전히 캐시를 사용하지 않을 때보다 높은 $105.00의 비용이 발생합니다. 90퍼센트 적중률에서는 각각 $21.50와 $29.00가 됩니다. 99퍼센트 적중률에 도달하면 단기 캐시는 캐시 미사용 시 가격의 10분의 1 수준인 $11.15에 근접합니다.
프리픽스 크기가 고정된 이후 제어할 수 있는 유일한 변수는 적중률이므로, 이를 측정하고 관리해야 합니다.
어떤 접두사에 중단점을 설정할 가치가 있는가
요청 하나당 최대 4개의 캐시 중단점을 설정할 수 있으므로, 어떤 블록에 중단점을 할당할지 결정해야 합니다. 후보는 호출 간에 바이트 단위로 동일하며, 유의미한 크기를 가진 블록입니다. 아래 차트는 5분 캐시에서 90%의 적중률을 보일 때 1,000건의 요청에 대한 4가지 일반적인 형태의 비용을 보여줍니다.
The data behind this chart
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]단순한 2,000 토큰 시스템 프롬프트는 캐시를 사용하지 않을 때의 $10.00 대비 1,000건당 $7.85를 절감합니다. 대량 처리 시에는 실질적인 비용이 되지만, 이것이 캐싱의 핵심 가치는 아닙니다. 도구 정의를 추가하면 8,000 토큰이 되어 $31.40가 절감됩니다. 모든 요청에서 참조하는 25,000 토큰 분량의 정책 문서는 $98.12를 절감합니다. 마지막 행은 아키텍처를 변화시키는 사례입니다. 120,000 토큰의 코드베이스나 대화 맥락은 캐시 미사용 시 $600.00, 캐시 사용 시 $129.00가 소요되어 $471.00가 절감됩니다.
절감액은 접두사 크기와 적중률에 비례하며, 다른 요소에는 영향을 받지 않습니다. 이는 프롬프트에 무엇을 포함할지에 대한 기준을 바꿉니다. Claude 토큰 100만 개의 실제 비용은 한 번 이상 전송하는 모든 데이터에 대해 표시 가격의 10분의 1 수준으로 떨어집니다.
월별 청구서에 나타나는 비용
아래 차트는 위에서 언급한 8,000 토큰 프리픽스에 시스템 프롬프트와 도구 정의를 포함하고, 90퍼센트의 적중률을 가정하여 월간 요청량에 따른 비용을 산출한 것입니다.
The data behind this chart
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]월 10,000건의 요청 시 절감액은 $314.00이며, 이는 $400.00와 $86.00 사이의 차액입니다. 100,000건의 요청 시 절감액은 $3,140.00입니다. 100만 건의 요청 시 캐싱되지 않은 입력 비용은 $40,000.00이며, 캐싱을 통해 이 중 $31,400.00를 절감할 수 있습니다. 이는 입력 토큰에만 해당합니다. 출력 토큰은 별도로 과금되며 캐싱의 영향을 받지 않으므로, 누군가에게 90퍼센트의 비용 절감을 약속하기 전에 이 점을 반드시 기억해야 합니다. 캐싱은 VPS에서 AI 에이전트 비용을 제어하는 방법에 관한 더 넓은 관점의 습관들과 함께 고려해야 합니다.
캐시 작동 여부 확인 방법
설계만 믿지 마십시오. 응답의 usage 블록을 확인하십시오. 모든 Messages API(애플리케이션 프로그래밍 인터페이스) 응답은 기록된 캐시 토큰, 읽어 들인 캐시 토큰, 그리고 새로 처리해야 했던 토큰의 수를 보고합니다.
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)동일한 문서로 질문을 바꾸어 두 번 실행하십시오. 첫 번째 호출은 0이 아닌 cache_creation_input_tokens 값과 0인 cache_read_input_tokens 값을 보고합니다. 두 번째 호출에서는 접두사가 발견되었으므로 이 결과가 반대로 나타납니다. input_tokens은 마지막 중단점 이후의 토큰만 계산하므로, 정상적인 두 번째 호출에서는 보통 새로운 사용자 메시지만 포함되어 작은 값을 가집니다.
request.json에 저장한 요청 본문을 사용하여 셸에서 동일한 확인을 수행할 수 있습니다.
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'정상적인 두 번째 호출은 다음과 같은 결과를 출력합니다.
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}한 줄의 결과가 진실을 말해줍니다. 만약 호출을 반복해도 cache_read_input_tokens가 0으로 유지된다면, 매번 1.25배의 쓰기 비용을 지불하고 있으며 캐시 효과를 전혀 보지 못하는 것입니다.
1시간의 수명(TTL)을 위해 중단점에는 생존 시간(TTL)이 포함됩니다.
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}자동 캐싱 기능도 있습니다. 요청 최상위 수준에 cache_control 필드를 하나 추가하면, 대화가 길어짐에 따라 API가 알아서 중단점을 관리합니다. 이는 4개의 중단점 슬롯 중 하나를 사용합니다. 우선 이 방식을 시작하십시오. 경계 위치를 정확히 결정해야 할 때 명시적 중단점으로 전환하십시오.
적중률을 떨어뜨리는 순서 규칙
캐시는 요청 시작 부분부터 바이트 단위로 접두사를 일치시키며, 요청은 도구(tools), 시스템(system), 메시지(messages) 순서로 고정되어 조립됩니다. 특정 수준에서 변경이 발생하면 해당 수준과 그 이후의 모든 항목이 무효화됩니다. 도구 설명을 하나만 수정해도 시스템 프롬프트와 전체 메시지 기록이 함께 무효화되는데, 이는 사용자가 해당 부분을 건드리지 않았더라도 마찬가지입니다.
여기에는 예외 없는 규칙이 하나 있습니다. 호출마다 변경되는 모든 요소는 변경되지 않는 모든 요소 뒤에 위치해야 합니다.
가장 흔한 원인은 타임스탬프입니다. 시스템 프롬프트 상단에 Current time: 2026-08-03T14:07:11Z라고 적힌 줄이 있으면 적중률은 0퍼센트가 됩니다. 호출할 때마다 접두사 해시가 달라지며, 이전 항목은 그 어떤 것도 일치할 수 없기 때문입니다. 이를 사용자 메시지의 맨 끝으로 옮기십시오. 세션 식별자나 요청별 nonce도 같은 방식으로 문제를 일으키며 동일한 해결책이 적용됩니다. 요청마다 달라지는 검색된 문서 역시 캐시된 블록 뒤에 배치해야 합니다. 그렇지 않으면 안정적인 모든 토큰이 이동하는 경계 뒤로 밀려나게 됩니다.
두 번째 원인은 변경되는 블록에 중단점(breakpoint)을 설정하는 것입니다. 캐시 쓰기는 중단점에서 발생하므로, 해당 블록이 매번 다르다면 안정적인 데이터는 전혀 저장되지 않습니다. 이 경우 조회(lookback) 기능은 이전 요청들이 각자의 이동하는 중단점에서 기록한 항목들만 찾게 됩니다. cache_control는 요청 간에 내용이 동일한 마지막 블록에 배치하십시오.
세 번째 원인은 프롬프트 내용이라고 생각하지 못한 매개변수 변경입니다. 모델이 다르면 캐시도 다릅니다. 도구 선택을 변경하면 시스템 수준부터 이후의 모든 내용이 무효화됩니다. 도구를 추가하거나 제거해도 모든 것이 무효화됩니다.
최소 프리픽스 및 조용한 무동작
모델의 최소 요구치보다 짧은 프리픽스는 캐싱되지 않으며, 이에 대한 알림도 제공되지 않습니다. 오류나 경고는 발생하지 않습니다. 요청은 성공하며 두 카운터 모두 0으로 표시됩니다. 2026년 8월 기준 공개된 최소 토큰 요구치는 다음과 같습니다.
- Claude Opus 5 및 Claude Fable 5: 512 토큰
- Claude Sonnet 5 및 Claude Opus 4.8: 1,024 토큰
- Claude Haiku 4.5: 4,096 토큰
캐싱이 적용되어야 할 요청에서 두 카운터가 모두 0으로 표시된다면, 다른 무엇보다 먼저 프리픽스 길이를 확인하십시오. 이것이 바로 가장 저렴한 모델이 캐싱 작업 부하에서도 자동으로 가장 저렴한 모델이 되지는 않는 이유입니다. Haiku 4.5는 캐싱이 시작되기 위해 Opus 5보다 8배 더 긴 프리픽스가 필요합니다. 따라서 2,000 토큰의 시스템 프롬프트는 한 모델에서는 캐싱되지만 다른 모델에서는 조용히 무시됩니다.
Claude Code의 캐싱 위치와 캐싱이 불가능한 경우
Claude Code는 자체적인 프리픽스(prefix)를 캐싱합니다. 시스템 프롬프트와 도구 정의는 모든 요청의 앞부분에 위치하며 변경되지 않으므로, 한 번 작성된 후 세션이 유지되는 동안에는 이를 다시 읽어 들입니다. 이것이 긴 세션의 턴당 비용이 컨텍스트 크기로 예상되는 것보다 훨씬 낮은 이유이며, Claude Code의 토큰 사용량 보고 방식에서 설명하는 카운터에 반영됩니다.
캐싱이 도움이 되지 않는 경우는 컨텍스트 앞부분에서 수정이 발생할 때입니다. 대화 기록은 추가만 가능(append-only)하므로, 일반적인 새 턴은 이미 캐싱된 프리픽스를 확장하는 방식입니다. 세션 초기에 읽은 파일을 수정하면 해당 프리픽스 중간의 내용이 바뀌게 되며, 변경 지점 이후의 모든 토큰을 다시 작성해야 합니다. 긴 유휴 시간(idle gap)이 발생해도 마찬가지입니다. 캐시 항목이 만료되어 다음 턴에서 전체 쓰기 비용이 발생하기 때문입니다. 두 경우 모두 버그가 아닙니다. 프리픽스 규칙이 명시된 대로 정확하게 작동하는 결과입니다.
직접 클라이언트를 개발 중이라면, 나중에 구조를 수정하려 하지 말고 첫 번째 요청부터 레이아웃을 올바르게 적용하십시오. VPS에서 첫 Claude API 앱 만들기에서 설명하는 방식대로, 변하지 않는 블록을 앞쪽에 배치하고 변동성이 큰 블록을 뒤쪽에 배치하여 호출을 구성하십시오.
실패 유형 및 확인 사항
모든 호출이 쓰기(write)로 처리됨. cache_creation_input_tokens은 모든 요청에서 0이 아니지만 cache_read_input_tokens은 0을 유지합니다. 호출 사이에 중단점(breakpoint) 이전이나 그 지점에서 무언가가 변경되고 있습니다. 연속된 두 요청에서 조립된 프리픽스의 처음 200자를 출력하여 육안으로 비교하십시오.
두 카운터 모두 0임. 프리픽스가 모델의 최소 요구 사항보다 작거나, cache_control 필드가 API에 도달하지 못한 경우입니다. 먼저 프리픽스 토큰 수를 세어보고, 실제로 전송한 요청 본문을 로그로 남기십시오.
읽기는 작동하다가 중단됨. 적중(hit)이 이어지다가 쓰기가 발생하고 다시 적중이 이어지는 경우입니다. 요청 사이의 간격이 유효 기간(lifetime)보다 길었습니다. 쓰기를 수용하거나, 적중률이 53 퍼센트를 넘는지 확인한 후 1시간 TTL로 전환하십시오.
배포 후 적중률이 하락함. 도구 설명이 수정되었거나 모델이 변경된 경우입니다. 두 경우 모두 전체 프리픽스를 무효화합니다. 프롬프트에 영향을 주는 배포가 있을 때마다 한 번의 비용이 많이 드는 쓰기 과정을 예상해야 합니다.
캐싱을 활성화한 후 청구 금액이 증가함. 적중률이 손익분기점 아래에 있는 경우입니다. 5분 캐시에서는 약 22 퍼센트 미만일 때, 1시간 캐시에서는 약 53 퍼센트 미만일 때 프리픽스를 캐싱하지 않고 전송하는 것이 더 저렴합니다.
FAQ
캐시 비용을 회수하려면 프롬프트를 몇 번 재사용해야 합니까?
5분 캐시 기준으로는 1회입니다. 쓰기 비용은 기본 입력의 1.25배이고 읽기 비용은 0.1배입니다. 캐시를 사용하지 않는 N번의 요청 비용은 N인 반면, 캐시를 사용하는 N번의 요청 비용은 1.25 + 0.1 * (N - 1)입니다. 두 비용은 N = 1.28에서 교차하므로 두 번째 요청부터는 캐시가 유리합니다. 1시간 캐시는 쓰기 비용이 2배이며 N = 2.11에서 교차하므로, 두 번의 읽기가 필요합니다.
왜 cache_read_input_tokens 값이 항상 0입니까?
먼저 접두사 길이를 확인하십시오. 2026년 8월 기준 Claude Opus 5는 512 토큰, Claude Haiku 4.5는 4,096 토큰인 모델 최소치를 넘지 못하면 캐싱은 자동으로 건너뛰며 두 카운터 모두 0으로 표시됩니다. 접두사가 충분히 길다면 시스템 프롬프트의 타임스탬프나 세션 식별자처럼 호출 간에 변경되는 내용이 중단점 이전이나 그 지점에 있는지 확인하십시오. 카운터가 정상 작동하다가 멈췄다면 요청 사이의 간격이 캐시 유지 시간보다 길었던 것입니다.
프롬프트 캐싱이 Claude의 답변을 변경합니까?
아니요. 캐시는 이미 전송한 토큰의 처리된 형태를 저장하며, 모델은 어떤 방식이든 동일한 프롬프트를 확인합니다. 이는 비용 청구 및 지연 시간 개선을 위한 기능일 뿐 동작 방식의 변경이 아닙니다. 따라서 기존에 잘 작동하던 프롬프트에 평가를 다시 실행하지 않고도 캐싱을 활성화할 수 있습니다.
1시간 캐시를 사용해야 합니까?
트래픽 간격이 5분보다 길고 적중률이 약 53퍼센트를 넘을 것으로 예상될 때만 사용하십시오. 2배의 쓰기 비용은 캐시 적중 실패 시 1.25배 쓰기 비용보다 두 배의 손실을 발생시킵니다. 5분 캐시는 적중할 때마다 갱신되므로, 꾸준한 트래픽이 있다면 읽기 비용만으로 캐시를 유지할 수 있어 더 긴 수명에 대한 비용을 지불할 필요가 없습니다.