정상 캐시 적중률은? AI 코딩 클라이언트 실측
2026-11-03 주간 실측에서 Claude 모델을 쓸 때 주요 AI 코딩 클라이언트의 진행 중 대화 캐시 적중률은 95%–98%, GPT를 쓰는 Codex는 약 95%였습니다. 클라이언트 간 차이는 작으며, 적중률이 눈에 띄게 낮다면 원인은 대개 계정 전환, 5분을 넘는 공백, 새 대화입니다.
2026-11-03 – 2026-11-09 주간(UTC)
핵심 요약
- Claude 모델 정상 수치: 95%–98%, 클라이언트 7개의 진행 중 대화 중앙값
- GPT를 쓰는 Codex: 94.8%, 사용자 71명의 중앙값
- 가장 흔한 미스 원인: 캐시 만료, Claude Code × Claude 미스의 37%
- 발표된 조합: 20, 클라이언트 × 모델, 각각 기준 충족 사용자 5명 이상
클라이언트별 정상 캐시 적중률
진행 중 대화 적중률은 같은 대화, 같은 모델과 업스트림 계정에서 이전 요청이 끝난 뒤 5분 이내에 보낸 요청만 집계합니다. 클라이언트 자체가 달성하는 수치입니다. 전체 요청 적중률은 라우팅, 만료, 새 채팅까지 포함하므로 청구서에 표시되는 값에 더 가깝습니다.
| 클라이언트 × 모델 | 진행 중 대화 | 전체 요청 | 사용자 |
|---|---|---|---|
| Z Code × Claude | 98.5% (97.7%–99.0%) | 94.3% | 13 |
| Magpie × DeepSeek | 98.3% (95.6%–98.8%) | 91.4% | 7 |
| DeepSeek Harness × DeepSeek | 98.2% (96.6%–98.9%) | 94.8% | 27 |
| Magpie × Claude | 98.2% (97.0%–98.8%) | 93.6% | 25 |
| OpenCode × DeepSeek | 98.2% (92.2%–98.5%) | 97.7% | 8 |
| Claude Code × Claude | 98.1% (96.9%–98.8%) | 94.6% | 343 |
| WorkBuddy × Claude | 97.8% (96.6%–98.3%) | 88.2% | 20 |
| OpenCode × Claude | 97.6% (97.1%–98.9%) | 95.1% | 20 |
| Claude Code × DeepSeek | 97.5% (95.6%–98.8%) | 96.5% | 12 |
| DeepSeek Harness × Claude | 97.2% (93.6%–98.0%) | 92.0% | 38 |
| Codex × DeepSeek | 96.9% (95.4%–98.3%) | 97.2% | 12 |
| WorkBuddy × GPT | 96.4% (91.4%–97.4%) | 92.4% | 10 |
| DeepSeek Harness × Kimi | 96.4% (95.3%–97.4%) | 93.9% | 6 |
| Codex × GPT | 94.8% (91.2%–96.9%) | 91.8% | 71 |
| Codex × Claude | 94.7% (87.0%–97.8%) | 93.5% | 21 |
| OpenCode × GPT | 94.6% (90.8%–96.2%) | 90.8% | 11 |
| Magpie × GPT | 94.3% (91.5%–95.5%) | 87.0% | 7 |
| DeepSeek Harness × GPT | 93.9% (92.5%–96.3%) | 91.9% | 11 |
| DeepSeek Harness × Other | 90.3% (88.4%–94.2%) | 80.8% | 5 |
| Claude Code × GPT | 78.8% (78.6%–94.4%) | 77.4% | 5 |
샘플링 중
- OpenCode × Other: 샘플링 중: 기준 충족 사용자 5명 중 4명(이번 주 사용자 9명)
- pi × Claude: 샘플링 중: 기준 충족 사용자 5명 중 4명(이번 주 사용자 7명)
- Claude Code × GLM: 샘플링 중: 기준 충족 사용자 5명 중 4명(이번 주 사용자 7명)
- Magpie × Kimi: 샘플링 중: 기준 충족 사용자 5명 중 4명(이번 주 사용자 4명)
- WorkBuddy × Kimi: 샘플링 중: 기준 충족 사용자 5명 중 3명(이번 주 사용자 4명)
- DeepSeek Harness × Grok: 샘플링 중: 기준 충족 사용자 5명 중 3명(이번 주 사용자 3명)
- Claude Code × Other: 샘플링 중: 기준 충족 사용자 5명 중 2명(이번 주 사용자 5명)
- WorkBuddy × DeepSeek: 샘플링 중: 기준 충족 사용자 5명 중 2명(이번 주 사용자 5명)
캐시 적중률이 낮은 이유: 클라이언트별 원인별 캐시 미스
- Claude Code × Claude: 5분 넘게 유휴, 캐시 만료 37%, 진행 중인 대화의 새 콘텐츠와 프리픽스 변경 23%, 새 대화 또는 1시간 넘게 유휴 17%
- Codex × GPT: 진행 중인 대화의 새 콘텐츠와 프리픽스 변경 57%, 다른 업스트림 계정 또는 엔드포인트로 라우팅됨 19%, 새 대화 또는 1시간 넘게 유휴 16%
- DeepSeek Harness × Claude: 진행 중인 대화의 새 콘텐츠와 프리픽스 변경 48%, 5분 넘게 유휴, 캐시 만료 32%, 새 대화 또는 1시간 넘게 유휴 16%
- DeepSeek Harness × DeepSeek: 다른 업스트림 계정 또는 엔드포인트로 라우팅됨 44%, 진행 중인 대화의 새 콘텐츠와 프리픽스 변경 30%, 새 대화 또는 1시간 넘게 유휴 22%
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%였습니다.
측정 방법
- Wokey 게이트웨이를 거친 실제 사용자 요청이며, 매주 월요일 05:00 UTC에 직전 주(월요일~일요일)를 집계합니다.
- 클라이언트는 요청의 User-Agent로 식별합니다. 실제 클라이언트를 알 수 없는 SDK, HTTP 라이브러리, 다운스트림 Relay의 요청은 제외하며, 엔터프라이즈 계정도 제외합니다.
- 연속 턴은 같은 대화의 이전 요청과 모델 및 업스트림 계정이 같고, 그 요청이 끝난 뒤 5분 이내에 시작된 턴입니다. 사용자별 적중률은 이 턴들의 캐시 읽기 ÷ 입력(입력에는 캐시 읽기와 쓰기가 포함)이며, 주간 연속 턴이 20회 이상인 사용자의 중앙값을 발표합니다.
- 각 셀은 기준 충족 사용자가 5명 이상일 때 발표하며, 지난주 대비 3포인트를 넘는 변화는 먼저 수동으로 확인합니다.
- 알려진 편향: Wokey 사용자만 대상입니다. 사용 습관은 사람마다 크게 다릅니다. 전체 요청 적중률에는 게이트웨이 자체의 라우팅 손실("다른 업스트림 계정으로 라우팅됨" 원인)이 포함됩니다.
자주 묻는 질문
정상적인 캐시 적중률은 어느 정도인가요?
Claude 모델의 진행 중 대화에서 주요 클라이언트의 사용자 중앙값은 95%–98%입니다. 라우팅, 만료, 새 채팅을 포함한 전체 요청 기준으로는 보통 몇 포인트 더 낮습니다. 90% 미만이라면 클라이언트 자체가 원인인 경우는 드뭅니다.
캐시 적중과 캐시 미스란 무엇인가요?
프롬프트 캐시는 요청 앞부분의 변하지 않는 내용(시스템 프롬프트, 도구 정의, 이전 턴)을 저장합니다. 다음 요청이 같은 내용으로 시작하면 그 부분은 캐시에서 읽히며(적중) 입력 가격의 일부만 과금됩니다. 내용이 다르거나 캐시가 만료되었으면 전체를 다시 처리하며(미스) 보통 다시 캐시에 기록됩니다.
캐시 적중률은 높을수록 좋은가요?
네, 높을수록 좋습니다. 캐시된 입력은 입력 가격의 약 0.1배(일부 최신 모델은 더 낮음)로 과금되고 첫 토큰도 더 빨리 도착합니다. Claude 구독에서는 캐시 읽기가 사용량 한도에 거의 반영되지 않습니다.
캐시 적중률이 왜 이렇게 낮나요?
흔한 원인은 다른 업스트림 계정으로 라우팅된 요청(Relay에서 흔함), 캐시를 만료시키는 5분 넘는 공백, 서브에이전트 같은 병렬 요청, 모델 전환, 새 대화입니다. 각 클라이언트 페이지에서 실측 비중순으로 원인과 대처법을 정리했습니다.
클라이언트마다 캐시 적중률 차이가 큰가요?
크지 않습니다. 같은 모델에서는 Claude Code, pi, OpenCode 등의 진행 중 대화 적중률이 몇 포인트 차이에 불과합니다. 벤더의 영향이 더 큽니다. OpenAI의 캐시는 프리픽스 전체가 일치해야 하므로 GPT를 쓰는 Codex는 Claude 클라이언트보다 몇 포인트 낮습니다.
Relay는 왜 캐시 적중률이 낮나요?
캐시는 업스트림 계정에 속합니다. 한 대화를 여러 계정에 나누거나 형식 변환 중 프리픽스를 바꾸는 Relay는 캐시를 계속 다시 기록합니다. 같은 프리픽스의 요청 두 개를 보내고 두 번째 요청이 프리픽스 길이 정도를 캐시에서 읽는지 확인해 테스트하세요.
캐시 적중률이 낮으면 Claude 요금제 한도가 더 빨리 소진되나요?
네. Claude 요금제 한도에 대한 자체 측정에서 캐시 읽기는 한도를 거의 쓰지 않고, 캐시 쓰기는 캐시되지 않은 입력과 비슷하게 계산됩니다. 캐시된 컨텍스트는 거의 소모가 없지만, 미스가 나면 다시 전부 계산됩니다. 요금제별 한도는 Claude 사용량 한도 페이지(/claude-usage-limits)에서 확인하세요.
캐시 적중률은 어떻게 계산하나요?
캐시 읽기 토큰 ÷ 입력 토큰이며, 입력에는 캐시되지 않은 입력, 캐시 쓰기, 캐시 읽기가 포함됩니다. Anthropic 형식에서는 cache_read_input_tokens, OpenAI 형식에서는 cached_tokens입니다.
Cline, Roo Code, Cursor가 표에 없는 이유는 무엇인가요?
각 셀에는 주간 연속 턴이 충분한 사용자가 5명 이상 필요합니다. Cursor의 자체 키 요청은 Cursor 서버에서 오므로 게이트웨이가 클라이언트를 볼 수 없고, SDK와 Relay를 거친 요청도 클라이언트를 구분할 수 없습니다.