이전의 저는 하나의 세션 안에서 모델과 에포트(Effort)를 빈번하게 전환하곤 했습니다. 조사나 정해진 처리 등 깊은 사고가 필요 없는 것은 Sonnet으로 낮추고, 개발 구현의 난관에는 Opus(사용 가능했던 기간은 Fable)로 올리며, 깊게 생각하게 하고 싶은 턴에는 에포트를 xhigh로 설정했습니다. 태스크마다 최적의 설정을 선택하는 현명한 사용법을 쓰고 있다고 생각했습니다.

하지만 그것은 착각이었습니다. 전환할 때마다 그때까지 쌓아온 프롬프트 캐시(Prompt Cache)를 버리고, 대화 이력의 재계산 비용을 다시 지불하고 있었기 때문입니다.

계기는 Claude Code에서 모델을 전환하려고 할 때 나타난 이 경고였습니다.

Switch model?
Your next response will be slower and use more tokens
This conversation is cached for the current model. Switching to Fable 5 means
...

"캐시가 있는데 왜 전체 이력(full history)을 다시 읽는가". 조사해서 알아낸 것을 결론부터 말씀드리겠습니다.

결론

• 프롬프트 캐시가 아끼는 것은 통신이 아니라 계산이다. 전환은 그 계산을 다시 하는 것 = 과금의 재발생
• 모델 전환은 캐시를 전부 파괴하고, 에포트 전환은 대화 이력만큼의 캐시를 파괴한다. 둘 다 '이력의 재계산'이라는 숨겨진 비용이 따른다. 단, 재계산은 단 한 번뿐인 지출이다.
• 남은 세션 동안 계속 사용할 것이라면, 전환하여 비용을 상쇄(amortize)하는 것이 정답이다. 비용이 많이 드는 경우는 몇 턴마다 위아래로 요동치는 경우다. 서브 에이전트(Sub-agent) 위임도
• 비용을 낮추는 기법이 아니다. 고정비가 존재하므로 작은 태스크에서는 회수할 수 없다.

전제 조건 3가지. 요금은 2026-07 시점의 공개 단가(Sonnet 5의 $2/$10는 2026-08-31까지의 도입 가격, 이후 $3/$15). Claude Code의 기본 캐시 TTL은 5분. 필자가 결제 금액을 실측한 기사가 아니라, 공식 문서와 API 사양을 정리한 것입니다.

원리 ─ 캐시되는 것은 텍스트가 아니라 계산 결과

캐시의 실체는 보낸 텍스트가 아니라, **해당 모델의 가중치(weight)로 계산한 KV(key/value) 텐서(tensor)**입니다. 대화 이력을 포워드 패스(forward pass)에 통과시켰을 때의 중간 상태입니다.

비유하자면, 대화 이력(매번 보내는 텍스트)은 두꺼운 자료, 모델은 그것을 읽는 담당자, KV는 읽기를 마친 담당자의 머릿속에 형성된 이해입니다. 캐시가 보관하는 것은 자료의 복사본이 아니라, 담당자의 이해입니다.

모델을 전환하면 담당자가 바뀝니다. 자료는 같더라도 전임자의 머릿속에 있는 이해는 이어받을 수 없습니다. 새로운 담당자가 처음부터 다시 읽어야 합니다. 경고문의 "the full history gets re-read"는 글자 그대로의 의미였습니다. 공식 마이그레이션 가이드에서도 모델 문자열을 바꾸면 기존 캐시는 무効화되며, 새 모델로 다시 작성된다고 명시하고 있습니다. 즉, 경고문은 "캐시가 있는데 사용하지 않는다"가 아니라, **"새로운 모델에게는 이것이 첫 번째 요청과 같다"**라고 말하고 있는 것입니다.

매번 전체를 보내는데 왜 저렴해지는가

Messages API는 스테이트리스(stateless)이며, 클라이언트는 매 요청마다 대화 이력을 통째로 보냅니다. 100번째 턴에서도 1번째 턴부터의 모든 이력이 네트워크를 타고 흐릅니다. 그런데도 캐시 히트(cache hit)분의 과금은 1/10이 됩니다. 언뜻 보면 모순적입니다.

비결은 과금 기준이 전송 바이트 수가 아니라 서버가 소비한 계산량이기 때문입니다. 자료를 건네주는 것(통신)은 순식간이며, 비용의 본체는 그것을 읽어 들여 이해를 구축하는 것(prefill ─ 모든 입력 토큰에 대한 forward pass)에 있습니다. 서버는 받은 프롬프트의 전반부가 지난번과 일치하면, 거기까지의 이해가 머릿속에 남아 있으므로 뒷부분만 읽으면 됩니다. 아끼는 것은 통신이 아니라 계산입니다.

캐시가 서버 측에 있다는 것은 API 응답의 usage에서 확인할 수 있습니다 (값은 설명을 위한 예시입니다).

"usage": {
"input_tokens": 300,
"cache_creation_input_tokens": 1500,
...

cache_read_input_tokens

는 "서버가 자신의 캐시에서 가져올 수 있었던 분량"에 대한 신고입니다. 캐시가 클라이언트 측에 있다면, 서버가 이 숫자를 보고할 방법이 없습니다.

방증 (TTL / 모델별 캐시 / cache_control)

• TTL이 존재함 (5분 / 1시간). 클라이언트가 단순히 보유하고 있는 텍스트에는 만료(expire) 개념이 필요하지 않습니다. 서버가 GPU 메모리나 스토리지를 해제해야 하므로 TTL이 존재합니다.
• 모델마다 별도의 캐시가 생성됨. 클라이언트가 텍스트를 단순히 보유하고 있는 것이라면, 모델에 의존할 이유가 없습니다.
• cache_control은 클라이언트가 보내는 "여기까지를 캐시해달라"는 마커일 뿐이며, 캐시의 실체를 보내는 것이 아닙니다. 이는 브레이크포인트(breakpoint)를 지정하는 지시사항에 불과합니다.

무엇을 바꾸면 어디까지 깨지는가

캐시는 tools (도구 정의) $\rightarrow$ system (시스템 프롬프트) $\rightarrow$ messages (대화 기록) 계층으로 쌓이며, 변경한 계층과 그 이후의 계층이 무효화됩니다 (이전 계층은 유지됩니다).

에포트(Effort, low $\sim$ max)는 새로운 모델에서 사고(thinking)의 깊이를 제어하는 파라미터입니다. 공식 문서에는 "thinking 설정 변경(활성화·비활성화·budget)은 대화 기록의 캐시를 무효화한다"라고 명시되어 있습니다.

주의해야 할 점은, "messages 계층만" 바뀌더라도 충분히 치명적이라는 것입니다. system과 tools는 크더라도 고정된 크기지만, messages는 대화가 진행될수록 커지는 거물입니다. 긴 세션에서는 "기록을 다시 읽는 것"이라는 가장 무거운 부분을 그대로 감당해야 합니다.

요금에 미치는 영향

캐시 단가는 기본 입력 단가 대비 cache read가 0.1배, cache write가 1.25배(5분 TTL) 또는 2배(1시간 TTL)입니다. 출력 토큰은 캐시와 무관하게 항상 전액 부과됩니다. Claude Code는 브레이크포인트를 자동으로 전진시켜 기록을 점진적(incremental)으로 캐싱하므로, 긴 세션의 입력은 "0.1배의 거대한 전반부 + 1배의 작은 차이분"이 됩니다.

하지만 저렴해질 뿐, 짧아지지는 않습니다. 기록의 토큰 수, 컨텍스트 윈도우(context window)의 소비, auto-compact의 발화 타이밍은 변하지 않습니다. "캐시가 작동하니까 도구 출력을 대량으로 쌓아도 괜찮다"는 성립하지 않으며, 밀어 넣은 raw dump는 이후 계속해서 윈도우를 점유하게 됩니다.

속도 제한(Rate Limit)에도 영향을 줍니다. API의 ITPM(input tokens per minute)은 cache read 토큰을 카운트하지 않습니다 (공식적으로 "Cache-aware ITPM"이라고 명시됨. Haiku 3.5만 예외).

전환 비용은 두 종류: 일회성 재읽기와 그 이후의 지속 비용

전환하는 순간 지불하는 것은 기록의 재읽기(cache write)입니다. 모델을 전환하면 모든 계층, 에포트를 전환하면 messages 계층이 대상입니다. 이는 단 한 번만 발생하며, 완료되면 이후에는 다시 캐시가 적용됩니다.

간과하기 쉬운 것은 지속 비용입니다. 100k의 기록을 가진 세션의 1턴당 입력 비용은, Sonnet 5를 유지할 경우 100k $\times$ $0.20 = $0.02, Opus 4.8을 유지할 경우 100k $\times$ $0.50 = $0.05입니다. 차이는 턴당 $0.03입니다. 반면, 한 번의 재읽기는 100k $\times$ $10 (Opus의 1시간 TTL cache write) = $1.00이므로, 입력 단가 차이만으로도 약 33턴이면 재읽기 비용을 추월합니다. 출력 단가 또한 $10 대 $25로 벌어지기 때문에 실제로는 훨씬 더 빠릅니다.

에포트의 경우, 지속 비용의 내용이 다릅니다. 모델이 바뀌지 않으므로 단가는 올라가지 않지만, 대신 매 턴의 사고(thinking) 토큰 생성량이 늘어납니다. 모델은 단가, 에포트는 사고량 $\dashv$ 레이어는 다르지만, 둘 다 "한 번의 재읽기" 이후에 계속해서 발생하는 비용입니다.

여기서 운영의 축이 나옵니다. 남은 세션 전체에서 상위 모델(또는 높은 에포트(Effort))이 필요하다면, 망설임 없이 전환하십시오. 다시 읽는 비용은 이후의 턴(turn)에서 상쇄됩니다. 비용이 많이 드는 것은 "몇 턴만 올렸다가 바로 되돌리는 것"을 반복하는 것입니다. … 서두에서 제가 사용했던 방식 그대로군요 😅

위임은 「비용을 낮추는 기법」이 아니다

"조금만 더 상위 모델을 쓰고 싶다"라고 할 때의 대안이 서브 에이전트(sub-agent)로의 위임입니다. 부모(parent)는 그대로 둔 채, 서브 에이전트를 model 지정으로 기동하여 그 태스크만 맡기는 방식입니다. 하지만 위임 비용을 "인수인계 프롬프트 분량만큼"이라고 계산하는 것은 잘못이며, 실제 지불은 다음과 같이 이루어집니다.

특히 효과가 큰 것은 system prompt와 도구 정의의 고정비입니다. 신규 에이전트는 매번 제로 베이스에서 시작하므로, 태스크가 작을수록 고정비가 상대적으로 높아집니다. Anthropic의 자체 데이터에 따르면, 단일 에이전트는 채팅 대화의 약 4배, 멀티 에이전트는 약 15배의 토큰을 소비합니다. 위임은 비용을 낮추는 기법이 아니라, 토큰을 더 쓰더라도 문맥(context)과 단가를 분리하는 기법입니다.

손익 분기점

위임이 부모 모델 전환보다 저렴해지는 조건은 하나의 부등식으로 요약됩니다.

인수인계 프롬프트 P + 재발견 비용 D < 대화 이력 H

인수인계는 부모의 출력이며, 이력의 다시 읽기는 상위 모델로의 cache write입니다. 1시간 TTL 기준이라면 Sonnet의 output 단가 $10와 Opus의 cache write 단가 $10가 일치하므로, 비교는 토큰 수만의 싸움이 됩니다 (이 일치는 Sonnet 5의 도입 가격 전제하에 2026-09 이후에는 깨지며, 기본 5분 TTL이라면 분기점이 P + D < 0.625 × H로 이동하지만, P와 D가 작다면 결론은 같습니다).

중요한 것은 좌변의 D입니다. 서브 에이전트는 부모가 읽은 파일이나 도구 결과를 가지고 있지 않으므로, 필요하다면 상위 모델의 단가로 다시 읽어야 합니다. 태스크가 대화 문맥에 의존할수록 D가 커지며 우위가 사라집니다. 게다가 Claude Code에서는 문맥을 통째로 계승하면서 모델만 올리는 것이 불가능합니다. 컨텍스트를 완전히 계승하는 fork는 model 지정을 무시하기 때문에, 상위 모델을 사용하려면 수동으로 인수인계해야 하며, 인수인계는 반드시 손실(lossy)을 동반합니다.

판단 기준

그대로 부모 모델로 계속한다 ─ 태스크가 작고, 위임의 고정비나 전환 시의 다시 읽기 비용을 회수할 수 없을 때. 현재 모델로 해결할 가능성이 있을 때.

부모 모델을 전환한다 ─ 남은 세션 전체에서 상위 모델이 필요할 때 (다시 읽기 비용이 상쇄됨). 태스크가 대화 문맥 전체를 요구할 때. 아직 초반이라 이력이 작을 때.

서브 에이전트에게 던진다 ─ 난도가 높지만 "경계가 명확"하여 짧은 프롬프트로 작성 가능할 때. 직후에 저렴한 모델로 돌아갈 때. 필요한 정보를 대화 이력이 아닌 파일로부터 재도출할 수 있을 때.

에포트(Effort)도 같은 잣대를 적용합니다. 남은 시간 내내 깊은 사고가 필요하다면 계속 올려서 상쇄시키고, 특정 지점만 필요하다면 그 몇 턴 동안만 올립니다. 다만 상하 이동이 일어날 때마다 messages 캐시가 다시 작성되므로, 자주 움직이지 말고 "결정적인 순간"에 몰아서 올려야 합니다.

그리고 단가보다 우선해야 할 판단이 하나 있습니다. lossy한 인수인계로 인해 답을 틀린다면, 재시도 비용이 절약한 비용을 가볍게 상회합니다. 위임은 "이 문맥은 잃어버려도 괜찮은가"를 기준으로 먼저 결정하는 것이 안전합니다.

운영 체크리스트

• 모델과 에포트 모두, 전환할 거라면 초반에 수행하라. 이력이 수만 토큰으로 커진 후가 가장 비싸다.
• 몇 턴마다 모델을 오르내리는 것을 멈춰라. 올릴 거라면 상쇄할 수 있는 길이로, 한꺼번에.
• 용도에 따라 모델을 나눈다면, 버릴 이력을 높은 단가로 다시 쓰지 않도록 /clear를 활용하라.

해서 -
원래 설정으로 되돌리려면 TTL(기본 5분) 이내에. 캐시가 살아있다면 재과금되지 않습니다. -
한도를 지키는 가장 큰 레버는 모델 선택 그 자체입니다. 캐시 최적화보다 어떤 모델로 실행할지가 더 효과적입니다.

요약

• 캐시의 실체는 KV 텐서(KV Tensor)입니다. 모델의 가중치(Weights)에 종속되므로, 모델 간에는 공유할 수 없습니다.
• 매번 전체 텍문이 전송되고 있습니다. 절약되는 것은 통신이 아니라 prefill(프리필)이라는 계산입니다. 비용은 저렴해지지만 길이는 짧아지지 않습니다. 컨텍스트 윈도우(Context Window)의 소비량은 변하지 않습니다.
• 모델 전환은 전 계층(All layers)을, 에포트(Effort) 전환은 메시지 계층(Messages layer)을 태웁니다(burn). 둘 다 "단 한 번의 다시 읽기"와 "그 이후의 지속적인 비용"이라는 2단계 구조를 가집니다.
• 남은 분량이 길다면 전환하여 상각하고, 조금 남았다면 움직이지 마십시오. 위임(Delegation)은 비용을 낮추는 기술이 아니라, 문맥(Context)과 단가(Unit price)를 분리하는 기술입니다.

과금에 대한 직관이 어긋나는 이유는, 사용자는 바이트(Byte) 수로 계산하고 있는데 과금은 계산량(Computation)으로 계산하기 때문입니다. 이 한 가지만 파악하고 있다면 모델, 에포트, 위임 모두 동일한 척도로 측정할 수 있습니다. 서두의 경고문이 말하고자 했던 것도 결국 "새로운 담당자에게 자료를 처음부터 다시 읽게 만들 것입니다"라는 뜻이었습니다.

참고

• Prompt caching (Anthropic) ─ 무엇을 변경할 때 어느 계층의 캐시가 깨지는지에 대한 목록
• Extended thinking (Anthropic) ─ thinking 설정 변경이 대화 이력 캐시를 무효화한다는 내용
• Effort (Anthropic) ─ 에포트가 budget_tokens의 후속이라는 내용
• Pricing (Anthropic)
• Rate limits — Cache-aware ITPM (Anthropic)
• Usage limit best practices (Anthropic Help Center)
• Models, usage, and limits in Claude Code (Anthropic Help Center)
• How we built our multi-agent research system (Anthropic) ─ 에이전트의 토큰 소비가 대화의 4배 / 15배라는 수치의 출처

Discussion