캐시는 접두부 일치로만 작동합니다
두 회사 모두 프롬프트의 앞부분(접두부)을 기준으로 캐시를 찾습니다. 시스템 프롬프트, 도구 정의, 참조 문서처럼 요청마다 똑같은 내용이 앞에 있고 사용자 질문처럼 바뀌는 내용이 뒤에 있으면 앞부분이 캐시에 맞아떨어집니다.
반대로 접두부 중간에 바뀌는 값이 하나라도 있으면 그 지점 이후는 전부 캐시 실패입니다. 시스템 프롬프트에 현재 시각을 넣는 습관이 대표적인 캐시 파괴 사례입니다. 매 요청 시각이 달라지므로 캐시가 한 번도 적중하지 않습니다.
Claude는 명시, OpenAI는 자동이 기본입니다
같은 원리지만 켜는 방식과 요금이 다릅니다. 2026년 8월 28일 기준 공식 문서의 내용입니다.
| 항목 | Claude (Anthropic) | OpenAI (GPT-5.6 이후) |
|---|---|---|
| 활성화 | cache_control 표시 (자동 옵션도 제공) | 기본 자동 (명시 모드 선택 가능) |
| 캐시 읽기 요금 | 입력가의 10% | 입력가의 10% |
| 캐시 쓰기 요금 | 입력가의 125% (5분) / 200% (1시간) | 별도 쓰기 과금 없음 |
| 유지 시간 | 5분 (연장 옵션 1시간) | 마지막 사용 후 30분 |
| 최소 길이 | 약 1,024토큰 | 1,024토큰 |
Claude는 캐시에 쓸 때 25% 할증이 붙습니다. 캐시를 만들어 놓고 5분 안에 재사용하지 않으면 할증만 내고 할인은 못 받는 역효과가 납니다. 요청 간격이 뜸한 서비스는 1시간 유지 옵션(쓰기 200%)이나 캐싱 미적용과 비교 계산이 필요합니다. OpenAI는 쓰기 과금이 없는 대신 캐시 유지와 적중을 플랫폼이 관리하므로 통제 여지가 적습니다.
프롬프트를 세 층으로 배치합니다
설계 원칙은 하나입니다. 바뀌지 않는 순서대로 앞에서부터 쌓는 것입니다.
[1층 · 고정] 시스템 프롬프트, 도구 정의 — 배포마다 동결
[2층 · 준고정] 참조 문서, 오늘의 설정 — 하루~세션 단위 변경
[3층 · 가변] 대화 이력, 사용자 질문 — 매 요청 변경Claude라면 1층과 2층 끝에 cache_control을 표시합니다. OpenAI는 같은 배치를 유지하는 것만으로 자동 캐싱이 적중합니다.
JSON을 프롬프트에 넣을 때는 키 정렬을 고정하세요. 같은 데이터라도 직렬화 순서가 바뀌면 다른 접두부가 됩니다. 도구 목록의 순서가 요청마다 바뀌는 것도 같은 이유로 캐시를 깹니다.
resp = client.messages.create(
model="claude-sonnet-5", max_tokens=1024,
system=[dict(
type="text", text=LONG_SYSTEM_PROMPT,
cache_control=dict(type="ephemeral"))], # 여기까지 캐시
messages=[dict(role="user", content=question)])cache_control이 붙은 블록까지가 캐시 대상입니다. 요청 최상위에 cache_control 하나만 두는 자동 방식도 있어서, 멀티턴 대화라면 대화가 길어질수록 캐시 지점이 자동으로 따라오는 그 방식이 더 편합니다.
멀티턴 대화가 캐싱의 최대 수혜자입니다
챗봇은 매 턴 이전 대화 전체를 다시 보냅니다. 캐싱 없이는 10턴째 요청이 1턴부터 9턴까지의 모든 토큰을 정가로 다시 계산합니다. 캐싱을 켜면 이전 턴까지의 대화가 캐시에 잡혀서, 매 턴 새로 내는 비용은 직전 턴 이후의 증가분에 가까워집니다.
이 구조 덕분에 대화형 서비스는 캐싱 적용 전후의 청구액 차이가 가장 큽니다. 반대로 매 요청이 완전히 다른 단발성 API라면 캐싱이 해줄 것이 거의 없습니다. 내 트래픽이 어느 쪽인지가 도입 판단의 첫 질문입니다.
손익분기는 생각보다 낮습니다
캐싱 없이 100회: 10,000 × 100 × $2 = $2.00
캐싱 사용 100회: 쓰기 1회 $0.025 + 읽기 99회 $0.198 = 약 $0.22
절감: 약 89%5분 내 재요청이 이어지는 조건의 단순 계산입니다. 실제 절감률은 적중률에 따라 달라집니다.
Claude 기준 5분 유지 캐시는 한 번만 적중해도 이득입니다(쓰기 125% vs 읽기 10%). 1시간 유지는 두 번 이상 적중해야 본전입니다. 트래픽이 계속 흐르는 서비스일수록 캐싱의 효과가 커지는 구조입니다.
적중 여부는 응답의 usage로 확인합니다
# Claude
print(resp.usage.cache_read_input_tokens) # 적중량
print(resp.usage.cache_creation_input_tokens) # 쓰기량
# OpenAI
print(resp.usage.prompt_tokens_details.cached_tokens)켰다고 믿지 말고 측정하세요. Claude는 응답의 cache_read_input_tokens, OpenAI는 cached_tokens 필드로 실제 적중량을 알려줍니다. 반복 요청에서 이 값이 계속 0이라면 접두부 어딘가에 매번 바뀌는 값이 숨어 있다는 뜻입니다. 타임스탬프, 요청 ID, 정렬되지 않은 JSON부터 의심하면 대부분 잡힙니다.
Anthropic 프롬프트 캐싱 문서와 가격 문서, OpenAI 프롬프트 캐싱 문서를 2026년 8월 28일 확인했습니다.