확인 끝났습니다. 코드 라인까지 짚어서 결론부터 답합니다.

결론: 서버측 일시 throttle를 데몬이 "계정 사용량 한도"로 오분류하고 있음

세 질문에 순서대로.

1) 그 에러는 실제로 무엇인가 → Anthropic 서버측 일시 제한(429 overloaded), 계정 한도 아님

"Server is temporarily limiting requests (not your usage limit) · Rate limited" — 문구 자체가 "not your usage limit"(당신 사용량 한도가 아님)이라고 명시합니다. 이건 Anthropic 인프라가 순간 부하로 요청을 미는 일시적 429이고, 보통 수 초~수십 초 내 자동 해소됩니다. Jason의 사용량 한도와 무관하다는 그의 말이 맞습니다.

2) 데몬이 이걸 "전 계정 한도 → 리셋까지 대기"로 바꾸는 로직이 실제로 있다 (그게 버그)

daemon/daemon.js의 detectUsageLimit() (159~192행) 매처가 너무 넓습니다:

/(rate|usage) limit/.test(t) || /limit reached/.test(t) ...

문제의 에러 문자열을 소문자화하면 ...(not your usage limit) · rate limited인데,

• "usage limit" → "(not your usage limit)" 안에서 매칭됨 (역설적으로 "아니다"라는 그 문구에 걸림)
• "rate limit" → "rate limited" 안에서 매칭됨

→ 서버 throttle을 계정 usage limit으로 오판합니다.

그 다음 흐름(1715~1738행):

• 이 에러엔 파싱 가능한 리셋 epoch이 없음 → fallback LIMIT_FALLBACK_MS = 20분(119행)으로 가짜 리셋 시각을 만듦
• 계정 풀이 단 1개입니다. .claude-accounts.json 파일이 없어서 env 단일 토큰 1개로 동작 중(직접 확인함). 그 하나를 walled 처리하면 pickAccount()가 즉시 null → 1728행 else 분기로 떨어져 "모든 Claude 계정이 사용량 한도에 도달… PM HH:MM 리셋 후 자동으로 이어서 진행" 문구(1732행)를 그대로 출력하고 글로벌 hold를 겁니다.

"PM 04:56"의 정체 = 진짜 Anthropic 리셋 시각이 아님. 에러 발생시각 + 20분(fallback)입니다. 즉 오해를 주는 자동 문구가 맞습니다.

자동 재개는 동작하긴 함: 작업은 /bridge/requeue로 다시 큐에 들어가고(1735행), isLimited()(144행)가 hold 만료 시 해제 → 루프가 다시 리스합니다. 그래서 "다시 보낼 필요 없다"는 맞지만 — 수 초면 풀릴 일을 20분 강제 대기시키는 게 실질 피해입니다.

3) 현재 상태 & 즉시 푸는 법

지금 라이브 확인 결과:

• daemon/limit-hold.json → 없음 = 현재 활성 글로벌 hold 없음 (이미 만료/해제됨)
• 데몬 node 프로세스는 떠 있음

즉 지금 이 순간엔 hold가 안 걸려 있습니다. Jason의 그 대화창이 멈춰 보인다면 (a) 이미 hold가 풀렸는데 화면만 그 문구에서 멈춰 있거나, (b) requeue된 task가 다음 폴링에서 재개되길 기다리는 상태입니다.

즉시 푸는 법:

• 그냥 그 대화에 메시지를 한 번 더 보내면 됩니다. (hold가 없으므로 바로 처리됨). 안내 문구의 "다시 보낼 필요 없다"는 무시하세요.
• 만약 또 hold가 잡힌 상태라면(파일 존재 시): daemon/limit-hold.json 삭제 + 데몬 재시작. ⚠️ 주의 — 이 hold는 in-memory(limitedUntil) + 파일 양쪽에 있고, 파일 재로딩 핫리로드가 없어 파일만 지워선 in-memory가 안 풀립니다. 파일 삭제 후 재시작해야 loadLimitHold()가 빈 상태로 뜹니다.

권고 (수정안 — 비가역 daemon 변경이라 착수 전 커밋 고정 필요)

근본 수정은 detectUsageLimit()가 서버측 throttle을 usage-limit에서 제외하도록 좁히는 것:

• not your usage limit, temporarily limiting requests, overloaded(429 overloaded) 포함 시 → usage-wall이 아니라 짧은 backoff 후 동일 계정 재시도로 분기.
• 진짜 계정 한도(usage limit reached|<epoch>처럼 파싱 가능한 reset이 동봉된 케이스)만 hold 처리.

이건 daemon 핵심 경로 변경이라 회사 규칙대로 (1) 변경 전 git 커밋 고정 → (2) 최소 패치 → (3) 실제 429 재현/모킹으로 라이브 검증 → (4) revert 경로 확보 순으로 갑니다. 지금은 진단까지만 했고, 자가 DONE 없이 라이브 검증 전까지 "고쳤다"고 말하지 않겠습니다.

진행할까요? Jason이 OK하면 커밋 고정부터 시작하겠습니다.