Nanobot 무한 루프와 토큰 사용량: 제한된 Dream 실행 진단

무한 루프처럼 보이는 nanobot 실행은 제한된 실행입니다. 배포된 v0.3.5 소스에서는 모든 에이전트 턴이 기본값 200인 agents.defaults.maxToolIterations에 의해 제한되며, 유지 관리자도 공식적으로 이는 문자 그대로 무한 루프가 아니라고 밝혔습니다. 실제 문제는 토큰 사용량입니다. 이 상한에 도달하는 실행은 assistant 턴 201회를 기록하고 매번 점점 커지는 프롬프트를 다시 전송합니다. 어떤 경우인지 판단하는 데는 네 가지 질문이 필요하며, 근거가 있는 해결책은 구성 값이 아닙니다.

먼저 가장 눈에 띄는 단서를 후보에서 제외하세요. 업스트림 신고는 제목이 dream.maxIterations를 가리키는 이슈 #5781이고, PR #5782의 제목은 "fix(dream): enforce configured iteration limit"입니다. 해당 키는 v0.3.5에 존재하지 않으며, PR은 2026년 9월 16일 병합되지 않은 채 종료되었습니다. 이를 기반으로 만든 튜토리얼은 아무것도 구성하지 않습니다.

검색 결과가 잘못된 이슈 트래커를 보여 주므로 구분해야 합니다. 이 페이지는 MIT 라이선스의 HKUDS/nanobot을 다루며, PyPI 패키지 nanobot-ai로 설치합니다. 버전은 0.3.5이고 Python 3.11 이상이 필요하며 2026년 9월 15일에 업로드되었습니다. obot-platform/nanobot은 다른 Go 프로젝트로, README에 이슈가 비활성화된 유지 관리 모드라고 명시되어 있습니다. 해당 이슈 번호는 여기서 근거가 되지 않습니다. 또한 접미사가 없는 pip install nanobot는 관련 없는 로봇 내비게이션 패키지를 설치합니다.

무엇이 보고되었고 어떤 버전을 대상으로 했는가

Dream은 nanobot의 예약된 메모리 통합 작업으로, dream이라는 cron 작업으로 게이트웨이가 실행합니다. 이는 임베딩 또는 벡터 인덱스 작업이 아닙니다. Kunavo는 임베딩 모델을 제공하지 않으며 Dream에도 임베딩 모델이 필요하지 않습니다. nanobot의 영속 메모리는 워크스페이스 아래의 일반 파일이고 Dream 실행은 일반 채팅 트래픽이기 때문입니다.

이슈 #5781은 2026년 9월 15일 BrianMwangi21이 nanobot v0.3.0을 대상으로 등록했습니다. Python 3.12에서 OpenRouter를 통해 접근한 추론 모델을 사용했습니다. 증상은 Dream 작업이 수십 차례에 걸쳐 memory/history.jsonl에서 read_file와 하나의 SKILL.md 파일에서 read_file를 번갈아 실행하면서, 추론 추적이 작은 사실 하나를 어디에 기록할지 반복해서 재검토하는 것이었습니다. 약 26시간 동안 기록된 7회의 실행 시간은 대략 25분에서 111분 사이였고, 도구 호출이 200회에 가까운 실행은 전역 상한에 도달했습니다. 세션 체크포인트에는 동일한 read_file 호출에서 runtime_checkpoint.iteration: 164, 단계 tools_completed가 표시되었습니다.

이 수치에는 적용 범위에 관한 세 가지 제한을 함께 명시해야 합니다. 이는 한 사용자가 직접 보고한 게이트웨이 로그이며, 하나의 모델에서 v0.3.0으로 실행한 결과입니다. 어떤 유지관리자도 이를 재현하지 않았으며, v0.3.5에서 다시 테스트한 사람도 없습니다. 해당 이슈에는 enhancement 및 priority: p2 라벨이 붙어 있으며, bug 라벨은 붙어 있지 않고, 아직 열려 있습니다. 또한 이런 양상은 이전에도 나타났습니다. 2026년 4월 12일에 보고된 이슈 #3073은 history.jsonl에서 발생한 거의 동일한 read_file 루프에 관한 것으로, 계획 없음 사유로 닫혔습니다. 이 모든 사실은 nanobot의 비용이 전반적으로 높다고 판단할 근거가 되지 않습니다. 다만 자신의 설치 환경에서도 이런 현상이 발생하는지 확인할 근거는 됩니다.

사용 중단된 키와 실제로 적용되는 경계

혼란의 전체 원인은 버전 차이이며 소스가 이를 확정합니다. 2026년 9월 21일 두 릴리스 태그에서 확인한 내용은 다음과 같습니다.

이 표를 잘못 이해하기 쉬운 이유는 두 가지입니다. 200이라는 값은 두 측면에서 모두 맞습니다. 보고자의 설정에 지정된 값인 동시에 nanobot/config/schema.py의 129번째 줄에 있는 배포 기본값이기도 하며, v0.3.5 태그와 main에서 동일합니다. 따라서 이 값을 직접 설정한 적이 없는 독자에게도 200이 적용됩니다. 또한 이 값은 문서에 나와 있지 않습니다. 2026년 9월 21일에 nanobot 자체의 0.3.5 설정 참조 문서를 가져왔을 때 488,608바이트의 HTML이 반환되었지만, maxToolIterations는 한 번도 등장하지 않았으며, 해당 태그의 저장소에 있는 docs/configuration.md에도 없습니다. 이 수치는 문서 페이지가 아니라 소스와 유지관리자의 댓글로 입증할 수 있습니다. 따라서 다른 수치를 제시하는 튜토리얼은 의심해 보아야 합니다.

modelOverride는 버전 조건이 붙은 유일한 해결책입니다. v0.3.0에는 해당 필드가 구현 예정이라는 주석과 함께 존재했지만 이를 해석하는 코드는 전혀 없었습니다. 2026년 7월 27일 병합된 PR #5107이 v0.3.5에서 이를 구현했습니다. 공식 0.3.5 메모리 페이지에는 Dream에서 model_presets의 이름이 지정된 항목을 선택하며, 프리셋 이름만 허용하고 원시 모델 식별자는 지원하지 않는다고 적혀 있습니다. 해당 페이지는 Dream 키 세 가지를 문서화하고 반복 제한은 어디에서도 언급하지 않습니다. 다음은 현재 설정 항목 전체이며, 이 설정이 의존하는 providers 블록은 nanobot 설정 페이지에서 다룹니다.

{
  "modelPresets": {
    "dream-cheap": {
      "provider": "kunavo",
      "model": "claude-haiku-4-5",
      "maxTokens": 8192
    }
  },
  "agents": {
    "defaults": {
      "maxToolIterations": 200,
      "dream": {
        "enabled": true,
        "intervalH": 2,
        "modelOverride": "dream-cheap"
      }
    }
  }
}

해당 파일에 없는 것을 확인하세요. Dream만 제한할 방법은 없습니다. AgentLoop는 프로세스 기본값에서 max_iterations와 함께 한 번 생성되며, Dream cron 경로와 수동 /dream 경로는 모두 반복 인수 없이 process_direct(...)를 호출합니다. 서브에이전트도 마찬가지입니다. 상한을 낮추면 채팅, Dream, heartbeat 및 서브에이전트 모두의 상한이 함께 낮아집니다.

다음 순서로 진단하세요

무엇이든 변경하기 전에 다음 네 가지에 답하세요. 이 중 세 가지는 무료로 확인할 수 있고, 네 번째는 앞의 세 가지가 중요한지 알려 줍니다. 로그 문자열은 v0.3.5의 리터럴 텍스트이고, 중괄호는 런타임 값입니다.

cron 틱을 두 시간 기다리지 않아도 재현할 수 있습니다. /dream 명령은 동일한 작업을 필요할 때 실행하고, 채팅에서 동일한 구분을 보고합니다. 성공 시 Dream completed in Ns. 또는 Dream completed in Ns; no memory changes., 완료되지 않으면 Dream did not complete after Ns (reason); memory cursor was not advanced.입니다. 증거를 찾는 동안 중요한 v0.3.5의 다른 변경 사항도 있습니다. session JSONL 파일이 설정 디렉터리의 sessions/<workspace-id>/ 트리 아래로 이동했으므로, 이슈 스레드에 인용된 v0.3.0 경로는 체크포인트가 있는 위치가 아닙니다.

다섯 가지 조정 항목과 각각을 뒷받침하는 실제 근거

신고자가 OpenRouter를 통해 사용했다고 적은 두 모델 ID는 그가 적은 그대로 deepseek/deepseek-v4-flash-0731와 openai/gpt-5.6-luna입니다. 여기서는 해당 ID와 가격을 확인하지 않았으므로, 이 비교를 어느 한쪽의 추천이 아니라 모델이 수렴을 결정한다는 근거로 읽으세요. 업스트림도 같은 결론에 도달했습니다. 이슈 #5781에서 PR #5782의 종료를 알리며 chengyongru는 고정된 Dream 반복 상한이 모델에 의존하는 근본적인 수렴 문제를 해결하지 못하고, 원래는 성공적으로 수행될 수 있는 실행을 반복적으로 다시 시도하게 만들 수 있다고 썼습니다.

제한된 실행 비용: 예시 계산

이는 예시용 토큰 계산이며, 측정된 작업 비용도 청구액 상한도 아닙니다. nanobot은 Dream의 실행당 토큰 수를 공개하지 않으므로, 여기에 사용된 모든 입력값은 가정이며 직접 측정한 값으로 대체해야 합니다. 어시스턴트 턴 201회에서 상한에 도달하는 한 번의 실행을 가정합니다. 이 횟수는 작성자의 감사에서 집계된 수치입니다. 각 턴에서는 25,000토큰으로 일정하게 유지된 프롬프트를 다시 전송한다고 가정하며, 이 토큰 수는 작성자가 자신의 작업 공간을 설명한 수치이지 공개된 수치가 아닙니다. 이는 입력 토큰 5.03M에 해당합니다. 출력 토큰은 제외되며, 실제 프롬프트는 각 도구 결과가 추가될 때마다 커지므로, 이 계산은 두 가지 측면에서 동시에 실제 실행의 비용을 과소평가합니다. 요율은 Kunavo 카탈로그의 실시간 가격입니다.

마지막 열은 여기서 테스트하지 않은 최선의 경우를 가정합니다. 첫 전송은 일반 입력 요금이고, 모든 200 재전송은 캐시 읽기로 처리된다는 가정입니다. 캐시 쓰기에는 자체 요금이 적용되며, 일부 모델에서는 일반 입력 요금보다 높습니다. 캐시 항목은 만료되고, 커지는 프롬프트는 다시 읽는 대신 다시 작성됩니다. 따라서 마지막 두 열의 차이는 견적이 아니라 절감 가능한 최대 규모로 보세요. 핵심은 긴 반복 실행에서 비용을 발생시키는 것은 모델이 아니라 재전송이라는 점뿐입니다.

캐시 마커가 실제 전송에 도달하는지는 nanobot 설정에서 결정되며, 제공된 소스에서 확인할 수 있습니다. providers 아래의 임의 provider 키는 일반 OpenAI 호환 provider로 처리되고 supports_prompt_caching는 기본값인 false로 남으므로, Claude 형태의 모델 ID를 사용하더라도 nanobot 클라이언트는 해당 경로에서 cache_control 마커를 보내지 않습니다. preset을 기본 제공 anthropic provider에 유지하고 providers.anthropic.apiBase를 재정의하면 마커가 유지됩니다. 이는 nanobot 클라이언트가 보내는 내용에 대한 설명이지, 어떤 endpoint가 자체적으로 처리하는 방식에 대한 설명이 아니며, Kunavo는 nanobot을 런타임 테스트하지 않았습니다. 반복 작업을 캐시된 것으로 예산에 반영하기 전에 실제 호출 하나의 반환 usage를 확인하세요. 캐싱 문서는 작동하는 캐시의 형태를 보여 주고, base URL reference는 두 endpoint 규칙을 모두 제공합니다.

Kunavo 카탈로그 금액은 상한이 아니라 청구 하한입니다. upstream이 요금을 보고하면 청구액은 카탈로그 비용과 upstream 비용에 해당 markup을 곱한 금액 중 더 큰 값입니다. 최소 충전액은 선불 크레딧 10$이며, 이는 자금 충전 최소액이지 작업 요금이나 구독료가 아닙니다. billing details와 위 가정을 대체할 측정 방법을 설명하는 cost optimization을 참조하세요.

한 번 실행하여 수정 사항 확인

한 가지씩 변경한 뒤 일정을 기다리지 말고 /dream를 한 번 실행하여 세 마커를 순서대로 확인하세요. Max iterations (200) reached 경고가 없고, cursor remains at …가 아니라 cursor advanced to … 줄이 나타나며, 그 사이의 도구 호출 수가 타당해야 합니다. 그런 다음 usage에서 해당 시간대에 자신의 계정이 기록한 청구액을 키별·일별로 확인하세요. nanobot의 store는 금액이 아니라 토큰을 계산합니다. endpoint를 처음 구성하는 경우 quickstart와 nanobot setup page에서 두 프로토콜 경로를 모두 다루며, 키에 자금을 충전하기 전 단계는 Kunavo 계정 생성입니다. 런타임을 비교하시나요? nanobot vs OpenClaw은 두 백그라운드 주기를 나란히 비교하고, agent API directory는 wire protocol별 클라이언트를 정리합니다.

자주 묻는 질문

2026년 9월 21일 확인: HKUDS/nanobot의 GitHub API와 이슈 #5781, #5324, #3073 및 pull request #5782, #5107, #5325, #5442, #5407, #3077, #4522, #5344, #3701, #4154, #3735, #3921, #4622; nanobot-ai 0.3.5의 PyPI 기록; nanobot의 0.3.5 메모리 및 설정 문서; 그리고 위에서 인용한 모든 기본값·로그 문자열·코드 경로에 대한 v0.3.5 태그의 제공 소스이며, 두 버전이 다른 경우 v0.3.0과 비교했습니다. Kunavo는 nanobot을 설치하거나 실행하지 않았고, 여기의 어떤 동작도 Kunavo에서 테스트한 것이 아닙니다. 또한 누구도 v0.3.5에서 issue #5781의 루프를 다시 테스트하지 않았습니다. 토큰 요금은 현재 카탈로그에서 가져왔으며, 모든 달러 수치는 명시된 가정에 따른 예시 계산입니다