Claude Code 프롬프트 캐싱 버그: 낭비된 사용량은 누가 책임지나?

예전에 Claude Code가 서브 에이전트, 도구, 훅, 긴 컨텍스트를 다루는 오케스트레이터 스타일 워크플로우에 아직 최적화가 덜 된 것 같다고 글을 썼었지. 사용량이 너무 미친 수준이었거든.

Fable 5.1이 배포된 이후로 캐시 동작을 훨씬 꼼꼼하게 살펴보기 시작했어. 아니나 다를까, 공식 Claude Code 변경 로그를 보니 프롬프트 캐싱 관련해서 심각한 버그가 여러 개 있었던 게 확인됐네.

확인된 수정 사항은 다음과 같아:

- v2.1.260: 도구 결과 뒤에 추가된 Fable 5.1 컨텍스트가 프롬프트 캐싱 적용이 안 돼서, 도구를 호출할 때마다 매번 캐싱 안 된 입력값으로 다시 전송됨.

- v2.1.260: 세션 도중에 Fable 5.1 노력을 변경하면 프롬프트 캐시가 무효화됨.

- v2.1.261: 에이전트 팀 동료들이 두 번째 턴에서 도구/스킬 공지를 다시 보내는 바람에 요청 접두사가 바뀌어서 캐시 미스가 발생함.

- v2.1.265: 서브 에이전트를 재개할 때 도구 목록과 시스템 프롬프트 접두사가 바뀌면서 프롬프트 캐시 재사용이 깨짐.

- v2.1.265: 동료 에이전트와 재개된 서브 에이전트들이 나중 턴에서 SubagentStart 훅 컨텍스트와 미리 로드된 스킬들을 캐시된 접두사 밖으로 밀어내면서 또 캐시 재사용이 깨짐.

Anthropic의 GitHub 트래커에도 수십만 토큰씩 캐시를 통째로 다시 쓰는 버그에 대한 상세한 제보가 올라와 있어. #91514, #91706, #92090 같은 것들이지. 어떤 제보를 보면 8개의 병렬 Fable 5.1 서브 에이전트가 약 40분 만에 290만 토큰을 다시 캐싱했다는 기록도 있어.

이 중 일부는 Fable 관련 문제고, 나머지는 Claude Code 오케스트레이션/캐시 관련 버그야. 결과는 똑같아. 재사용됐어야 할 컨텍스트가 캐싱 안 된 입력값으로 처리되면서 토큰만 낭비되는 거지.

우리처럼 서브 에이전트, 훅, 스킬, 도구, 대규모 컨텍스트를 많이 쓰는 오케스트레이터 중심 환경에서는 이게 특히 치명적이야.

Anthropic이 구독 계정 정보를 그 정도로 상세하게 공개하지 않아서, 이 버그들 때문에 우리 Claude Max 사용량이 정확히 얼마나 날아갔는지는 증명할 방법이 없어.

하지만 사용량이 비정상적으로 높았던 건 사실이고, 이번에 수정된 내용들을 보면 불필요한 토큰 처리를 유발할 만한 요소들이 확실히 있었어.

아직 우리 오케스트레이터 환경에서 최신 버전인 2.1.265/2.1.266을 완벽하게 테스트해보진 못했어. 사용량은 조금씩 나아지고 있는데, 과연 이 수정 사항들이 실제로 유의미한 차이를 만들어낼지 진짜 궁금하네.

내가 더 걱정되는 건 이거야:

프롬프트 캐싱이 경제성 측면에서 핵심인 제품에 어떻게 이런 캐시 관련 퇴보가 수두룩하게 프로덕션까지 넘어올 수 있었을까?

그리고 더 중요한 건, Anthropic의 버그 때문에 이미 날려버린 사용량은 어떻게 보상할 거냐는 거지.

소프트웨어 결함 때문에 Claude Code가 컨텍스트를 계속 캐싱 안 된 상태로 보내서 Max 구독자가 자기 할당량을 의미 없이 날렸다면, Anthropic이 이걸 복구해주거나 크레딧이라도 줘야 하는 거 아냐?

Anthropic이 이 부분에 대해 투명하게 입장을 밝혀야 한다고 봐.

Claude나 Fable 모델이 구려서가 아냐. 오히려 정반대지. 하지만 세계 최고 수준의 코딩 시스템이라고 비싼 구독료를 받으면서 장사할 거면, 그 주변 소프트웨어랑 사용량 관리도 그에 걸맞은 프로급 수준은 맞춰야지.

공식 참조:

- Claude Code 변경 로그: v2.1.260, v2.1.261, v2.1.265

- Anthropic GitHub 이슈: #91514, #91706, #92090

다른 Claude Code / Max 헤비 유저들은 어떤지 궁금하네. 이 캐시 버그들 수정되고 나서 사용량 좀 눈에 띄게 좋아졌어?

관련 게시물:
https://www.reddit.com/r/ClaudeCode/s/QSW2c7aWzp