Claude Code 캐시 적중률 실측

2026-11-03 주간 실측에서 Claude 모델을 쓰는 Claude Code의 진행 중 대화 캐시 적중률 중앙값은 98.1%(사용자 343명), 전체 요청 기준 94.6%였습니다. 미스의 주된 원인: 캐시 만료 (37%), 진행 중인 턴의 새 콘텐츠 (23%), 새 대화 (17%).

2026-11-03 – 2026-11-09 주간(UTC)

핵심 요약

  • 정상 수치: 98.1%, 사용자 343명의 진행 중 대화 중앙값, 중간 절반 96.9%~98.8%
  • 전체 요청: 94.6%, 라우팅, 만료, 새 채팅 포함
  • 가장 큰 미스 원인: 캐시 만료, 미스의 37%
  • 형태 간: 1.7포인트 차이, CLI(터미널), 데스크톱 앱, 데스크톱 로컬 에이전트

클라이언트별 정상 캐시 적중률

2026-11-03 – 2026-11-09 주간(UTC)

  • 진행 중 대화 적중률(사용자 중앙값): 98.1%
  • 중간 절반 사용자: 96.9%–98.8%
  • 기준 충족 사용자: 343 (주간 연속 턴 20회 이상)
  • 전체 요청 적중률: 94.6%

Claude Code 형태별 적중률

한 클라이언트의 CLI, IDE 확장, 데스크톱 앱은 거의 같은 요청을 보내므로 적중률도 비슷해야 합니다.

  • CLI(터미널): 98.2% (147)
  • 데스크톱 앱: 98.4% (114)
  • 데스크톱 로컬 에이전트: 98.0% (78)
  • VS Code 확장: 97.8% (50)
  • Agent SDK(CLI): 96.7% (43)
  • Agent SDK(TypeScript): 97.8% (16)
  • t3-code: 97.9% (5)

Claude Code 버전별 적중률

요청 프리픽스를 바꾼 릴리스는 배포된 그 주에 다른 버전보다 적중률이 뚜렷하게 낮게 나타납니다.

  • 2.1.321: 97.6% (5)
  • 2.1.319: 98.4% (77)
  • 2.1.318: 98.3% (92)
  • 2.1.317: 97.9% (133)
  • 2.1.316: 98.4% (44)
  • 2.1.314: 98.5% (25)
  • 2.1.312: 98.0% (20)
  • 2.1.311: 98.4% (13)
  • 2.1.310: 97.4% (14)
  • 2.1.309: 98.3% (98)
  • 2.1.308: 98.0% (30)
  • 2.1.302: 96.4% (7)
  • 2.1.299: 97.6% (6)
  • 2.1.296: 98.0% (8)
  • 2.1.295: 97.6% (14)
  • 2.1.292: 99.0% (5)
  • 2.1.284: 97.0% (6)
  • 2.1.280: 98.2% (11)

주간 중앙값

  • 2026-09-29: 96.8% (120명)
  • 2026-10-06: 97.8% (220명)
  • 2026-10-13: 98.0% (256명)
  • 2026-10-20: 98.0% (250명)
  • 2026-10-27: 98.0% (259명)
  • 2026-11-03: 98.1% (343명)

Claude Code 캐시 적중률이 낮은 이유: 원인별 캐시 미스

이번 주 입력의 5.4%는 캐시에서 읽히지 않았습니다. 아래에 원인별 내역과 각각의 대처법을 정리했습니다.

5분 넘게 유휴, 캐시 만료: 미스의 37%, 전체 입력의 약 2.0%
캐시는 기본 5분 동안 유지되며 적중할 때마다 무료로 갱신됩니다. 자주 더 오래 멈춘다면 CLAUDE_CODE_PROMPT_CACHE_TTL=1h를 설정하세요(v2.1.242+). 그러면 캐시 쓰기 비용이 입력 가격의 1.25배가 아니라 2배가 됩니다.
진행 중인 대화의 새 콘텐츠와 프리픽스 변경: 미스의 23%, 전체 입력의 약 1.2%
해당 턴의 새 콘텐츠는 기록만 되고 읽을 수 없습니다. MCP 서버를 연결하거나 제거하거나, MCP 서버를 포함한 플러그인을 활성화하면 도구 정의가 바뀌어 캐시가 무효화됩니다.
새 대화 또는 1시간 넘게 유휴: 미스의 17%, 전체 입력의 약 0.9%
새 대화의 첫 요청이나 1시간 유휴 후의 요청은 캐시를 다시 기록해야 합니다.
모델 변경: 미스의 12%, 전체 입력의 약 0.6%
모델마다 캐시가 따로 있습니다. /model 이후 다음 요청은 내용이 완전히 같아도 캐시 적중 없이 전체 기록을 읽습니다.
병렬 요청(이전 요청이 아직 실행 중): 미스의 10%, 전체 입력의 약 0.5%
서브에이전트와 병렬 도구 호출은 이전 요청이 끝나기 전에 다음 요청을 보냅니다. Claude Code의 fork는 상위 세션의 캐시를 읽고, 일반 서브에이전트는 자체 시스템 프롬프트와 도구를 가지며 자체 캐시를 만듭니다.
다른 업스트림 계정 또는 엔드포인트로 라우팅됨: 미스의 2%, 전체 입력의 약 0.1%
프롬프트 캐시는 요청을 처리한 업스트림 계정에 저장됩니다. Relay나 다중 계정 게이트웨이가 다음 턴을 다른 계정으로 보내면 전체 컨텍스트가 다시 기록됩니다. 벤더에 직접 연결하면 이 원인은 생기지 않습니다.

적중률 몇 포인트 차이가 청구액 몇 배 차이

Claude Opus 5.5 공식 가격 기준, 미스분을 5분 캐시에 기록할 때 입력 토큰 100만 개당 실제 비용:

  • 이번 주 중앙값 98.1%: $0.29 (×1.0)
  • 90%: $0.68 (×2.3)
  • 80%: $1.16 (×4.0)
  • 50%: $2.60 (×9.0)

Claude API 비용 계산기로 직접 계산해 보세요

Claude Code 캐시 TTL: 유지 시간과 비용

  • 기본 5분 동안 유지되며, 적중할 때마다 무료로 갱신됩니다.
  • CLAUDE_CODE_PROMPT_CACHE_TTL=1h로 1시간으로 바꿀 수 있습니다(v2.1.242+, 서브에이전트는 CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL). 이전 버전에서는 ENABLE_PROMPT_CACHING_1H=1을 사용하세요.
  • 캐시 쓰기는 입력 가격의 1.25배(5분) 또는 2배(1시간)이고, 읽기는 보통 0.1배이며 Opus 5.5와 Sonnet 5.5에서는 0.05배입니다.
  • 최소 길이보다 짧은 프롬프트는 오류 없이 캐시되지 않습니다. 모델에 따라 512~4,096토큰입니다.

Anthropic 프롬프트 캐싱 · Claude Code 프롬프트 캐싱 · Claude Code 환경 변수

Claude Code 캐시 적중률 확인 방법

  • Claude Code에서 /usage를 실행하세요. Session 블록의 Prompt cache (main) 줄에 요청 수, 캐시에서 제공된 입력 비율, 캐시 미스, 캐시가 아직 유효한지가 표시됩니다.
  • 상태 표시줄 스크립트는 prompt_cache 필드를 읽을 수 있고, OpenTelemetry 익스포터는 캐시 읽기 및 생성 토큰을 사용자와 세션별로 보고합니다.
  • API 기준: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
  • Wokey에서는 콘솔의 요청 로그에서 요청마다 캐시 읽기와 캐시 쓰기를 확인할 수 있습니다.

Claude Code 비용 및 사용량

Relay를 거치면 적중률이 떨어지는 이유

  • 계정 전환: 캐시는 업스트림 계정에 속하므로 다른 계정으로 보낸 턴은 모든 내용을 다시 기록합니다. Relay에서 가장 흔한 원인이며 직접 연결에서는 생기지 않습니다.
  • 형식 변환: Anthropic 형식과 OpenAI 형식을 서로 변환하면 프리픽스가 바뀌거나 cache_control 브레이크포인트가 사라질 수 있습니다.
  • v2.1.181 이전의 Claude Code는 사용자 지정 base URL에서 시스템 프롬프트 맨 앞 귀속 블록에 요청마다 다른 토큰을 넣었기 때문에, 요청 본문 기준으로 캐시하는 게이트웨이에서는 적중하지 않습니다. 업데이트하거나 CLAUDE_CODE_ATTRIBUTION_HEADER=0을 설정하세요.
  • 자체 테스트: 최소 캐시 길이를 넘는 같은 프리픽스의 요청 두 개를 보내세요. 두 번째 요청의 캐시 읽기가 프리픽스 길이에 가까워야 합니다.

Wokey는 가능한 한 대화의 후속 요청을 같은 업스트림 계정으로 라우팅합니다. 2026-10-04부터 2026-10-10까지 Wokey 일반 사용자는 Claude Opus 5.5 전체 요청에서 92.8% 적중률을 기록했고, OpenRouter 전체는 87.8%였습니다.

OpenRouter 캐시 적중률과 비교 · 실시간: Wokey 공개 캐시 적중률 API(최근 7일)

측정 방법

  • Wokey 게이트웨이를 거친 실제 사용자 요청이며, 매주 월요일 05:00 UTC에 직전 주(월요일~일요일)를 집계합니다.
  • 클라이언트는 요청의 User-Agent로 식별합니다. 실제 클라이언트를 알 수 없는 SDK, HTTP 라이브러리, 다운스트림 Relay의 요청은 제외하며, 엔터프라이즈 계정도 제외합니다.
  • 연속 턴은 같은 대화의 이전 요청과 모델 및 업스트림 계정이 같고, 그 요청이 끝난 뒤 5분 이내에 시작된 턴입니다. 사용자별 적중률은 이 턴들의 캐시 읽기 ÷ 입력(입력에는 캐시 읽기와 쓰기가 포함)이며, 주간 연속 턴이 20회 이상인 사용자의 중앙값을 발표합니다.
  • 각 셀은 기준 충족 사용자가 5명 이상일 때 발표하며, 지난주 대비 3포인트를 넘는 변화는 먼저 수동으로 확인합니다.
  • 알려진 편향: Wokey 사용자만 대상입니다. 사용 습관은 사람마다 크게 다릅니다. 전체 요청 적중률에는 게이트웨이 자체의 라우팅 손실("다른 업스트림 계정으로 라우팅됨" 원인)이 포함됩니다.

자주 묻는 질문

Claude Code의 정상적인 캐시 적중률은 어느 정도인가요?

이번 주 사용자 343명의 진행 중 대화 중앙값은 98.1%이고, 중간 절반은 96.9%~98.8%였습니다. 전체 요청 기준으로는 94.6%였습니다.

Claude Code 캐시 적중률이 낮은 이유는 무엇인가요?

이번 주 미스의 주된 원인: 캐시 만료 (37%), 진행 중인 턴의 새 콘텐츠 (23%), 새 대화 (17%). 페이지에 원인별 대처법을 정리했습니다.

캐시 적중률이 낮으면 Claude 요금제 한도가 더 빨리 소진되나요?

네. Claude 요금제 한도에 대한 자체 측정에서 캐시 읽기는 한도를 거의 쓰지 않고, 캐시 쓰기는 캐시되지 않은 입력과 비슷하게 계산됩니다. 캐시된 컨텍스트는 거의 소모가 없지만, 미스가 나면 다시 전부 계산됩니다. 요금제별 한도는 Claude 사용량 한도 페이지(/claude-usage-limits)에서 확인하세요.

Claude Code의 cache read tokens란 무엇인가요?

캐시에서 제공된 입력 부분으로, cache_read_input_tokens로 보고됩니다. 긴 세션에서는 보통 입력의 90% 이상이며 입력 가격의 0.1배(Opus 5.5와 Sonnet 5.5는 0.05배)로 과금됩니다. cache_creation_input_tokens는 해당 요청이 새로 캐시에 기록한 부분입니다.

1시간 캐시를 쓸 가치가 있나요?

대개는 아닙니다. Wokey의 실제 Claude 트래픽 하루치를 다시 계산해 보니, 모두 1시간 캐시로 바꾸면 총지출이 순증 약 15~25% 늘었습니다. 쓰기 비용이 입력 가격의 1.25배에서 2배로 오르는데, 이는 만료가 줄어 아끼는 금액보다 큽니다. 컨텍스트가 길고 5~60분 멈춤이 잦은 경우에만 이득일 수 있습니다.

Claude Code 캐시는 얼마나 유지되나요?

기본 5분이며 적중할 때마다 무료로 갱신됩니다. CLAUDE_CODE_PROMPT_CACHE_TTL=1h(v2.1.242+)로 1시간이 되며, 캐시 쓰기는 입력 가격의 1.25배가 아니라 2배가 됩니다.

모델 전환이나 서브에이전트가 캐시를 깨뜨리나요?

네. 모델마다 캐시가 따로 있어 /model 이후 요청은 모든 내용을 다시 읽습니다. 일반 서브에이전트는 자체 시스템 프롬프트와 도구로 자체 캐시를 만들고, fork는 상위 세션의 캐시를 재사용합니다.

cache creation(캐시 생성)은 왜 이렇게 비싼가요?

캐시 쓰기는 입력 가격의 1.25배(5분) 또는 2배(1시간)입니다. 긴 대화의 첫 요청이나 계정 전환·만료 후의 요청은 전체 컨텍스트를 한 번 기록하므로 일반 턴보다 확연히 비쌉니다.

Claude Code를 Relay로 연결해도 캐시가 작동하나요?

네. Relay가 cache_control을 그대로 전달하고 한 대화를 하나의 업스트림 계정에 유지한다면 작동합니다. 사용자 지정 base URL을 쓰는 v2.1.181 이전 버전은 업데이트하거나 CLAUDE_CODE_ATTRIBUTION_HEADER=0을 설정해야 합니다.