Claude Code 사용을 시작했는데, 캐시 읽기(cache-read)가 사용량의 90%를 넘어서 뭔가 잘못하고 있는 것 같아요.

높은 캐시 읽기는 정상이지만, 매 턴마다 무엇을 다시 읽느냐가 관건입니다. /context를 실행해서 무엇이 윈도우를 채우고 있는지 확인하세요: MCP 도구 정의, CLAUDE.md 및 메모리 파일이 매 턴마다 다시 전송되므로, 사용하지 않는 서버는 /mcp로 비활성화하세요. 관련 없는 작업 사이에는 /compact나 /clear를 사용하세요. /model로 세션 도중에 모델을 전환하는 것도 전체 컨텍스트를 캐시되지 않은 상태로 다시 읽게 만듭니다. 캐시는 구독 시 메인 세션에서는 약 1시간 동안 유지되지만 서브 에이전트의 경우 5분 정도밖에 안 가므로, 긴 유휴 시간이나 많은 서브 에이전트는 컨텍스트 비용을 다시 발생시킵니다. 토큰이 실제로 어디에 쓰였는지 보고 싶다면 ccusage로 ~/.claude/projects의 로컬 로그를 읽어보세요.

90% 캐시 읽기는 정상적인 부분입니다. 제가 볼 부분은 오케스트레이터 스레드 자체입니다. 매 턴마다 전체 기록을 다시 보내기 때문에, 일주일 동안 살아있는 앱 스레드는 무언가를 위임할 때마다 일주일 치의 기능 관련 대화를 매번 다시 읽고 있는 셈입니다.

보통 도움이 되는 방법: 서브 에이전트에게 전체 보고서 대신 3줄(무엇이 변경되었는지, 어떤 파일인지, 무엇이 깨졌는지)로 요약해서 보고하게 하고, 기능별로 짧은 상태 파일에서 시작하는 새로운 오케스트레이터를 만드세요. CLI를 사용 중이라면 /context를 전후로 실행해보세요, 차이가 꽤 명확할 겁니다.

도구 호출을 기록하고 Claude에게 분석 및 최적화를 요청해보세요.

모든 작업을 Opus로 하지 않는 걸 추천합니다. 그리고 서브 에이전트를 쓰면 Opus+Sonnet 조합이 훨씬 더 비쌉니다. 대신 Sonnet Medium을 쓰거나, 세션 한도의 20% 정도만 Opus Medium으로 가이드를 잡고 나머지는 Sonnet을 쓰세요. Pro 플랜은 Opus를 마음껏 쓸 수 있는 곳이 아닙니다.

구독 중이라면 캐시 읽기 비중을 99% 이상으로 맞추는 걸 목표로 하세요.

맞기도 하고 아니기도 합니다.

캐시 읽기가 사용량의 대부분을 차지하는 건 정상입니다. 하지만 그렇게까지 높다고요? 아마 100만 컨텍스트까지 가는 너무 긴 세션을 운영하고 계신 것 같네요.
오랫동안 같은 세션에 머무는 걸 좋아하신다면, 최대 컨텍스트를 500k~600k로 설정하세요(저는 550k로 설정했습니다).

그렇게 많은 컨텍스트가 실제로 필요하지 않고 자주 수동으로 압축하고 싶지 않다면, 다음 중 하나를 시도해보세요. 512k는 전체 사용 가능한 컨텍스트 크기의 절반이며 요청당 비용이 누적되기 전에 압축됩니다:

/autocompact 512k
/autocompact 420k
/autocompact 384k

아니면 개발에 실제로 필요하다고 느껴지는 크기로 설정하세요. 저는 개인적으로 420k로 설정해두었습니다.

그 외에, 캐시 읽기가 90% 이상인 것은 좋은 현상입니다. 비용이 훨씬 적게 들고 장기 실행 세션에서는 꽤 일반적인 모습이니까요.

90% 이상의 캐시 읽기 비율은 정상이며 실제로는 토큰을 절약해주는 것이지만, Pro 한도가 그렇게 빨리 소진된 이유는 긴 '앱 스레드' 오케스트레이터 때문입니다. 긴 오케스트레이터 스레드에서의 매 턴은 계속 커지는 전체 기록을 다시 읽습니다. Pro 플랜에서 제 주간 한도를 지켜준 방법은 영구적인 오케스트레이터 채팅을 버리고 상태를 디스크의 짧은 마크다운 핸드오버 파일에 유지하는 것이었습니다. 기능별로 새로운 세션을 시작하고, 완료되면 핸드오버 파일을 업데이트하게 하세요. 그리고 Opus는 계획이나 까다로운 버그 해결에만 엄격히 사용하고, 편집은 Sonnet이 하게 하세요.

하루 만에 주간 한도 30%를 다 썼네.
작업할 때 이거 관리할 방법 좀 알려줄 사람?

네, 구독 중이라면 캐시 읽기를 1시간으로 설정해야 하고, 에이전트가 항상 살아있도록 50분마다 메시지를 보내는 스크립트가 필요합니다.