OpenManus는 기본적으로 토큰 한도를 적용하지 않습니다. 자체 한도는 max_input_tokens이며, app/config.py에서 Optional로 선언되어 기본값은 None이고 설명은 "Maximum input tokens to use across all requests (None for unlimited)"입니다. 또한 제공된 설정 예시에는 나타나지 않습니다. 따라서 기본 설치에서는 자체 토큰 한도 오류가 발생하지 않습니다. 발생한 오류는 제공업체에서 온 것입니다. 이 값을 설정하면 사람들이 예상하지 못하는 두 가지 방식으로 동작하며, 현재 main에 존재하는 결함 때문에 빠르게 실패하지 않고 느리게 실패합니다.
이 페이지에서 다루는 또 다른 오류인 Error: Unknown tool 'BrowserUseTool'는 현재 발생하는 버그가 전혀 아닙니다. 이 오류에 명시된 클래스는 2026년 8월 15일에 OpenManus에서 삭제되었으며, 현재 main의 기본 Manus 에이전트는 로컬에 브라우저 도구를 등록하지 않습니다. 두 증상 모두 API 키, 엔드포인트 또는 제공업체의 문제가 아니며, base_url가 가리키는 대상을 바꿔도 어느 쪽도 해결되지 않습니다.
그 전에 전제 하나를 짚고 넘어가겠습니다. 인용할 OpenManus 버전은 없습니다. 유일한 세 태그 v0.1.0, v0.2.0, v0.3.0는 2025년 4월 10일 서로 34초 이내에 모두 게시되었고, 그 이후 태그가 추가되지 않았으므로 모두 태그가 없는 main를 실행합니다. 정식 저장소는 FoundationAgents/OpenManus이며, 아카이브되지 않았고 MIT 라이선스이며 별은 58,371개, 마지막 푸시는 2026년 8월 22일이었습니다(GitHub API, 2026년 9월 21일). 이전 mannaandpoem/OpenManus 경로는 이제 프로젝트가 이전되었다고만 말하는 스텁 README이므로, 2025년 튜토리얼에서 인용한 파일 경로와 줄 번호는 더 이상 존재하지 않는 코드를 가리킵니다. 아래 내용은 모두 2026년 9월 21일 main 브랜치의 소스를 읽어 확인한 것이며 실행한 내용은 없습니다.
실제로 가지고 있는 네 가지 메시지 중 어느 것인가요
| 표시되는 내용 | 누가 출력하나요 | 의미 |
|---|---|---|
Maximum token limit reached, cannot continue execution: Request may exceed input token limit (Current: …, Needed: …, Max: …) | OpenManus, app/agent/toolcall.py | 실행에 대한 자체 max_input_tokens 한도에 도달했습니다. 요청은 전송되지 않았습니다 |
| 모델 이름을 포함한 컨텍스트 길이 또는 토큰 오류 | 제공업체가 OpenAIError를 통해 표시한 오류 | 요청이 모델의 컨텍스트 창 또는 엔드포인트 자체의 한도를 초과했습니다. OpenManus의 한도와는 무관합니다 |
Error: Unknown tool 'X' | OpenManus, app/agent/toolcall.py 179–181행 | 모델이 available_tools.tool_map에 없는 도구를 지정했습니다. 도구 결과로 반환되므로 루프가 계속되고 한 단계를 소모합니다 |
Failed to connect to Browser Use CLI 3.0: … | OpenManus, app/agent/manus.py 99행 | 기본 브라우저 MCP 서버가 시작되지 않았습니다. 실행은 계속되며 Manus 에이전트는 네 개의 로컬 도구와 사용자가 설정한 다른 MCP 서버를 계속 보유합니다 |
세 번째 행을 생성하는 디스패치는 세 줄이며 2026년 브라우저 재작성으로도 변경되지 않았습니다. name = command.function.name 다음에 if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'"가 옵니다. 이 코드에는 브라우저에만 해당하는 내용이 없으므로 모델이 만들어 낸 어떤 도구에도 동일한 문자열이 나타납니다.
토큰 한도는 선택 사항이며 누적되고 근사값입니다
서로 다른 세 숫자가 모두 "토큰 한도"라고 불리며, 오류 메시지는 그중 하나만 다룹니다.
| 설정 | 무엇을 제한하나요 | 기본값 | 제공된 예시에 있나요? |
|---|---|---|---|
max_tokens | 응답 하나 | 코드의 4096 | 예 — 8192로 설정됨 |
max_input_tokens | 전체 실행에 걸친 누적 입력 | None, 즉 무제한 | 아니요. 직접 추가하지 않으면 적용되지 않습니다 |
| 모델의 컨텍스트 창 | 제공업체에서 요청 하나에 적용 | 모델 자체의 한도 | OpenManus 설정이 아님 |
두 번째 행이 사람들을 가장 놀라게 합니다. app/llm.py의 LLM.check_token_limit()는 (self.total_input_tokens + input_tokens) <= self.max_input_tokens를 반환합니다. 이는 한 요청에 대한 검사가 아니라 세션의 누적 합계입니다. 따라서 각 개별 요청이 작더라도 긴 에이전트 실행은 누적을 통해 한도에 도달하며, 오류 텍스트는 current, needed, max라는 계산을 그대로 보여 줍니다. 기본 Manus 에이전트는 max_steps = 20를 설정하고 각 단계마다 지금까지의 대화를 다시 전송하므로, 누적 수치는 단계 수보다 더 빠르게 증가합니다.
이 수치 역시 OpenManus 자체의 추정값입니다. LLM.__init__는 tiktoken.encoding_for_model(self.model)를 호출하고 KeyError에서 cl100k_base로 대체하므로, tiktoken에 사전 설정이 없는 모델 ID(Claude 또는 Gemini ID, 혹은 게이트웨이 네임스페이스 ID)의 경우 적용되는 예산은 제공업체의 계산값이 아니라 근사값입니다.
# config/config.toml
[llm]
model = "claude-sonnet-4-6"
base_url = "https://api.kunavo.com/v1"
api_key = "sk-kn-..."
# The RESPONSE cap. Ships as 8192 in config.example.toml; the code default is 4096.
max_tokens = 8192
# The CUMULATIVE INPUT budget for the whole run. Absent from every shipped
# example, and None in code — so a stock install enforces no ceiling at all.
max_input_tokens = 400000한도가 비용 면에서 의미하는 것
max_input_tokens는 누적 입력을 제한하므로 한 번의 실행에서 입력 측 비용의 상한으로 직접 환산됩니다. 아래 수치는 명시된 한도를 기준으로 한 예시적인 토큰 산술이며, 측정된 작업 비용이나 청구서 상한이 아닙니다. 이는 설정이 제한하는 입력 토큰을 백만 토큰당 실시간 Kunavo 카탈로그 요율로 계산한 것입니다. 출력은 이 설정의 적용 대상이 아니며, 마지막 열은 예시 설정에 포함된 max_tokens = 8192에서 응답 하나의 가격을 계산한 것입니다. 20단계 실행에서는 이러한 응답이 20개 생성될 수 있습니다.
| 모델 | 1M당 입력 / 출력 | 100,000 한도에서의 입력 | 400,000 한도에서의 입력 | 8,192 토큰 응답 하나 |
|---|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.070 | $0.280 | $0.029 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.070 | $0.280 | $0.034 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.210 | $0.840 | $0.086 |
| Claude Opus 5 | $3.50 / $17.50 | $0.350 | $1.400 | $0.143 |
두 가지로 해석해야 합니다. 한도는 예산이 아니라 중지선입니다. 실행의 입력 측 비용이 얼마나 들 수 있는지만 알려 줄 뿐, 작업이 완료되었는지는 말해 주지 않습니다. 또한 OpenManus는 tiktoken으로 계산하므로 적용되는 한도와 제공업체가 청구하는 토큰은 서로 다른 측정값입니다. 폭주하는 루프를 제한하도록 숫자를 설정한 다음 실제 계정에 기록된 내용과 대조하세요. Kunavo 카탈로그 금액은 상한이 아니라 청구 기준 하한입니다. 업스트림이 요금을 보고하면 청구액은 카탈로그 비용과 업스트림 비용에 적용 가능한 마크업을 곱한 금액 중 더 큰 쪽입니다. Kunavo의 최소 충전 금액은 선불 크레딧 $10이며, 작업 요금이나 구독료가 아니라 자금 충전 최소 금액입니다. billing details를 참조하세요.
토큰 오류가 늦게 발생하는 이유
이는 현재 main에서 소스 코드를 읽어 확인할 수 있는 결함이며, 토큰 한도 실패가 멈춘 것처럼 느껴지는 이유입니다. app/llm.py의 세 @retry 데코레이터(ask, ask_with_images, ask_tool에 적용됨)는 모두 동일하게 작성되어 있습니다.
| 데코레이터의 설명 | 무엇과 일치하나요 | 결과 |
|---|---|---|
끝부분 주석: # Don't retry TokenLimitExceeded | retry_if_exception_type((OpenAIError, Exception, ValueError)) | TokenLimitExceeded는 OpenManusError의 하위 클래스이고, 그 클래스는 Exception의 하위 클래스입니다. 따라서 별도 한정 없이 지정된 Exception 항목이 이 예외에 일치합니다. |
raise 위치 주석: # Raise a special exception that won't be retried | stop_after_attempt(6), wait_random_exponential(min=1, max=60) | 오류가 표면화되기 전에 지수 백오프로 최대 6회 시도하며, 매번 동일하게 실패하는 합계를 다시 계산합니다 |
이후의 에이전트 루프도 이 구조를 부정하지 않고 확인해 줍니다. app/agent/toolcall.py는 예외를 포착하고 isinstance(e.__cause__, TokenLimitExceeded)를 검사합니다. __cause__ 언래핑이 tenacity RetryError가 전달되는 방식이며, 자체 로그 행은 "Token limit error (from RetryError)"입니다. 그제야 사용자에게 표시되는 "Maximum token limit reached, cannot continue execution" 메시지를 추가하고 에이전트 상태를 finished로 설정합니다. 즉, 소비하는 코드는 데코레이터 주석이 발생하지 않는다고 말하는 재시도를 이미 전제로 합니다.
병합된 수정 사항은 없습니다. "fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback"라는 제목의 PR #1348은 2026년 8월 10일 병합되지 않은 채 종료되었고, 재제출된 #1407은 2026년 9월 21일에도 여전히 열려 있으며 병합되지 않았습니다. 관련 컨텍스트 오버플로 PR #1391 "add tool description token budget to prevent context overflow"도 2026년 8월 18일 병합되지 않은 채 종료되었습니다. 유지관리자가 왜 이를 종료했는지는 여기서 확인하지 않았고, 병합되지 않았다는 사실만 확인했습니다. 2025년 3월 17일의 역사적 보고인 이슈 #779 "hitting token limit"는 2026년 9월 17일 비활성 봇에 의해 state_reason: not_planned 상태로 종료되었습니다. 이는 해결이 아니라 시간 초과입니다. 이 중 하나가 병합될 때까지 실질적인 완화책은 max_input_tokens를 설정하지 않고 제공업체가 지나치게 큰 요청을 거부하게 두거나, 이를 설정하고 지연을 받아들이는 것입니다.
Unknown tool 'BrowserUseTool'는 더 이상 존재하지 않는 버전의 오류입니다
이슈 #789 "Result: Error: Unknown tool 'BrowserUseTool'"는 2025년 3월 18일에 등록되었고 2026년 9월 21일에도 여전히 열려 있었으며 inactive로 표시되었습니다. 원인은 엔드포인트나 키가 아니었습니다. 제보자가 직접 붙여 넣은 로그에는 모델이 Python 클래스 이름인 BrowserUseTool를 출력했지만, 등록된 도구 이름은 browser_use였고, 같은 실행의 바로 다음 단계에서는 browser_use를 호출하자 정상적으로 디스패치되었습니다. 그들이 붙여 넣은 로그는 "Activating tool: 'browser_use'"에서 끝나며, 마무리 문장은 전체 진단을 담고 있습니다. "BrowserUseTool seems not work, but browser_use can". 댓글 작성자가 제시한 유일한 조언은 더 강력한 모델을 사용해 보라는 것이었으며, 이는 도구 호출 충실도 문제에 적합한 답입니다.
현재 main에는 올바르게 지정할 browser_use라는 도구가 더 이상 없으므로 이 진단을 현재 상황에 그대로 적용할 수 없습니다. 2026년 8월 15일 커밋 ab8dfe43 ("feat(browser): use Browser Use CLI 3.0") 및 05c5bbb1 ("refactor(browser): use CLI 3.0 MCP server")가 로컬 브라우저 도구를 삭제했습니다. main의 app/tool/ 디렉터리 목록에는 browser_use_tool.py가 없으며, 트리에서 BrowserUseTool 문자열이 남아 있는 유일한 위치는 app/agent/sandbox_agent.py의 주석 처리된 줄입니다.
| 2025년 3월 코드(이슈 #789) | 현재 main, 2026년 9월 21일 확인 | |
|---|---|---|
| 브라우저 도구 | app/tool/browser_use_tool.py의 로컬 클래스 | 삭제됨. 기본 Manus 에이전트에서는 uvx browser-use --cli-mcp로 시작되는 프로세스 외부 MCP 서버가 사용됩니다 |
| 등록된 이름 | browser_use | README에 따르면 browser_exec 및 browser_screenshot |
| Manus 에이전트에 로컬로 등록된 도구 | 브라우저 도구 포함 | PythonExecute, StrReplaceEditor, AskHuman, Terminate — 브라우저 도구는 MCP를 통해 제공됨 |
| 의존성 고정 | requirements.txt에 고정됨 | browser-use 항목 없음. uvx가 실행 시 가져오므로 브라우저 스택은 체크아웃과 독립적으로 변경됩니다 |
| 자격 증명 | 모델 키 | 로컬 모드에는 키가 필요하지 않습니다. 클라우드 모드는 자체 환경 변수를 사용하는 별도의 Browser Use 계정입니다 |
| 비활성화 방법 | 도구 제거 | OPENMANUS_DISABLE_BROWSER_USE=1 |
따라서 현재 이 정확한 문자열을 해결하려면 체크아웃을 업데이트하고 이전 저장소 경로를 기준으로 작성된 튜토리얼에 의존하지 않아야 합니다. 추측하지 않고 명시할 주의사항이 하나 있습니다. MCP 연결이 실패하면 app/agent/manus.py는 Failed to connect to Browser Use CLI 3.0를 기록하고 네 개의 로컬 도구로 계속 진행하며, 모델은 등록되지 않은 브라우저 도구를 계속 이름으로 지정할 수 있습니다. 실제로 이것이 Unknown tool 메시지를 생성하는지, 생성한다면 어떤 이름으로 생성되는지는 여기서 관찰하지 않았습니다. 조사할 지점으로만 취급하고 문서화된 증상으로 보지 마세요. 또한 requirements.txt가 uv>=0.6.0를 고정한다는 점도 참고하세요. 일반 설치에서 uvx가 PATH에 포함되는지는 확인하지 않았습니다.
검색하면 여전히 발견되지만, 위 문단들이 의도적으로 주장하지 않는 내용이 하나 있습니다. 저장소에는 기본 경로가 절대 로드하지 않는 브라우저 코드가 실제로 포함되어 있습니다. 별도의 Daytona 샌드박스 진입점 sandbox_main.py는 app/tool/sandbox/sb_browser_tool.py에서 SandboxBrowserTool를 로컬 도구로 등록하는 SandboxManus 에이전트를 생성하며, 이름은 sandbox_browser이지 browser_use가 아닙니다. 따라서 "로컬 브라우저 도구가 없다"는 말은 main.py에서 가져오는 기본 Manus 에이전트에 관한 것이지, 전체 트리에 관한 말이 아닙니다.
검색할 때 구분해야 할 이름이 하나 있습니다. OpenManus/OpenManus-RL는 별도 조직의 별도 저장소이며, 에이전트 런타임의 버전이 아니라 강화학습 연구 프로젝트입니다. 파일 구조도 어느 오류에 관해서든 아무런 의미를 제공하지 않습니다.
다른 API 엔드포인트가 바꾸는 것과 바꾸지 않는 것
위의 두 증상은 모두 OpenManus 내부에서 생성되므로 "다른 제공업체를 사용하면 해결되나요?"라는 질문에 대한 정직한 답은 아니요입니다. 엔드포인트 선택이 영향을 미치는 것은 이 두 오류로 오해하기 쉬운 인접한 실패 유형들입니다.
| 실패 | 엔드포인트에 따른 오류인가요? | 먼저 확인할 것 |
|---|---|---|
| OpenManus 자체 토큰 한도 메시지 | 아니요 — 어떤 요청도 전송되기 전에 발생 | max_input_tokens 값과 값을 설정하려고 했는지 여부 |
Unknown tool | 아니요 — 모델이 등록되지 않은 항목을 지정 | 해당 에이전트가 등록하는 도구와 모델의 도구 호출 능력이 충분한지 여부 |
| 제공업체의 컨텍스트 길이 거부 | 예 | 모델의 컨텍스트 창과 그에 대한 max_tokens |
| 첫 실행에서 발생하는 인증 또는 모델 없음 오류 | 예 | 제공된 예시는 Anthropic이 2026년 2월 19일 폐기한 Claude ID를 여전히 지정합니다 — OpenManus 요금 및 API 설정에서 다룹니다 |
temperature의 400 오류 | 예 | OpenManus는 하드코딩된 두 추론 ID 이외의 모든 요청에 temperature를 전송하며, temperature = 0.0를 제공합니다 |
| 스크린샷이 조용히 모델에 도달하지 않음 | 부분적으로 그렇습니다 | 비전 기능은 하드코딩된 6개 모델 ID와의 정확한 문자열 일치로 제한되며, 그중 Anthropic 모델 ID는 모두 폐기되었습니다. 설정 페이지에서도 다룹니다 |
다섯 번째 행에는 일반적인 조언이 아니라 이 엔드포인트에 특화된 첫 번째 제공업체 측 세부사항이 있습니다. Kunavo 디스패처는 지원되지 않는 매개변수를 선언한 카탈로그 모델에 대해 전달 전에 temperature, top_p, top_k를 제거합니다. 현재 해당 모델은 Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5입니다. 이 작업은 프로토콜 분기에서 이루어지므로 재시도 시도에서도 제거된 본문이 그대로 사용됩니다. 그 밖의 모든 모델에서는 필드가 OpenManus가 보낸 그대로 전달됩니다. 이는 해당 모델에서 발생하는 특정 400 오류 하나를 제거하지만, OpenManus가 여기서 테스트되었다는 의미는 아닙니다. Kunavo는 OpenManus를 런타임 테스트하지 않았으며, 이 페이지의 어떤 내용도 호환성 결과가 아닙니다.
한 가지를 디버깅하는 대신 경로를 비교 중이라면 OpenAI-compatible API에서 일반 경로가 전달하는 것과 전달하지 않는 것을, LLM gateway에서 여러 모델군에 하나의 키를 사용하는 것이 언제 가치 있는지를, AI cost optimization에서 가장 저렴한 나열 요율과 작업을 완료하는 가장 저렴한 방법의 차이를 다룹니다. 이 차이가 에이전트 루프의 결과를 결정합니다. 다른 클라이언트에서 같은 유형의 진단을 보려면 OpenCode provider not found를 참조하세요.
OpenManus를 수리하는 대신 설정하려는 건가요? 엔드포인트 측에는 [llm]의 세 필드, 즉 model, base_url, api_key가 있습니다. quickstart에서 시작하고, 요청 형식을 chat completions와 대조하며, 키에 자금을 충전할 준비가 되면 create a Kunavo account를 선택하세요. 시도하는 동안 작동하는 경로를 하나 유지하고, 다른 것을 변경하기 전에 제한된 작업을 하나 실행하세요.
자주 묻는 질문
OpenManus의 토큰 제한은 얼마인가요?
기본적으로는 없습니다. OpenManus 자체의 상한은 max_input_tokens 필드이며, app/config.py에서 기본값 None인 Optional로 선언되어 있고 "무제한"으로 설명됩니다. 또한 제공된 어떤 구성 예시에도 나타나지 않습니다. 따라서 기본 설치는 자체 토큰 제한 오류를 발생시키지 않으며, 도달하는 제한은 대신 제공자에서 발생합니다. 이 값을 설정하면 LLM.check_token_limit()는 self.total_input_tokens + input_tokens를 해당 값과 비교하므로, 요청별 컨텍스트 검사가 아니라 전체 실행에 대한 누적 입력 예산이 됩니다. 이는 모델의 컨텍스트 창과 무관하며, 한 번의 응답을 제한하는 max_tokens와도 무관합니다. max_tokens는 config/config.example.toml에서 8192로 제공됩니다. 세 항목 모두 2026년 9월 21일 main 브랜치에서 확인했습니다.
OpenManus가 토큰 제한을 보고하기 전에 멈추는 이유는 무엇인가요?
제한 오류가 재시도되기 때문입니다. 주석에는 재시도하지 않는다고 쓰여 있지만 실제로는 그렇지 않습니다. app/llm.py의 세 @retry 데코레이터(ask, ask_with_images 및 ask_tool)는 모두 retry_if_exception_type((OpenAIError, Exception, ValueError))로 작성되어 있고 뒤에 "# Don't retry TokenLimitExceeded" 주석이 붙어 있습니다. TokenLimitExceeded는 OpenManusError를 상속하고, OpenManusError는 Exception을 상속하므로 일반적인 Exception 항목이 이를 일치시킵니다. 그 결과 tenacity는 wait_random_exponential(min=1, max=60) 백오프와 함께 stop_after_attempt(6)까지 재시도합니다. 에이전트 자체의 핸들러도 이 형태를 확인합니다. app/agent/toolcall.py는 isinstance(e.__cause__, TokenLimitExceeded)를 검사하며, 이것이 tenacity RetryError가 전달되는 방식입니다. 그런 다음에야 "Maximum token limit reached, cannot continue execution"을 출력합니다. 수정안은 존재하지만 병합되지 않았습니다. PR #1348은 2026년 8월 10일 병합되지 않은 채 종료되었고, 재제출된 #1407은 2026년 9월 21일에도 여전히 열려 있으며 병합되지 않았습니다. 이는 실행으로 재현한 결과가 아니라 소스에서 읽은 내용입니다.
OpenManus에서 Error: Unknown tool 'BrowserUseTool'을 어떻게 수정하나요?
체크아웃을 업데이트하세요. 현재 OpenManus main에는 해당 클래스가 존재하지 않습니다. 로컬 브라우저 도구는 2026년 8월 15일 커밋 ab8dfe43 및 05c5bbb1에서 제거되었습니다. app/tool/에는 browser_use_tool.py가 없고, 트리 전체에서 BrowserUseTool 문자열이 나타나는 유일한 곳은 app/agent/sandbox_agent.py의 주석 처리된 줄입니다. main.py가 빌드하는 기본 Manus 에이전트에서는 브라우저 작업이 이제 uvx browser-use --cli-mcp로 시작되는 프로세스 외부 MCP 서버이며, browser_exec 및 browser_screenshot이라는 도구를 제공합니다. 별도의 Daytona-sandbox 진입점인 sandbox_main.py는 sandbox_browser라는 자체 로컬 브라우저 도구를 여전히 등록합니다. 문제 #789를 보고한 사람이 실행하던 2025년 3월 코드에서는 모델이 등록된 도구 이름 대신 Python 클래스 이름을 출력한 것이 원인이었습니다. 해당 로그에는 바로 다음 단계에서 browser_use를 호출했을 때 정상적으로 디스패치된 내용이 보이며, 종료 문장은 "BrowserUseTool seems not work, but browser_use can"입니다. 이 문자열 자체는 일반적입니다. app/agent/toolcall.py는 available_tools.tool_map에 없는 모든 이름에 대해 f"Error: Unknown tool '{name}'"을 반환하므로, 현재도 모델이 임의로 만든 모든 도구에 대해 동일한 메시지가 표시됩니다.
이슈 #789는 해결되었으며, 해결 사항이 포함된 OpenManus 버전은 무엇인가요?
해결되지 않았으며 인용할 버전도 없습니다. "Result: Error: Unknown tool 'BrowserUseTool'"인 이슈 #789는 2025년 3월 18일에 등록되었고 2026년 9월 21일에도 여전히 열려 있었으며, 비활성으로 표시되어 있고 댓글은 세 개였습니다. 댓글 하나는 더 강력한 모델을 제안했고, 제보자는 하나를 사용해 보겠다고 동의했으며, 나머지 하나는 비활성 봇이 남긴 댓글이었습니다. 관련 토큰 한도 보고인 이슈 #779 "hitting token limit"는 2026년 9월 17일 동일한 비활성 봇에 의해 state_reason이 not_planned인 상태로 종료되었는데, 이는 수정이 아니라 시간 초과입니다. 또한 OpenManus에는 현재 명명할 수 있는 릴리스가 없습니다. 유일한 세 태그 v0.1.0, v0.2.0, v0.3.0은 2025년 4월 10일 서로 34초 이내에 모두 게시되었고 그 이후 태그가 추가되지 않았으므로, 모두 태그가 없는 main을 실행합니다. 버전 번호가 아니라 커밋 날짜를 인용하세요.
API 제공업체를 바꾸면 OpenManus의 토큰 오류나 도구 오류가 해결되나요?
아니요. 두 오류 유형 모두 실제로 제공업체에 의해 발생하는 오류와 구분해야 합니다. 위에서 언급한 토큰 한도 메시지는 요청이 전송되기 전에 OpenManus가 사용자가 설정한 한도를 기준으로 자체적으로 계산한 결과이므로 어떤 엔드포인트도 이를 바꿀 수 없습니다. Unknown tool 메시지는 모델이 등록되지 않은 항목을 이름으로 지정할 때 OpenManus의 도구 디스패치가 생성하는 것으로, 모델의 도구 호출 충실도에 관한 문제입니다. 이슈 #789에서 제시된 유일한 조언도 바로 그 이유로 다른 모델을 사용해 보라는 것이었습니다. 다른 엔드포인트가 바꾸는 것은 다음과 같습니다. 제공업체 측 컨텍스트 길이 거부는 TokenLimitExceeded가 아니라 OpenAIError로 도착합니다. 제공된 예시 설정을 새로 복사하면 토큰 오류가 아니라 모델 오류가 발생하는데, Anthropic이 2026년 2월 19일 폐기한 Claude ID를 여전히 지정하기 때문입니다. 또한 OpenManus는 하드코딩된 두 개의 추론 ID 이외의 모든 경우에 temperature를 항상 전송하므로, 해당 제공업체가 그 매개변수를 폐기한 모델에서는 400 형태의 오류가 발생합니다.
OpenManus는 제가 사용하는 제공업체와 같은 방식으로 토큰을 계산하나요?
아니요. OpenManus는 tiktoken을 사용해 로컬에서 계산하며, LLM.__init__은 try 블록 안에서 tiktoken.encoding_for_model(self.model)을 호출하고 KeyError가 발생하면 cl100k_base로 대체합니다. Claude 또는 Gemini ID, 혹은 tiktoken에 사전 설정이 없는 게이트웨이 네임스페이스 ID의 경우 OpenManus가 적용하는 예산은 제공업체의 계산값이 아니라 cl100k_base 추정값입니다. 또한 TokenCounter는 자체 고정값을 추가합니다. 메시지당 4토큰, 서식 토큰 2개, 낮은 세부 수준으로 처리하는 이미지당 85토큰, 높은 세부 수준으로 처리하는 타일당 170토큰입니다. OpenManus의 로그 합계가 아니라 제공업체 계정에 기록된 사용량과 대조하세요. 2026년 9월 21일 main 브랜치에서 확인했으며, requirements.txt에는 tiktoken~=0.9.0이 고정되어 있습니다.
2026년 9월 21일에 확인했으며 범위를 더 넓히지는 않았습니다. app/llm.py, app/config.py, app/agent/toolcall.py, app/agent/manus.py, app/agent/base.py, app/agent/sandbox_agent.py, app/tool/sandbox/sb_browser_tool.py, sandbox_main.py, app/exceptions.py, requirements.txt, config/config.example.toml 및 main 브랜치의 README, app/tool/ 디렉터리 목록, 삭제된 브라우저 도구의 커밋 기록, 이슈 #779 및 #789와 해당 댓글, PR #1348, #1391, #1407의 GitHub 기록, 저장소 및 릴리스 메타데이터, Anthropic의 모델 폐기 페이지를 확인했습니다. 실행한 내용은 없습니다. 설치, OpenManus 실행, 어느 오류의 재현, 어떤 엔드포인트에서든 OpenManus를 통한 요청 전송을 수행하지 않았습니다. 따라서 여기의 모든 동작 관련 주장은 소스를 읽은 결과이지 관찰된 실패가 아니며, 성공적인 최소 실행도 수행하지 않았으므로 보고하지 않습니다. Kunavo 토큰 요율은 실시간 카탈로그에서 가져왔으며 모든 달러 금액은 측정된 작업 비용이 아니라 예시적인 토큰 산술입니다.