platform.claude.com/docs/en/build-with-claude/prompt-caching)를 기반으로 하며, 복사-붙여넣기 가능한 예시와 함께 APIYI의 설정에 맞게 조정되었습니다.
한 문장으로
긴, 재사용되는 prompt 접두사(시스템 지시사항 / 긴 문서 / few-shot 예시)를cache_control로 표시합니다. 서버가 이를 저장하며, 다음 요청에서 같은 접두사가 오면 다시 처리하지 않으므로 — 대략 10배 더 저렴하고 빠릅니다. 일정 기간 사용이 없으면 만료됩니다.
왜 신경 써야 하는가 — 배수를 보십시오
모델의 기본 입력 token 가격 대비(1×):
손익분기점:
- 5분 TTL: 같은 prefix를 2번 재사용하면 손익분기점입니다(1.25 + 0.1 = 1.35, 캐시되지 않은 요청 2회분인 2.0보다 저렴합니다).
- 1시간 TTL: 3번 재사용하면 손익분기점입니다(2 + 0.2 = 2.2, 3.0보다 저렴합니다).
TTL은 슬라이딩 윈도우입니다: 캐시 적중할 때마다 만료 타이머가 초기화되므로, 활성 대화가 중간에 만료되지 않습니다. TTL을 넘는 진짜 유휴 상태일 때만 제거됩니다.
적합한 경우
- 같은 긴 시스템 prompt를 여러 번 호출하는 경우(에이전트, 챗봇)
- 멀티턴 대화인 경우(이전 턴마다 재사용 가능한 prefix가 됨)
- 하나의 문서를 일괄 처리하는 경우(한 계약서에 대해 50개 질문하기)
- 안정적인 검색 결과 청크가 prefix를 이루는 RAG
부적합한 경우
- 첫 글자부터 모든 prompt가 달라지는 경우
- 전체가 짧아서 모델별 최소값(아래)을 한 번도 넘지 않는 경우
세 가지 필수 요구 사항
세 가지 모두 필수입니다.1. 명시적인 cache_control 마커
content는 일반 문자열일 수 없습니다. 캐시하려는 블록에 cache_control가 연결된 콘텐츠 블록 배열이어야 합니다.
2. 길이가 모델별 최소 기준을 충족해야 함
콘텐츠가 모델의 최소 기준보다 짧으면 마커가 있어도 캐시되지 않습니다(오류 없이 조용히 건너뜁니다). Anthropic의 공식 문서에서 확인했습니다.APIYI에서 측정(2026-07-29). 크기를 단계적으로 늘린 고정 접두사로 쓰기 기준을 테스트했습니다.
claude-opus-5는 301 tokens에서 캐시 쓰기가 발생하지 않았지만 614에서는 발생하여 공식 기준인 512를 확인했고, claude-sonnet-5는 612에서는 발생하지 않았지만 1,250에서는 발생하여 공식 기준인 1,024를 확인했습니다. 둘 다 위 표와 일치합니다.3. 접두사가 바이트 단위로 완전히 일치해야 함
캐싱은 접두사 기반입니다. 요청 시작부터cache_control 마커까지의 바이트 스트림은 이전 요청과 동일해야 합니다. 공백, JSON 키 순서, 타임스탬프 등 단 하나의 문자라도 변경되면 새 접두사로 간주되어 캐시 적중 대신 새로운 쓰기가 발생합니다.
실무 규칙: 안정적인 내용은 앞에, 변동되는 내용은 뒤에 배치하십시오.
최소 실행 예제
같은 긴 문서를 사용하지만 서로 다른 질문으로 두 번 요청을 보냅니다. 첫 번째는 쓰고, 두 번째는 적중합니다:read는 첫 번째 호출의 write와 거의 같습니다. 같은 접두사가 다시 사용되고 있기 때문입니다.
적중 여부를 확인하는 방법 — 세 가지 사용 필드
모든 응답에서,usage는 다음을 보고합니다:
총 입력 token = 세 항목의 합입니다.
cache_read_input_tokens > 0인 한, 비용을 절감하고 있는 것입니다.
가장 흔한 문제점
고급: 다중 턴 대화
cache_control을 가장 최근 사용자 메시지의 마지막 콘텐츠 블록에 배치합니다. 각 새 턴은 캐시된 읽기 범위를 이전 턴의 끝까지 자동으로 확장합니다:
- 요청당 최대 4개의
cache_control중단점만 허용됩니다. - 각 중단점의 접두사 조회 창은 뒤로 최대 20개 콘텐츠 블록까지만입니다. 그보다 오래된 내용은 히트 대상으로 고려되지 않습니다. 다시 말해, 대화가 매우 길어지면 최신 턴만 표시해서는 이전 전체 기록을 포괄하지 못합니다.
APIYI와 캐싱에 대하여
APIYI는 캐시 필드를 엔드투엔드로 전달합니다. 사용자가 보내는
cache_control는 상위 Claude(AWS Claude 또는 Claude Official)로 그대로 전달되며, 반환되는 cache_creation_input_tokens / cache_read_input_tokens는 수정 없이 그대로 다시 전달됩니다. 따라서 코드에서 별도의 조정이 필요하지 않습니다.- 첫 번째 요청에서는
usage.cache_creation_input_tokens > 0(쓰기 성공)로 표시됩니다. - 몇 초 안에 동일한 prefix를 다시 보내면
usage.cache_read_input_tokens > 0(적중)를 보게 됩니다. - 과금 대시보드에서는 캐시 쓰기와 캐시 읽기가 각각 항목별로 표시되며, 동일한 공식 요율 배수(1.25× / 2× / 0.1×)가 적용됩니다.
요약
1. 표시하기
cache_control: {"type": "ephemeral"} 콘텐츠 블록에 — 일반 문자열 content은 캐시되지 않습니다.2. 충분한 길이
Opus 5 ≥ 512; Sonnet 5 / Sonnet 4.6 ≥ 1,024; Opus 4.7 ≥ 2,048; Opus 4.6 / Haiku 4.5 ≥ 4,096 tokens, 그렇지 않으면 조용히 건너뜁니다.
3. 안정적인 접두부
앞부분은 안정적으로 유지하고 뒷부분은 변동적으로 유지합니다; 한 글자만 달라도 캐시 적중이 깨집니다.
4. 사용량 확인
오직
cache_read_input_tokens > 0만이 실제로 비용을 절감했음을 증명합니다.관련 링크
- 상위 페이지: Claude API 기본
- 클라이언트 설정 가이드: Claude Code 연동 · Cherry Studio 연동
- token 가져오기 / 관리:
https://api.apiyi.com/token - Anthropic 공식 문서:
platform.claude.com/docs/en/build-with-claude/prompt-caching