Codex 캐시 적중률 실측

핵심 요약

• 정상 수치: 94.8%, 사용자 71명의 진행 중 대화 중앙값, 중간 절반 91.2%~96.9%
• 전체 요청: 91.8%, 라우팅, 만료, 새 채팅 포함
• 가장 큰 미스 원인: 진행 중인 턴의 새 콘텐츠, 미스의 57%
• 형태 간: 4.6포인트 차이, 데스크톱 앱, 터미널 UI, codex exec(비대화형)

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

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

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

Codex 형태별 적중률

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

• 데스크톱 앱: 95.3% (55)
• 터미널 UI: 95.8% (11)
• codex exec(비대화형): 91.2% (9)

Codex 버전별 적중률

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

• 0.167.0-alpha.3.2: 95.0% (27)
• 0.167.0: 93.3% (6)
• 0.166.0-alpha.6: 95.6% (29)
• 0.166.0-alpha.5.1: 96.4% (28)
• 0.166.0: 96.6% (5)

주간 중앙값

• 2026-09-29: 96.0% (38명)
• 2026-10-06: 95.3% (54명)
• 2026-10-13: 95.4% (62명)
• 2026-10-20: 95.8% (49명)
• 2026-10-27: 95.1% (72명)
• 2026-11-03: 94.8% (71명)

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

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

진행 중인 대화의 새 콘텐츠와 프리픽스 변경: 미스의 57%, 전체 입력의 약 4.7%

OpenAI의 캐시는 프리픽스 전체가 일치해야 합니다. 세션 도중 reasoning effort, 도구, 출력 형식을 바꾸거나 Codex가 기록을 압축(compaction)하면 프리픽스가 바뀝니다. 이것이 Codex 캐시 미스의 가장 큰 원인입니다.

다른 업스트림 계정 또는 엔드포인트로 라우팅됨: 미스의 19%, 전체 입력의 약 1.6%

프롬프트 캐시는 요청을 처리한 업스트림 계정에 저장됩니다. Relay나 다중 계정 게이트웨이가 다음 턴을 다른 계정으로 보내면 전체 컨텍스트가 다시 기록됩니다. 벤더에 직접 연결하면 이 원인은 생기지 않습니다.

새 대화 또는 1시간 넘게 유휴: 미스의 16%, 전체 입력의 약 1.3%

새 대화의 첫 요청이나 1시간 유휴 후의 요청은 캐시를 다시 기록해야 합니다.

모델 변경: 미스의 3%, 전체 입력의 약 0.3%

모델마다 캐시가 따로 있으므로 모델을 전환한 뒤 첫 요청은 전체 기록을 다시 읽습니다.

5분 넘게 유휴, 캐시 만료: 미스의 3%, 전체 입력의 약 0.2%

GPT-5.6 이상에서는 캐시가 마지막 쓰기 또는 재사용 시점부터 기본 30분 동안 유지됩니다. 이전 모델은 보통 5~10분 유휴 후 캐시를 버립니다.

병렬 요청(이전 요청이 아직 실행 중): 미스의 2%, 전체 입력의 약 0.2%

이전 요청이 끝나기 전에 보낸 요청(서브에이전트, 병렬 도구 호출)은 이전 요청이 아직 쓰고 있는 캐시를 읽을 수 없습니다.

Codex 캐시 TTL: 유지 시간과 비용

• OpenAI는 클라이언트 브레이크포인트 없이 프롬프트 프리픽스를 자동으로 캐시합니다. GPT-5.6 이상은 1,024토큰부터 캐시합니다.
• GPT-5.6 이상은 마지막 쓰기 또는 재사용 시점부터 기본 30분 동안 유지합니다. 이전 모델은 메모리 내 항목을 약 5~10분 유휴까지, 최대 1시간 유지하며, 일부는 24시간 보존을 지원합니다.
• 캐시된 입력은 보통 입력 가격의 0.1배(GPT-6.1 Sol은 0.05배)로 과금되며, GPT-5.6 이상은 캐시 쓰기에 1.25배를 부과합니다.
• Codex는 세션 ID를 prompt_cache_key로 보내므로(소스 코드 기준) 한 세션의 요청은 같은 캐시로 라우팅됩니다.

OpenAI 프롬프트 캐싱 · OpenAI 캐시 미스 진단 · Codex 소스 코드(prompt_cache_key) · Codex issue #35416: reasoning effort 변경 시 캐시 미스

Codex 캐시 적중률 확인 방법

• Codex CLI는 종료할 때 세션의 토큰 사용량을 출력하며, "+ N cached" 부분이 캐시에서 읽은 입력입니다(현재 동작이며 문서에는 없음).
• API 기준: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens. GPT-5.6 이상은 캐시 쓰기도 보고합니다.
• OpenTelemetry 지표 turn.token_usage에는 cached_input 유형이 있습니다.
• Wokey에서는 콘솔의 요청 로그에서 요청마다 캐시 읽기와 캐시 쓰기를 확인할 수 있습니다.

OpenAI 캐시 미스 진단

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 사용자만 대상입니다. 사용 습관은 사람마다 크게 다릅니다. 전체 요청 적중률에는 게이트웨이 자체의 라우팅 손실("다른 업스트림 계정으로 라우팅됨" 원인)이 포함됩니다.

자주 묻는 질문