⚠️ Rate limited — fallback provider로 전환 중... 🔄 Primary 모델 실패 — fallback 전환: sg claude opus 4.7 via custom. 왜 자꾸 이 에러가 뜨는 걸까?

그런데 왜 이 메시지가 계속 반복될까요?

핵심은 Hermes의 fallback이 '턴(turn) 단위' 로만 적용된다는 점입니다 .

• 매번 새 메시지를 보낼 때마다, Hermes는 무조건 primary 모델을 먼저 시도합니다.
• primary가 여전히 rate limit 상태라면 또다시 실패하고, 그제서야 fallback으로 전환됩니다.
• 이 과정이 primary의 rate limit이 풀릴 때까지 매 턴마다 계속 반복되는 것입니다.

즉, "fallback으로 전환 중"이라는 메시지가 반복되는 것은 primary 모델의 근본적인 rate limit 문제가 아직 해결되지 않았다는 증거입니다 .

근본적인 원인은 'Rate Limit (HTTP 429)'

문제의 시작은 대부분 upstream으로부터의 HTTP 429 응답입니다 . 이는 할당된 API 사용량 한도를 초과했음을 의미합니다.

OpenClaw(게이트웨이) 및 Hermes 문서에 따르면, 429 오류는 특히 다음과 같은 상황에서 자주 발생합니다:

• 장기 컨텍스트(Long Context) 요청: 프롬프트나 대화 이력의 길이가 매우 길어지면, provider가 추가 사용량을 요구하며 거부하거나 쿼터를 더 엄격하게 적용할 수 있습니다. HTTP 429: rate_limit_error: Extra usage is required for long context requests와 같은 메시지가 대표적입니다 .
• 조직(Organization) 또는 토큰(Token) 단위 쿼터 초과: API 키 혹은 조직에 할당된 전체 사용량이 한도를 넘은 경우입니다.

가장 의심스러운 부분: Primary와 Fallback이 같은 풀(Pool)을 쓸 수 있다?

현재 오류 메시지에서 특히 주목해야 할 점은 sg claude opus 4.7 via custom 이라는 표기입니다 . 이는 fallback이 단순히 다른 기본 provider로 전환된 것이 아니라, 사용자가 별도로 설정한 맞춤형 엔드포인트(Custom Endpoint) 를 통해 연결되고 있음을 의미합니다 .

이로 인해 발생할 수 있는 가장 큰 함정은 다음과 같습니다:

• primary 모델과 fallback으로 설정된 sg claude opus 4.7 via custom이 실질적으로 동일한 업스트림 서버나 API 키 풀(Pool)을 공유하고 있을 가능성입니다.
• 만약 그렇다면, primary가 rate limit에 걸렸을 때 같은 한도에 묶여 있는 fallback으로 전환해 봐야 똑같이 제한될 수밖에 없습니다. 겉으로는 "전환"에 성공한 것처럼 보여도, 실제 서비스는 계속 불안정하거나 '여전히 안 되는' 느낌을 주게 됩니다 .

참고: 현재 제공된 정보만으로 primary와 fallback이 동일한 풀을 공유한다고 단정할 수는 없습니다. 하지만 이 현상이 지속된다면 가장 먼저 의심하고 확인해야 할 지점입니다 .

지금 바로 확인하고 조치할 사항

문제를 근본적으로 해결하려면 코드를 수정하는 것이 아니라 설정(configuration) 을 점검해야 합니다.

1. config.yaml 파일 확인하기

Hermes의 모든 설정은 ~/.hermes/config.yaml 파일에 저장됩니다 .

• 현재 primary 모델이 무엇인지 확인하세요.
• fallback_providers 목록을 확인하세요. 여기에 sg claude opus 4.7 via custom이 어떻게 설정되어 있는지, 어떤 provider와 model을 가리키는지 살펴보세요 .
• hermes fallback list 명령어로도 현재 fallback 체인을 확인할 수 있습니다 .

2. Primary와 Fallback의 공급원(Source) 비교하기

config.yaml 파일에서 primary provider의 설정과 custom endpoint 설정을 비교하세요.

• API 엔드포인트 URL: 동일한 기본 도메인(예: api.anthropic.com)을 사용하나요?
• API 키: 동일한 키를 사용하거나, 같은 조직/프로젝트에 속한 키를 사용하나요?
• 만약 둘이 같다면, primary가 막혔을 때 fallback도 똑같이 막히는 것은 당연한 결과입니다. 이 경우, 완전히 다른 provider(예: OpenRouter)나 다른 계정의 키를 사용하는 별도의 엔드포인트로 fallback 체인을 재구성해야 합니다.

3. 게이트웨이 상태 점검 및 Probe 실행

OpenClaw 또는 커스텀 게이트웨이를 사용 중이라면, 게이트웨이 레벨에서의 상태를 확인하세요.

• openclaw gateway probe 명령어를 실행하여 게이트웨이 연결 상태와 인증 수준을 확인합니다 .
• openclaw gateway status --deep 으로 오래된 클라이언트 프로세스가 남아 연결을 방해하는 것은 아닌지 확인합니다 .
• 실제 오류가 429 외에 인증 오류(auth error)나 기타 서버 오류는 아닌지 로그를 통해 정확히 진단합니다.

4. 장기 컨텍스트 문제 해결하기

주로 대화가 길어질 때 이 현상이 발생한다면, 장기 컨텍스트로 인한 rate limit일 가능성이 높습니다 .

• 대화를 새로 시작하여 컨텍스트 길이를 줄여보세요. 문제가 사라진다면 장기 컨텍스트가 원인입니다.
• 일부 provider는 장기 컨텍스트 사용 시 더 높은 티어의 API 키나 추가 설정을 요구할 수 있습니다.

결론

요약하자면, 이 현상은 Hermes의 정상적인 자가 치유(Self-healing) 메커니즘입니다 .

• 메시지가 반복되는 것은 primary 모델의 rate limit 문제가 해결되지 않았기 때문입니다.
• 문제의 본질은 "fallback 전환"이 아니라, primary와 fallback이 동일한 리소스 풀에 묶여 있을 가능성을 포함한 upstream rate limit입니다 .

config.yaml을 열어 primary와 fallback provider의 설정을 꼼꼼히 비교하고, 필요하다면 완전히 독립적인 provider로 fallback 체인을 재구성하는 것이 가장 확실한 해결책입니다.

다음 단계: 지금 바로 ~/.hermes/config.yaml 파일을 확인하고, hermes fallback list 명령어로 현재 체인을 살펴보세요. 그 후, primary와 fallback이 서로 다른 API 키와 엔드포인트를 사용하도록 설정하는 것을 권장합니다.