Claude Code, 백그라운드 에이전트 대화를 주기적으로 모델에 다시 보냅니다

본문

작업 중인 백그라운드 에이전트의 상태 문구를 만들려고 Claude Code가 약 30초마다 해당 에이전트의 전체 대화를 모델에 보냅니다. 원문 작성자는 이 호출이 에이전트 자신의 모델을 사용하며, 결과는 에이전트 패널의 상태 문구에만 반영된다고 설명합니다. 에이전트가 쉬는 동안에는 요약 호출이 발생하지 않는다는 점은 댓글에 참여한 Anthropic 직원이 덧붙였습니다.

측정 결과와 비용

작성자는 Claude Code의 OpenTelemetry 내보내기에서 query_source = agent_summary를 기준으로 요청을 집계했습니다. 자체 측정 주간에 이 호출은 Claude Code 전체 추정 지출의 16.4%를 차지했고, 주 대화의 15.7%보다 컸습니다. API 요청 비중은 19.7%로 약 5건 중 1건이었고, 입력 토큰 대 출력 토큰 비율은 약 9,000 대 1이었습니다. 지출 수치는 청구서가 아니라 Claude Code가 요청별로 추산한 cost_usd입니다. 구독 이용자는 실제 청구액 대신 사용량 한도 여유가 줄어드는 형태로 영향을 받는다고 원문은 구분합니다.

이 수치는 작성자 팀의 관측값입니다. Anthropic 직원은 원문 댓글에서 telemetry를 보내는 전체 Claude Code 사용자 기준 agent_summary가 API 정가 기준 비용의 약 2%, 요청의 4% 미만이었다고 밝혔습니다. 터미널 사용자의 비용 비중은 약 6%라고 설명했습니다. 따라서 16.4%를 일반적인 사용자나 세션의 비율로 읽어서는 안 됩니다. 백그라운드 에이전트를 많이 쓰는 팀의 측정치와 전체 사용자 평균은 서로 다른 범위를 가리킵니다.

공개된 우회 방법

작성자는 약 80줄짜리 Bun preload 스크립트 no-agent-summary.js를 공개했습니다. 스크립트는 setTimeout과 setInterval을 감싸고, 콜백의 소스 문자열에 [AgentSummary] 같은 식별 문구가 있으면 타이머를 실행하지 않는 핸들을 돌려줍니다. 다른 타이머는 그대로 둡니다. Claude Code 바이너리는 사전 컴파일된 Bun 바이트코드를 사용하고 API 요청도 전역 fetch를 통하지 않아, 작성자는 타이머 콜백의 toString() 결과에서 문자열을 찾는 방식을 택했다고 설명합니다. 지연 시간에는 2^31−1밀리초를 사용합니다. Node와 Bun에서 이보다 큰 값은 1밀리초로 처리될 수 있기 때문입니다.

Linux의 Claude Code 2.1.257부터 2.1.312까지 테스트한 표에서, 약 2분 30초 동안 에이전트를 실행했을 때 훅 없이 요약 호출이 1~5회 발생했고, 훅을 불러오되 타이머를 허용하는 pass 모드에서도 비슷하게 발생했습니다. 요약을 막는 off 모드에서는 테스트한 버전 모두 호출이 0회였습니다. 작성자는 실제 사용 환경에서도 훅 적용 뒤 agent_summary 요청이 0건이었다고 보고합니다. 백그라운드 에이전트와 fork는 계속 작동하지만 패널의 상태 문구는 갱신되지 않습니다. SDK의 task_progress에도 요약이 없습니다.

설치와 한계

훅은 BUN_OPTIONS=--preload <절대 경로>로 적용합니다. Claude Code daemon, PTY 호스트, 미리 실행된 백그라운드 세션은 daemon을 시작한 환경을 물려받으므로, 환경 변수를 바꾼 뒤 claude daemon stop --any로 daemon을 재시작해야 합니다. 이미 실행 중인 세션도 다시 시작해야 합니다. claude -p, cron, CI, 에디터 연동 같은 비대화형 실행 환경에도 변수를 전달해야 합니다.

이 방식은 콜백 안의 문자열에 기대므로 업데이트에서 로그 문구가 바뀌거나 콜백이 래핑되면 매칭에 실패할 수 있습니다. 실패해도 요약 호출이 다시 발생할 수 있어 원문은 업데이트 뒤 OpenTelemetry의 query_source와 로그를 확인하라고 안내합니다. Linux에서만 시험했고 macOS와 Windows는 검증하지 않았습니다. 작성자는 훅으로 인한 시작 시간 차이를 claude --version에서 약 10밀리초에서 17밀리초로 측정했습니다.

작성자에 따르면 공식 SDK 옵션과 환경 변수는 요약을 켤 수만 있고 끌 수는 없었습니다. 주기 간격은 서버 측 설정으로 30~240초 범위에 있으며 기본값은 최솟값입니다. 2.1.310에는 전체 대화 대신 짧은 메모와 더 작은 모델을 쓰는 저비용 모드가 들어갔지만 기본값은 꺼져 있고 서버 플래그로만 바꿀 수 있다고 원문은 설명합니다. Anthropic 직원은 2.1.311 이상에서 프롬프트 캐시를 놓치는 가장 비싼 경우에 대한 수정이 배포됐고, 전체 대화 대신 짧은 메모를 작은 모델에 보내는 더 저렴한 방식을 작업 중이라고 댓글에 남겼습니다.

Hacker News 반응

• @edwinarbus — Claude Code에서 일합니다. 기본 작동 방식은 맞지만, 이 기능은 현재 작업 중인 백그라운드 에이전트에만 적용됩니다. 약 30초마다 요약을 받아 사용자와 Claude Code가 대화를 읽지 않고도 각 에이전트의 작업을 파악합니다. 16.4%는 백그라운드 에이전트를 주로 쓰는 팀의 수치로 보이며 전형적인 세션을 나타내지는 않습니다. 지난주 telemetry를 보내는 Claude Code 사용자 전체에서 agent_summary는 API 정가 기준 비용의 약 2%, 요청의 4% 미만이었고 터미널에서는 비용의 약 6%였습니다. 그래도 상태 문구에 쓰기에는 큰 비용입니다. 프롬프트 캐시를 놓치는 가장 비싼 경우를 수정했고, 전체 대화 대신 짧은 메모를 작은 모델에 보내는 더 저렴한 모드를 작업 중입니다.
• @jakozaur — 직접 시험해 보니 실제 동작하는 것 같지만 더 복잡합니다. 서브에이전트에만 해당하고 워크플로에는 영향이 없어 보입니다. 대부분 캐시된 읽기라 짧은 컨텍스트의 서브에이전트는 비용이 적고, 긴 컨텍스트는 더 많이 듭니다. 제 Claude Code 세션에서는 많아야 약 8%였습니다.
  • @lemming — 8%도 여전히 정당화하기 어려워 보입니다. 끌 수 없다면 사용량의 큰 부분입니다.
• @HeavenFox — 전체 대화를 보내 요약한다면 토큰 대부분이 캐시 적중일 텐데 비용이 그렇게 큰가요?
  • @buzer — 캐시 TTL이 올해 초 5분으로 바뀌지 않았나요? 업데이트 간격에 따라 캐시가 만료될 수도 있습니다.
  • @maxbond — 한 시간입니다. 상태 표시줄에서 만료 시간을 볼 수 있고 /usage에서도 확인할 수 있습니다.
• @quantbuilder — 터미널 아래 상태 표시줄이 아니라 에이전트 패널의 백그라운드 에이전트별 요약을 말하는 것 아닌가요? 일반 세션 하나만 쓰면 비용이 들지 않는 걸까요? disableAgentView를 켜면 호출이 멈추는지, 패널만 숨기는지 아는 사람이 있나요?
• @esikich — 에이전트에 정기적으로 요약 요청을 보내 토큰을 쓰는 일이 흔한 지식이라고 말하는 건가요? 문서에 설명돼 있나요?
  • @simoncion — 용어가 다른 문제일 수 있지만 공식 문서는 상태 표시줄이 로컬에서 실행되고 API 토큰을 쓰지 않는다고 설명합니다. 그 문서가 여기서 말하는 기능과 같은 것을 가리킨다면 널리 알려진 동작이라고 보기는 어렵습니다.
• @gym — Pro를 쓰는데 이틀 전에는 5시간 사용량을 전부 채웠을 때 주간 한도의 25%를 썼습니다. 오늘은 같은 100%인데 13% 정도입니다. 뭔가 고쳐진 것 같습니다.
  • @OsrsNeedsf2P — A/B 테스트입니다.
  • @grim_io — 인프라 전체 부하에 따른 영향일 가능성이 더 큽니다.

원문: Hacker News / 번역·요약: Trawling