Claude Code의 컨텍스트 압축 기준을 400K로 낮춰 요청당 비용을 38% 절감함

이게 무슨 만능 레시피 같은 건 아님. 그냥 내가 내 작업 방식에 맞춰서 Claude Code를 튜닝한 방법일 뿐이고, 너한테는 다른 설정이 더 잘 맞을 수도 있어.

컨텍스트 윈도우

모든 요청은 전체 컨텍스트를 모델로 보내. 1M 윈도우 모델이라도 Claude Code는 967K 근처에서야 압축을 시작하니까, 긴 세션의 뒷부분이 제일 돈 많이 깨지는 구간이지. 나 같은 경우엔 메인 스레드 비용의 3분의 2(66%)가 컨텍스트 400K 넘는 요청에서 나갔거든.

그래서 "autoCompactWindow": 400000으로 설정하고 한 달 전이랑 설정 바꾼 후 일주일치를 비교해 봤어. 메인 스레드만 따진 거고, 설정 전 약 23K 요청, 설정 후 19K 요청 기준이야:

• 요청당 컨텍스트: 412K → 219K

• 요청당 비용: −38% (각 모델 API 정가 기준)

이건 그냥 한 사람의 전후 비교일 뿐이고, 통제된 실험은 아니라는 점 참고해.

요약 비용

윈도우를 작게 잡으면 그만큼 압축을 더 자주 하게 돼. 한 달에 17번 하던 요약을 일주일 만에 81번이나 하게 됐거든. 기다리는 시간만 103분, 한 번당 76초씩 걸린 셈이지. 요약하고 나면 모델이 이미 봤던 파일들을 다시 읽는 경우가 많아서 좀 짜증 나더라고.

요약 대신 슬라이딩(Slide)

컨텍스트 대부분은 파일 읽기, 테스트 실행, diff 같은 옛날 도구 출력값들이야. 그래서 압축할 때 대화 내용은 그대로 두고, 옛날 출력값들은 "이거 봤던 거니까 필요하면 다시 읽어"라는 짧은 문구로 대체하는 훅을 만들었어. 모델 호출이 없으니까 압축하는 데 밀리초 단위밖에 안 걸려. 물론 /compact 명령어 쓸 때나 슬라이딩만으로 공간 확보가 안 될 때를 대비해서 요약 기능은 백업으로 남겨뒀지.

벤치마크 결과야. Claude Code로 TypeScript 프로젝트를 고정된 테스트 환경에서 돌렸고, Haiku 5.5 모델에 100K 윈도우를 썼어. Claude Code 자체 요약 방식이랑 슬라이딩 방식을 비교한 중앙값이고, Claude Code가 직접 보고한 비용 기준이야:

Task	Cost	Time
A day of work, 307 tests	−19%	−33%
An eval harness, 238 tests	−35%	−28%
A short task with one compaction	+6%	−17%

두 방식 다 테스트는 전부 통과했어.