Anthropic, Claude Code 프롬프트 캐시 TTL을 슬쩍 1시간→5분으로 되돌린 정황 포착

• Anthropic이 Claude Code의 프롬프트 캐시 TTL을 1시간에서 5분으로 슬쩍 되돌린 정황이 포착됨
  • 한 사용자가 2026년 1월~4월까지 약 12만 건의 API 호출 로그(JSONL)를 분석해서 밝혀냄
  • 리눅스 워크스테이션 + 윈도우 노트북, 서로 다른 계정 2대에서 동일한 패턴 확인 — 클라이언트 문제가 아니라 서버사이드 변경

타임라인으로 보는 TTL 변화

• 1월 (Phase 1): 5분 TTL만 존재 — 아마 1시간 TTL 티어 자체가 API에 없던 시기
• 2월 1일 ~ 3월 5일 (Phase 2): 1시간 TTL로 완전히 전환됨
  • 33일 연속, 두 대 머신 모두에서 5분 토큰이 0 — 노이즈가 아니라 의도적인 설정
  • 이 기간 비용 낭비율 1.1%로 사실상 제로
• 3월 6~7일 (Transition): 5분 토큰이 다시 나타나기 시작
• 3월 8일 이후 (Phase 4): 5분 TTL이 다시 지배적 — 3월 22일 하루에만 3천만 토큰이 5분 티어로 기록됨

5분 TTL이 이렇게 비싼 이유

• 5분 TTL이면 코딩 중 잠깐 5분만 쉬어도 캐시가 전부 만료됨
  • 다음 턴에서 전체 컨텍스트를 cache_write 비용으로 다시 올려야 함
  • write 비용은 read의 12.5배 — Sonnet 기준 $3.75/MTok vs $0.30/MTok
• 세션이 길고 컨텍스트가 클수록 패널티가 복리로 누적됨
  • 분석 기간 동안 2.2억 토큰이 5분 티어에 write 되었고, 그 토큰들이 57억 번 cache read에 사용됨
  • 1시간 TTL이었으면 대부분이 저렴한 read로 처리됐을 금액

구독 사용자 할당량(Quota)에도 직격탄

• cache write 토큰은 할당량에 정가로 차감되는 반면, cache read는 훨씬 싸게 카운트됨
  • 3월 이후 처음으로 5시간 할당량 한도에 도달하는 구독자가 속출
  • 이슈 작성자 본인도 2026년 3월 전까지는 한 번도 할당량 한도를 쳐본 적이 없었음
• Pro/Max 사용자들이 "갑자기 쿼터가 너무 빨리 소진된다"는 불만이 이 시점과 정확히 일치

작성자의 요청사항

• Anthropic에 TTL 변경 여부 공식 확인/부인 요청
• 5분이 의도된 기본값인지, 1시간이 영구적 의도였는지 명확한 답변 요구
• 1시간 TTL 복원 또는 사용자 설정 가능한 옵션으로 노출 제안
• cache_read 토큰의 할당량 카운팅 방식 공개 요청

---

기술 맥락

• 프롬프트 캐시(Prompt Cache)는 LLM API 호출 시 시스템 프롬프트나 이전 대화 컨텍스트를 서버에 일정 시간 저장해두는 기능이에요. 매번 전체 토큰을 새로 보내는 대신 캐시된 부분은 저렴한 read 비용만 내면 되거든요.
• TTL(Time To Live)은 이 캐시가 얼마나 오래 살아있느냐의 문제인데, Claude Code처럼 긴 코딩 세션에서는 이게 치명적이에요. 코드 리뷰하다 커피 한 잔 마시고 오면 5분은 금방 지나거든요. 그 사이에 캐시가 만료되면 수만 토큰의 컨텍스트를 write 비용(read의 12.5배)으로 다시 올려야 해요.
• 이 이슈가 흥미로운 건 분석 방법론이에요. Claude Code가 ~/.claude/projects/ 아래 JSONL 파일에 모든 API 호출 메타데이터를 남기는데, 여기에 캐시 티어별 토큰 사용량이 기록되거든요. 두 대의 독립된 머신에서 동일한 패턴을 확인함으로써 클라이언트 문제가 아닌 서버사이드 변경임을 입증한 게 깔끔해요.
• 할당량(Quota) 이슈도 연결되어 있어요. Pro/Max 구독은 비용이 아니라 할당량으로 제한되는데, cache write가 정가로 차감되니까 TTL이 짧아지면 같은 작업을 해도 할당량이 훨씬 빨리 소진돼요. "갑자기 쿼터가 빨리 닳는다"는 불만의 근본 원인이 여기 있었던 거예요.