캐시 읽기 단가 인하가 바꾸는 비용 구조
2026년 9월 1일 공개된 Claude Fable 5.1은 입력 10달러·출력 50달러(백만 토큰당) 가격은 그대로 두고 캐시 읽기 단가만 백만 토큰당 1달러에서 0.25달러로 75% 내렸습니다. Anthropic은 일반 워크로드에서 약 25%, 캐시 재사용이 잦은 에이전트형 워크로드에서는 최대 약 45%까지 비용이 줄어든다고 밝혔습니다. 컨텍스트 윈도우는 100만 토큰으로 동일해, 절감 폭은 순전히 캐시 히트율에 달려 있습니다.
캐시 히트율이 낮으면 가격표는 의미가 없다
프롬프트 캐싱은 캐시 브레이크포인트 이전 구간이 토씨 하나 안 바뀐 채 유지될 때만 히트합니다. 브레이크포인트 이후 내용이 매 호출 바뀌거나 TTL이 지나 캐시가 비면, 그 구간은 다시 캐시 라이트 비용을 물고 시작합니다. 즉 단가 인하는 상한선을 낮췄을 뿐이고, 실제 청구액은 팀이 설계한 캐시 히트율에 좌우됩니다.
설계에서 운영까지: 캐시 히트율 관리 체크리스트
목표 지표부터 숫자로 고정합니다. 캐시 히트율 80% 이상을 1차 목표로 잡고, 캐시 미스 시 발생하는 라이트 비용까지 합산한 실질 절감률을 별도로 계산해야 합니다. 고빈도 에이전트 워크로드의 최대 45% 절감은 팀 워크로드에 그대로 적용되는 수치가 아니라 상한값이므로, 배포 전 자체 골든셋으로 히트율을 실측해 목표를 재설정합니다.
실패 패턴 첫째는 시스템 프롬프트 맨 앞부분에 요청 시각이나 세션 ID 같은 가변 값을 끼워 넣어 매 호출마다 캐시가 통째로 깨지는 경우입니다. 고정 지침·도구 정의·예시는 앞쪽에, 가변 데이터는 뒤쪽에 두는 순서 규칙 하나로 예방됩니다.
둘째, 프롬프트를 단일 블록으로 취급해 브레이크포인트를 하나만 두는 경우입니다. 도구 정의처럼 자주 안 바뀌는 구간과 대화 이력처럼 자주 바뀌는 구간을 별도 브레이크포인트로 나누지 않으면, 이력 한 줄이 늘 때마다 도구 정의 구간까지 재작성 비용이 붙습니다.
셋째, TTL 만료를 감지하지 못해 캐시 라이트 구간으로 조용히 되돌아가는 경우입니다. 세션 간격이 캐시 유효 시간을 넘나드는 배치·야간 작업일수록 이 손실이 누적되므로, 캐시 히트 여부를 매 호출 로그에 남겨야 회귀를 조기에 발견합니다.
넷째, 모델을 5에서 5.1로 옮기면서 캐시 단가표를 갱신하지 않아 비용 대시보드가 실제 청구서와 어긋나는 경우입니다. 모델 전환 체크리스트에 캐시 읽기·라이트 단가 갱신 항목을 못박아 두면 이 격차를 막을 수 있습니다.
운영 체크리스트로는 배포 전 동일 세션 반복 호출 시나리오로 히트율을 측정하는 절차, 캐시 히트 여부·캐시 토큰 수·비캐시 토큰 수를 표준 로그 필드로 남기는 절차, 캐시 대상 구간에 PII·시크릿이 섞이지 않도록 마스킹 대상과 캐시 대상을 분리하는 절차를 갖춰야 합니다.
개선 루프는 주간 단위로 캐시 히트율 추이와 실제 청구 비용을 나란히 놓고 봅니다. 히트율은 그대로인데 비용이 늘었다면 모델 가격 변경을 놓친 신호이고, 비용은 그대로인데 히트율이 떨어졌다면 프롬프트 구조가 바뀐 신호입니다. 두 지표를 같은 변경 로그에 묶어 두면 원인 추적이 빨라집니다.
바로 쓰는 체크리스트
캐시 읽기 단가 75% 인하는 비용 상한을 낮췄을 뿐, 실제 절감은 브레이크포인트 설계와 히트율 관측에 달려 있습니다. 가변 데이터를 프롬프트 뒤쪽으로 몰고, 구간별 브레이크포인트를 나누고, 캐시 히트 여부를 로그 필드로 고정하는 세 가지만 지켜도 절감 폭을 예측 가능한 범위 안에 둘 수 있습니다.
참고 링크
Introducing Claude Fable 5.1 and Claude Mythos 5.1 — Anthropic