Hermes 컨텍스트 압축 시간 초과: 해결 방법

"Context compression timed out before it could commit"은 주 모델이 아닌 Hermes의 요약 모델, 즉 auxiliary.compression 아래에 지정된 모델이 Hermes의 압축 제한 시간이 소진될 때까지 아무 진전도 이루지 못했고, 주 모델 호출을 보내지 않은 채 차례가 중지되었다는 뜻입니다. 동작은 버전에 따라 다릅니다. Hermes Agent v0.21.3에서 두 메시지를 모두 재현했고, 요약 모델이 응답하도록 만든 뒤 같은 세션에서 재시도하여 복구했습니다. 반면 v0.21.5에서는 같은 응답 지연이 오류 대신 긴 대기를 초래했습니다. 2026년 10월 1일 실제 제공업체 대신 두 모델을 대신하는 기록용 대체 서버를 대상으로 테스트했습니다.

디버깅이 아니라 자체 엔드포인트를 사용하도록 Hermes를 설정하는 경우에는 사용자 지정 API를 사용하는 Hermes Agent에서 시작하세요.

두 메시지와 각각이 알려 주는 내용

표시되는 내용	나타난 시점	주 호출이 전송되었나요?
"요청이 여전히 약 83,485토큰인 상태에서 컨텍스트 압축이 결과를 저장하기 전에 시간 초과되었습니다. 제공업체 호출은 전송되지 않았습니다. /compress를 실행하고 완료될 때까지 기다린 다음 재시도하세요."	v0.21.3, 요약 모델이 응답하지 않음, 요청(~83,485토큰)이 모델의 64,000토큰 창보다 큼	아니요
"컨텍스트 압축이 이 대화의 크기를 줄이지 못한 채 시간 초과되었습니다. 삭제된 메시지는 없습니다. 새 세션을 /new로 시작하거나 /compress를 재시도하기 전에 auxiliary.compression을 확인하세요."	v0.21.3, 요약 모델이 응답하지 않음, 요청(~57,489토큰)이 54,400토큰 압축 트리거를 초과하지만 창 안에 있음	아니요

첫 번째 메시지의 토큰 수치는 Hermes가 전송했을 요청에 대한 자체 추정치입니다. 두 차례 모두 "Context compression made no progress for 5.0s" 형식의 경고가 나온 뒤 로그에 reason=context_compression_timeout 및 api_calls=0로 기록되며 종료되었습니다. 테스트에서 실행 시간을 짧게 유지하려고 compression.context_timeout_seconds: 5를 설정했기 때문에 5초였으며, 기본값은 120입니다.

사용 중인 버전이 결과를 결정합니다

요약 모델 상태	v0.21.3 (9월 14일)	v0.21.5 (9월 24일)
응답 없음, 요청이 창 안에 있음	차례 중지 — 위의 두 번째 메시지	응답을 기다린 후(30초 및 90초 대기), 9개 메시지를 5개로 압축하고 요청 전송
응답 없음, 요청이 창을 초과함	차례 중지 — 위의 첫 번째 메시지	응답하지 않는 요약 모델로 실행되지 않음. 문서에서는 이 경우를 하나의 비활동 예산과 결정론적 대체 요약으로 제한함
응답 오류(404)	두 번 시도하고 압축을 건너뛴 후 요청 전송(창 안에서 테스트)	동일합니다. 창을 초과하는 요청도 전송되었으며, 실제 제공업체라면 거부했을 것입니다
응답함	압축 후 전송	압축 후 전송

경계는 소스 코드에 있습니다. v0.21.4(태그 v2026.9.21)에서는 이슈 #113646 및 #114594를 근거로, 압축 시간 초과 후 차례를 중지하는 함수의 적용 범위가 모델의 컨텍스트 창을 초과하는 요청으로 한정되었습니다. v0.21.3에서는 모든 경우에 차례를 중지합니다. 이후 v0.21.5의 구성 문서에는 압축 대기 시간의 "하한은 보조 압축 요청 자체의 시간 제한(auxiliary.compression.timeout, 최소 300초)"이라는 설명이 추가되었습니다. 이것이 해당 버전에서 5초 설정이 아무 효과가 없었던 이유입니다. 따라서 현재 빌드에서는 느린 요약 모델로 인해 오류가 발생하는 대신 몇 분간 기다리게 되고, 완전히 작동하지 않는 요약 모델은 건너뜁니다.

가장 짧은 진단

버전 확인은 hermes --version으로 하세요. v0.21.3 이하에서는 위의 두 메시지가 응답하지 않는 요약 모델에 대해 예상되는 동작입니다.
요약 모델 찾기는 ~/.hermes/logs/agent.log에서 하세요. "Auxiliary compression: using <provider> (<model>) at <url>" 줄이 시간 초과된 모델과 엔드포인트를 명시합니다. auxiliary.compression 블록이 없으면 주 모델 설정을 상속합니다.
트리거 줄 확인: "Pre-API compression: ~N request tokens >= T threshold (context=W)". N이 W보다 크면 어떤 버전에서도 요청을 압축하지 않은 상태로 전송할 수 없습니다.
요약 모델의 창 확인. Hermes 문서에서는 요약 모델의 창이 주 모델의 창 이상이어야 한다고 요구합니다. 대화 중간 전체가 요약 모델에 전송되기 때문입니다.

검증된 복구 방법

위의 모든 v0.21.3 사례에서 응답하는 요약 모델로 대체 서버를 재시작하고 같은 세션에서 한 차례 더 전송하면(--resume) 대화가 유지된 정상 응답이 나왔습니다. 실제로는 다음 중 하나를 의미합니다. auxiliary.compression을 도달할 수 있는 빠른 모델로 지정하거나, 해당 모델이 가리키는 엔드포인트를 수정하거나, 요약 모델이 느리지만 정상적으로 작동한다면 compression.context_timeout_seconds를 늘리세요. 예를 들어 로컬 모델을 사용할 수 있습니다. 그런 다음 같은 세션에서 재시도하세요.

응답하는 요약 모델을 가리킨 압축 — 작동한 복구 방법

# ~/.hermes/config.yaml — the summariser is its own model, with its own budget
auxiliary:
  compression:
    base_url: https://api.kunavo.com/v1   # overrides provider; any OpenAI-compatible endpoint
    api_key: sk-kn-...
    model: claude-haiku-4-5             # fast, and a context window >= your main model's
    timeout: 300

compression:
  context_timeout_seconds: 120   # inactivity budget for the summary (default)
  context_total_ceiling_seconds: 600

두 가지는 테스트하지 않았습니다. 서로 다른 예산으로 자체 위생 압축을 수행하는 Hermes Desktop 및 messaging-gateway 표면, 그리고 창을 초과하는 요청을 실제 제공업체가 거부하는 경우입니다. 실행은 일회성 hermes chat -Q 차례였습니다.

비용

중지된 차례는 주 모델 요청을 보내지 않으므로 주 모델에는 비용이 청구되지 않습니다. 요약 요청은 전송되었으며, 이 실행에서는 프롬프트가 약 19,000자였습니다. 요약 요청이 결국 완료되면 제공업체가 이에 대해 청구합니다. 재시도에서는 요약 호출 하나와 주 호출 하나에 대한 비용이 발생합니다. 작고 빠른 요약 모델을 사용하면 대기 시간과 오버헤드를 모두 줄일 수 있습니다. Kunavo에서는 Claude Haiku 4.5가 입력 토큰 100만 개당 $0.70, 출력 토큰 100만 개당 $3.50로 표시되며, 선불 잔액에서 토큰 단위로 청구됩니다. Kunavo에서는 Hermes를 해당 엔드포인트에 연결해 실행한 사람이 없습니다. 여기서의 실행은 로컬 대체 서버를 사용했습니다.

자주 묻는 질문

Hermes에서 "Context compression timed out before it could commit"은 무슨 뜻인가요?

Hermes는 사용자의 차례를 보내기 전에 대화를 줄이려고 했고, 이를 위해 사용하는 요약 모델이 제한 시간 내에 진행하지 못했으며, 요청이 압축하지 않은 상태로 보내기에는 너무 컸습니다. 따라서 Hermes는 주 모델을 전혀 호출하지 않고 해당 차례를 중지했습니다. 응답하지 않는 요약 모델과 64,000토큰 창에 대해 83,485토큰 요청을 보낸 Hermes Agent v0.21.3에서 재현되었으며, 해당 차례의 로그 줄은 api_calls=0이었습니다. 문제는 주 모델이나 주 모델의 API 시간 초과가 아닙니다. 문제는 config.yaml의 auxiliary.compression 아래에 지정된 모델인 요약 모델입니다.

Hermes 컨텍스트 압축 시간 초과를 어떻게 해결하나요?

요약 모델이 응답하도록 만든 다음 같은 세션에서 재시도하세요. 재현 환경에서는 auxiliary.compression을 응답하는 모델로 지정하고 같은 세션에서 다음 차례를 보내면 v0.21.3에서 매번 작동했으며, 기록도 그대로 유지되었습니다. 메시지 자체가 삭제된 메시지는 없다고 표시합니다. 업그레이드하면 상황도 달라집니다. v0.21.4부터 시간 초과된 압축은 모델 창에 여전히 들어가는 요청을 더 이상 중지하지 않으며, v0.21.5에서는 요약 대기가 요약 요청 자체의 시간 초과인 최소 300초로 설정됩니다. /new로 새 세션을 시작하는 방법도 작동하지만 대화 컨텍스트를 잃습니다.

Hermes 압축 시간 초과는 해결되었나요?

부분적으로 해결되었으며 형태가 바뀌었습니다. v0.21.3(2026년 9월 14일)까지는 시간 초과된 사전 압축이 모두 차례를 중지했습니다. v0.21.4(9월 21일)는 모델의 컨텍스트 창을 초과하는 요청만 중지합니다. v0.21.5(9월 24일)에서는 요약 모델의 응답을 먼저 30초, 그다음 90초 동안 보류해도 차례가 전혀 중지되지 않았습니다. Hermes는 기다린 뒤 압축하고 요청을 보냈습니다. 따라서 현재 버전에서 느린 요약 모델의 증상은 이 오류가 아니라 긴 대기입니다. 느린 것이 아니라 완전히 작동하지 않는 요약 모델은 다릅니다. 재시도한 다음 건너뛰고, 차례는 압축되지 않은 상태로 진행됩니다.

HERMES_API_TIMEOUT을 늘리면 도움이 되나요?

아니요. 이 변수는 기본값 1,800초인 주 모델 호출을 제어합니다. 압축에는 config.yaml에 자체 예산이 있습니다. compression.context_timeout_seconds(비활동 예산, 기본값 120초), compression.context_total_ceiling_seconds(기본값 600) 및 요약 요청 자체의 auxiliary.compression.timeout입니다. Hermes 문서에는 속도만큼 중요한 요구 사항도 추가되어 있습니다. 요약 모델의 컨텍스트 창은 주 모델의 컨텍스트 창 이상이어야 합니다. 대화 중간 전체를 받기 때문입니다.

시간 초과된 차례에도 비용이 들었나요?

Not on the main model: the turn ended before the main call was sent. The summary request was sent, though, and a summariser that eventually finishes is billed by its provider like any other call — in the runs here the summary prompt was about 19,000 characters. The retry then pays for one summary and one main call. That is why pointing compression at a small, fast model is cheaper as well as quicker: on Kunavo, Claude Haiku 4.5 lists at $0.70 per million input tokens.

2026년 10월 1일 Hermes Agent v0.21.3(태그 v2026.9.14) 및 v0.21.5(태그 v2026.9.24)에서 재현했습니다. 두 버전은 릴리스 소스에서 설치했고, 주 모델과 요약 모델 모두를 대신하는 로컬 기록용 대체 서버를 사용했습니다. 대체 서버는 응답이 멈춘 요약 모델을 재현할 때 응답을 보류했고, 실패하는 모델을 재현할 때 404를 반환했습니다. 테스트에는 64,000토큰 창과 테스트 차례 전에 필러가 포함된 재개 차례 4개가 사용되었습니다. 버전 경계는 v2026.9.14, v2026.9.21 및 v2026.9.24 태그의 agent/turn_context.py에서 확인했고, 시간 제한은 각 태그의 구성 문서에서 확인했습니다. 이 대체 서버는 모델이나 제공업체가 아닙니다. 어떤 크기의 요청이든 수락하므로 제공업체 측 컨텍스트 오류는 재현하지 않았습니다.