[Claude][운영] Claude Opus 5에서 cache_read_input_tokens는 0인데 cache_creation_input_tokens만 커질 때 tool result tail을 어떤 기준으로 다시 자르나

IT 리서치 노트

[Claude][운영] Claude Opus 5에서 cache_read_input_tokens는 0인데 cache_creation_input_tokens만 커질 때 tool result tail을 어떤 기준으로 다시 자르나

Claude Opus 5에서 tool use를 길게 돌리다 보면 cache_read_input_tokens는 0인데 cache_creation_input_tokens만 다시 커지는 turn을 자주 만난다. 2026년 8월 28일 KST 기준 Anthropic 문서를 다시 보면 이 현상은 단순한 메시지 diff뿐 아니라 tool result 모양, thinking budget, tool_choice, breakpoint 위치 변화로도 생긴다. 이 글은 write-only turn을 만났을 때 어디서 tail을 다시 분리해야 같은 incident를 짧게 재현할 수 있는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 cache_read_input_tokens=0인데 cache_creation_input_tokens만 커질 때는 먼저 tool result 뒤 tail, 그다음 thinking 설정, 마지막으로 uncached 요약·시간값 같은 짧은 동적 꼬리를 순서대로 나눠 확인하는 편이 빠르다. write-only turn은 보통 prefix가 완전히 달라졌다는 뜻이므로, 긴 본문보다 breakpoint 뒤에 새로 붙은 꼬리를 먼저 의심해야 한다.

앞단으로는 cache miss 필드 표준화 글과 messages_changed와 tools_mismatch split 글이 연결된다. 이번 글은 그 다음 단계인 usage 값만 보고도 tail을 어디서 다시 분리하고 어떤 로그와 응답을 먼저 확인할지 정하는 후속편이다.

2. 어디서 실제로 막히는가

현장에서 가장 흔한 실수는 cache_read_input_tokens=0을 보자마자 사용자 질문이 달라졌다고 적는 것이다. 하지만 prompt caching 문서는 tool_choice, thinking configuration, breakpoint 위치가 같아야 cache가 유지된다고 설명하고, extended thinking 문서는 budget 하나만 바뀌어도 cache를 다시 만든다고 예시를 든다.

두 번째 실수는 tool result 전체를 prefix에 그대로 묶어 두는 것이다. tool result JSON은 키 순서, 배열 길이, optional field 유무가 조금만 달라도 tail이 흔들릴 수 있다. 특히 동일한 의미의 tool output인데 serializer나 field ordering이 바뀐 경우에는 messages_changed보다 tool result tail drift로 적는 편이 더 정확하다.

세 번째 실수는 usage 세 필드를 한 줄로 기록하지 않는 것이다. cache_creation_input_tokens만 보고 비용이 갑자기 늘었다고 적으면, 실제로는 input_tokens가 작은 uncached tail인지, cache 자체가 새로 쓰인 turn인지 구분이 어렵다. context windows 문서가 세 필드를 합쳐 보라고 설명하는 이유가 여기에 있다.

• 증상: follow-up turn에서 read는 0인데 write만 다시 크게 잡힌다.
• 실패: 사용자 질문 한 줄만 바뀌었다고 사건을 요약한다.
• 막힘: tool result serializer 변화와 thinking budget 변화를 같은 층으로 적는다.
• 누락: input_tokens, cache_read_input_tokens, cache_creation_input_tokens를 한 줄에 저장하지 않는다.

헷갈리는 신호	실제 분기	먼저 남길 값
tool call 뒤 write만 커짐	tool result tail drift	tool schema hash, tool result hash, tail block count
같은 tool result인데 write 재발	thinking or tool_choice drift	effort, budget_tokens, tool_choice
tail은 짧은데 write 큼	breakpoint placement drift	cache_control 위치와 uncached summary field

3. 실무에서 적용하는 순서

가장 짧은 운영 순서는 다섯 단계다. 첫째, 세 usage 필드를 같은 메모 항목에 저장한다. 둘째, 그 turn이 tool result 직후인지 표시한다. 셋째, tool result 블록만 떼어 hash나 field count를 남긴다. 넷째, thinking budget과 tool_choice를 같은 시각으로 묶는다. 다섯째, 그래도 설명이 안 되면 cache diagnostics로 divergence 위치를 확인한다.

1. usage 세 필드를 한 줄로 저장한다.
2. tool result 직후 turn인지 먼저 표시한다.
3. tool result tail과 user follow-up tail을 분리해 기록한다.
4. thinking budget, effort, tool_choice를 같은 묶음으로 남긴다.
5. 수작업 비교 전에 cache diagnostics를 켠다.

실제 운영에서는 diagnostics 설정을 입력하고, 이전 message id를 조회하고, 재실행 응답을 저장하고, usage 로그와 tool result 로그를 비교하고, 오류 응답이 있으면 다시 확인하는 식으로 절차를 고정하는 편이 좋다. 같은 incident를 여러 사람이 볼 때도 이 메모 순서가 있으면 파일, 응답, 로그, 설정을 같은 이름으로 정리하기 쉽다.

실무에서는 breakpoint 앞은 길고 안정적으로, breakpoint 뒤는 짧고 흔들리는 값만 남기는 편이 안전하다. tool result가 큰 워크플로라면 tool output 전체를 캐시 구간에 묶기보다, 재사용 가능한 구조화 결과와 매 turn 달라지는 follow-up tail을 따로 나누는 편이 write-only turn을 줄인다.

tail split 메모 예시

stable_prefix=system + tool_schema + prior_summary
tail_1=tool_result_json
tail_2=user_followup
if write_only_turn:
  compare tail_1 hash
  compare thinking budget
  then move breakpoint

같은 흐름에서 더 앞단 판단이 필요하면 rollback 순서 글과 append-only change 관리 글을 같이 보면 좋다. 거기서 rollback 층을 고정한 뒤에야 이번 tail split이 제대로 의미를 가진다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 2026년 8월 28일 KST 기준 Anthropic prompt caching 문서의 troubleshooting 구간이다. 여기서는 cache miss를 볼 때 tool_choice, thinking configuration, breakpoint 위치를 같이 고정해야 한다는 전제를 먼저 확인해야 한다.

Anthropic prompt caching 문서는 cache miss를 볼 때 tool_choice, thinking 설정, breakpoint 위치를 함께 점검하라고 안내한다.

즉 cache_read_input_tokens=0이 떴다고 바로 메시지 전문 차이로 몰아가면 안 된다. tail에 붙인 tool result나 thinking budget이 prefix를 다시 만들었는지 먼저 분리해서 확인해야 한다.

두 번째 자료는 extended thinking 문서의 multi-turn 예시다. 같은 대화라도 budget이 바뀌면 셋째 요청에서 cache를 다시 만든다는 점이 그대로 보인다.

Anthropic extended thinking 문서는 budget 변경만으로도 cache_creation_input_tokens가 다시 커질 수 있음을 예시로 보여 준다.

이 장면이 중요한 이유는 tail split 판단이 단순히 tool result 길이의 문제가 아니라는 점 때문이다. tool result가 그대로여도 thinking budget을 흔들면 같은 증상이 나온다.

세 번째 자료는 context windows 문서다. Anthropic은 prompt caching을 쓰면 input count가 input_tokens, cache_read_input_tokens, cache_creation_input_tokens 세 값으로 나뉜다고 설명한다.

Context windows 문서는 세 usage 필드를 합쳐 봐야 실제 입력 크기를 해석할 수 있다고 설명한다.

그래서 cache_creation_input_tokens만 보고 tail이 얼마나 커졌는지 단정하면 안 된다. tail split 전후 비교에서는 세 필드를 같은 줄에 남겨야 한다.

네 번째 자료는 release notes다. 2026년 5월 13일자로 cache diagnostics public beta와 cache_miss_reason이 추가됐다는 점을 다시 확인할 수 있다.

Anthropic release notes는 cache diagnostics beta header와 cache_miss_reason 추가를 공지한다.

운영에서 cache_read_input_tokens=0이 반복될 때는 payload diff를 수작업으로 복기하기보다 diagnostics를 켜고 tail divergence 위치를 먼저 확인하는 편이 낫다.

실무에서는 어떤 경우에 tail을 다시 자를지 표로 남겨 두는 편이 빠르다. 아래 표는 cache_read_input_tokens=0인데 write만 커지는 상황을 가장 자주 세 갈래로 나누는 기준이다.

Claude cache write-only turn이 나왔을 때 tail 원인을 나누는 기준표다.

이미 messages_changed와 tools_mismatch split 글이 첫 갈래를 정리했다면, 이번 표는 그 다음 단계인 write-only usage 해석에 집중한다.

마지막 자료는 incident 메모 예시다. payload 전문을 복사하는 대신 tail 판단에 필요한 최소 필드를 한 줄로 고정하는 편이 재현성이 높다.

cache_read_input_tokens가 0으로 떨어질 때 남길 incident 메모 예시다.

같은 Claude branch에서는 cache miss 필드 표준화 글이 앞단이고, 이번 예시는 그 필드 세트에서 tail split 판단값만 더 좁혀 놓은 버전이다.

5. 주의사항과 리스크

첫 번째 리스크는 tool result를 안정 prefix에 너무 일찍 포함시키는 것이다. 두 번째 리스크는 thinking budget을 실험적으로 바꾸면서 동일 incident 비교라고 적는 것이다. 세 번째 리스크는 diagnostics를 켜지 않고 payload 전체 diff를 사람 손으로만 복기하는 것이다.

운영 메모에는 최소한 tool_choice, budget_tokens, cache_read_input_tokens, cache_creation_input_tokens, tail_after_breakpoint 다섯 값은 남기는 편이 좋다. 이 다섯 값이 없으면 write-only turn이 어디서 시작됐는지 다시 추적하는 시간이 길어진다.

• write-only turn은 대개 breakpoint 뒤 꼬리가 달라졌다는 신호다.
• tool result drift와 thinking drift는 같은 사건명이 아니다.
• diagnostics를 켜면 tail divergence 위치를 더 짧게 찾을 수 있다.

6. 결론

Claude Opus 5에서 cache_read_input_tokens=0인데 write만 커질 때는 사용자 질문보다 tail 구조를 먼저 분리하는 편이 맞다. tool result 뒤 꼬리, thinking 설정, 짧은 동적 값 순으로 확인하고 저장하면 같은 cache incident를 훨씬 짧게 재현할 수 있다.

다음으로 branch를 더 좁히려면 rollback 뒤 Sonnet fallback 쪽으로 내려가기보다, 먼저 오늘 정리한 write-only tail 기준을 운영 메모에 고정하는 편이 실익이 크다. 앞단 글인 messages_changed와 tools_mismatch split 글에 이 후속편을 연결해 두면 Claude incident 사다리가 더 자연스러워진다.

모델 fallback까지 바로 이어서 정리하려면 새 후속편인 Sonnet 5 fallback checklist 글로 내려가 thinking 설정, max_tokens, cache 재생성 메모를 같은 흐름으로 붙여 두는 편이 좋다.

7. 참고 링크

1. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
2. https://platform.claude.com/docs/en/build-with-claude/extended-thinking
3. https://platform.claude.com/docs/en/build-with-claude/context-windows
4. https://docs.anthropic.com/en/release-notes/api