Agent Zero의 LiteLLM 모델 오류는 키 문제보다 접두사 또는 역할 문제인 경우가 더 많습니다. Agent Zero는 사용자가 입력한 모델 이름을 그대로 보내지 않기 때문입니다. agent0ai/agent-zero main에서 models.py는 모든 LiteLLM 호출 전에 f"{provider}/{model}"을 구성합니다. 채팅은 385행, 임베딩은 800행이며, provider 부분은 드롭다운 라벨이 아니라 conf/model_providers.yaml에서 가져옵니다.
나머지 내용을 결정하는 두 가지 버전 정보가 있습니다. 최신 릴리스는 v2.12이며 2026년 9월 9일에 게시되었고, 이전 frdel/agent-zero 경로는 이제 agent0ai/agent-zero로 확인되므로 오래된 clone 명령과 이슈 링크는 리디렉션됩니다. 또한 requirements.txt는 litellm==1.88.1를 고정하며 주석은 # CVE-2026-42271 fix: patched floor is 1.83.7입니다. PyPI 기록상 이는 2026년 6월 9일 버전이고, 현재 1.102.0은 2026년 9월 20일 버전입니다. 증상은 LiteLLM의 최신 문서가 아니라 1.88.1을 기준으로 확인하세요. 모두 2026년 9월 21일에 확인했습니다.
키를 건드리기 전에 상태 코드를 읽으세요
예외에 정수 상태 코드가 포함되어 있으면 _is_transient_litellm_error가 그 코드만으로 결정합니다. 408, 429, 500, 502, 503, 504이면 true이고, 그 밖의 모든 5xx도 true이며, 다른 모든 상태에서는 false입니다. 상태 코드가 없을 때만 예외 클래스 일치로 대체하며, 여기에는 시간 초과와 연결 오류도 포함됩니다. 따라서 "상태 없음"만이 가리킬 4xx/5xx 없이 재시도가 일어날 수 있는 경우입니다. 아래 표의 모든 클래스에는 상태 코드가 있으며, litellm 1.88.1 휠 내부에서 확인했습니다.
| litellm 1.88.1의 클래스 | 상태 | 여기서 일반적으로 의미하는 것 | 재시도 여부 |
|---|---|---|---|
AuthenticationError | 401 | 엔드포인트가 자격 증명을 거부했거나 자격 증명이 전달되지 않음 | 아니요 |
BadRequestError | 400 | 아래의 두 제공자 확인 실패를 모두 포함 | 아니요 |
LiteLLMUnknownProvider (하위 클래스 BadRequestError) | 400 | 이 엔드포인트에서 LiteLLM이 경로를 제공하지 않는 접두사 | 아니요 |
ContextWindowExceededError (하위 클래스 BadRequestError) | 400 | 컨텍스트가 너무 긴 것이지 잘못된 ID가 아님 | 아니요 |
NotFoundError | 404 | 기본 URL의 경로가 잘못되었거나 엔드포인트에서 제공하지 않는 ID | 아니요 |
RateLimitError | 429 | 업스트림에서 요청이 제한됨 | 예 |
ServiceUnavailableError, InternalServerError | 5xx | 업스트림 오류 | 예 |
예외 하나와 사각지대 하나가 있습니다. models.py 638행은 got_any_chunk가 true일 때 재시도하지 않고 예외를 발생시키므로, 스트리밍 중 발생한 일시적 오류는 재시도되지 않습니다. 따라서 "즉시 실패했다"는 단서일 뿐 증거는 아닙니다. 또한 configure_litellm()는 가져오기 시 실행되어 LITELLM_LOG=ERROR와 litellm.suppress_debug_info = True를 설정합니다. 1.88.1에서 get_llm_provider_logic.py의 제공자 목록 힌트는 if litellm.suppress_debug_info is False로 보호됩니다. LiteLLM이 제공자 목록을 안내하기 위해 출력할 유일한 줄을 Agent Zero가 끄는 것입니다.
입력한 ID와 실제로 전송되는 ID가 다름
제공자마다 두 개의 식별자가 있으며, provider config 헤더가 이를 설명합니다. 제공자 ID는 "설정 UI 드롭다운"과 API 키 환경 변수를 결정하고, litellm_provider는 "LiteLLM에서 이에 대응하는 제공자 이름"입니다. 앞에 붙는 것은 두 번째 값입니다. 타사 OpenAI 호환 엔드포인트의 제공자 ID는 other("Other OpenAI compatible")이고, 해당 litellm_provider는 openai이며, _adjust_call_args도 other를 openai로 다시 매핑합니다. 실제 전송 값은 openai/<your-model>이며, LiteLLM 문서의 양식입니다. 따라서 그대로 ID만 입력하세요. 이 두 코드 위치를 읽어 보면 접두사를 직접 추가할 경우 openai/openai/gpt-4o가 되지만, 이는 관찰된 오류가 아니라 코드에 근거한 추론입니다.
제공자 확인에 실패하면 1.88.1에는 서로 다른 두 오류 문자열이 있으며 둘 다 400 오류입니다. get_llm_provider_logic.py는 "LLM Provider NOT provided … You passed model=…"라는 메시지와 함께 BadRequestError를 발생시킵니다. 문자열에서 사용할 수 있는 값이 도출되지 않았다는 뜻입니다. exceptions.py 902행에 정의된 LiteLLMUnknownProvider는 "Unmapped LLM provider for this endpoint. You passed model=…, custom_llm_provider=…"라는 메시지를 포함합니다. 제공자가 실제로 도출되었지만 해당 엔드포인트에는 그 제공자를 위한 경로가 없다는 뜻입니다. 제공자가 한 역할에서는 작동하지만 다른 역할에서는 작동하지 않을 때 예상되는 것은 두 번째 오류입니다.
한 가지 충돌 때문에 사람들이 잘못된 필드로 이동합니다. Agent Zero의 FAQ는 OpenRouter에는 openai/gpt-5.3가 올바르지만, 접두사 없이 사용하는 네이티브 OpenAI 제공자에는 잘못되었다고 설명합니다. 또한 설치 가이드의 이름 표에는 OpenAI가 "Model name only"로 나옵니다. 이 설명들은 텍스트 상자를 가리키며, 코드가 그 위에 접두사를 추가합니다. 계층을 구분하면 둘 다 맞습니다. 다만 해당 표에는 문서 오류도 있습니다. OpenAI 행의 예시에 Anthropic 모델 ID가 사용되어 있으므로 그 셀을 그대로 복사하지 마세요.
실패한 세 역할 중 어느 역할인지 확인하세요
Agent Zero는 채팅, 유틸리티, 임베딩이라는 세 역할을 독립적으로 구성하며, 각 역할에는 고유한 제공자, 모델 이름, API 기본 URL이 있습니다. 설정 섹션은 chat_model, utility_model, embedding_model이고, 기존의 평면 키는 chat_model_*, util_model_*, embed_model_*입니다. settings.json에서 잘못된 규칙을 검색하면 아무것도 찾지 못합니다. 알아둘 만한 네 번째 선택 항목도 있습니다. 기본 제공 브라우저 플러그인에는 자체 model_preset가 있으며, 비어 있는 상태로 제공되고 "비어 있으면 유효한 Main Model 사용"이라고 문서화되어 있습니다. 따라서 이를 설정하지 않았다면 브라우저 도구 오류는 다른 이름으로 나타난 채팅 역할의 실패입니다. 또한 채팅 응답 하나가 성공했다고 해서 세 역할이 모두 작동한다는 뜻은 아닙니다.
임베딩 역할은 트리아지를 바꾸는 두 가지 차이가 있습니다. LiteLLMEmbeddingWrapper.embed는 try/except나 시도 루프 없이 LiteLLM의 embedding()를 호출하므로 클래스와 관계없이 첫 시도에서 예외를 발생시킵니다. 또한 기본값은 제공자 huggingface와 이름 sentence-transformers/all-MiniLM-L6-v2입니다. models.py는 huggingface 이름이 sentence-transformers/로 시작하면 이를 HuggingFace API 호출을 피한다고 코드에 설명된 프로세스 내 래퍼로 라우팅하므로, 해당 오류에는 네트워크 호출이 포함되지 않을 수 있습니다.
Kunavo는 임베딩 모델을 제공하지 않으므로 Agent Zero에서 Kunavo 키로 채울 수 있는 역할은 채팅과 유틸리티입니다.
OpenRouter는 확인된 역할 분할이며, 이 사례에서 추론이 아니라 유지 관리자의 수정이 적용된 유일한 분기입니다. 이슈 #1597 "LiteLLM에 제공자 경로가 없어 OpenRouter 임베딩 모델이 실패함"은 2026년 5월 2일에 열렸고 2026년 8월 27일, 같은 날 v2.11이 출시되기 몇 시간 전에 종료되었습니다. 여기서는 쉽게 혼동할 수 있는 두 가지를 구분해야 합니다. 구성은 역할별로 제공자를 실제로 라우팅합니다. chat는 네이티브 litellm_provider: openrouter를 유지하고, embedding는 명시적인 api_base와 함께 litellm_provider: openai를 사용하며, 이는 OpenRouter가 "아직 LiteLLM에서 지원되지 않음"이라는 유지 관리자 TODO 아래에 있습니다. 하지만 이 분할은 v2.10 태그와 main에서 동일하므로 이슈를 종료시킨 원인이 아닙니다. 실제 변경은 models.py의 한 줄입니다. v2.10에서 임베딩 래퍼는 f"{provider}/{model}" if provider != "openai" else model를 구성하여 openai로 라우팅된 모든 임베딩에서 접두사를 제거했지만, v2.11부터는 무조건 접두사를 추가합니다. 그래서 유지 관리자의 종료 메모에는 슬래시가 포함된 ID가 이제 엔드포인트에 온전히 도달한다고 적혀 있습니다. 이 분기에서 해결책은 설정 변경이 아니라 업그레이드입니다.
키 조회와 "키 변경"이 자주 빗나가는 이유
get_api_key(service)는 세 환경 변수 이름을 정해진 순서로 읽고, 마지막에는 리터럴 문자열 "None"로 대체합니다.
# Provider id `other` ("Other OpenAI compatible"). models.py reads these
# three names in this order and stops at the first non-empty value.
API_KEY_OTHER=sk-...
# OTHER_API_KEY=sk-...
# OTHER_API_TOKEN=sk-...
# A comma in the value is not a syntax error: models.py splits on it
# and rotates the resulting keys round-robin.해당 플레이스홀더는 필터링됩니다. 호출 위치에서 api_key not in ("None", "NA")를 확인한 뒤에만 연결하므로, 키가 해석되지 않으면 어떤 api_key 인자도 전송되지 않으며 LiteLLM이 자체 환경 변수 조회를 적용합니다. 선택하지 않은 자격 증명에서 401이 도착할 수 있습니다. 두 번째 조회는 다른 service 값을 사용합니다. _merge_provider_defaults는 원래 제공자 ID인 original 아래에서 키를 읽은 다음, _get_litellm_chat가 get_api_key(provider_name)로 대체합니다. 이 시점의 이름은 LiteLLM 제공자 이름이며, openai는 other에 해당합니다. 따라서 같은 .env에 OpenAI 키가 있는데 API_KEY_OTHER가 설정되지 않았다면 OpenAI 키가 엔드포인트로 전송됩니다. 이 내용은 main의 두 함수를 읽어 확인한 것이며, 여기서 문서화되거나 런타임 테스트된 내용은 아닙니다.
설치 가이드는 External Services → Other OpenAI-compatible API keys 아래에 키를 넣고, 제공자로 OpenAI Compatible을 선택하도록 안내합니다. 근처에 설명된 두 증상은 모델 ID 오류가 아닙니다. 전송해도 아무 일도 일어나지 않으면 FAQ는 Settings에 키가 설정되지 않았기 때문이라고 설명합니다. 또한 ChatGPT Plus에는 API 크레딧이 없습니다. 다만 기본 제공 OAuth plugin은 OpenAI 계정으로 로그인하는 codex_oauth 연결을 제공하므로, "구독만으로 Agent Zero를 구동할 수 없다"고 말하면 부정확합니다.
엔드포인트와 서로 모순되어 보이는 두 규칙
other 제공자는 기본 api_base를 제공하지 않으며, ModelConfig.build_kwargs는 해당 필드가 비어 있지 않을 때만 전달합니다. 따라서 API URL이 비어 있으면 기본 URL이 전송되지 않고 LiteLLM의 기본 openai가 적용됩니다. 1.88.1에서 이것이 어떤 호스트로 해석되는지는 여기서 확인하지 않았습니다. 빈 URL에서 401이 발생하면 진단이 끝난 것이 아니라 필드를 채워야 한다는 신호로 보세요. LiteLLM의 호환 엔드포인트 페이지에는 서로 반대 방향으로 보이는 두 문장이 있습니다. "기본 URL에 /v1/embedding 같은 것을 추가하지 마세요"와 "테스트할 때 Not Found Error가 표시되면 api_base에 /v1 접미사가 있는지 확인하세요." 이는 하나의 규칙으로 정리됩니다. /v1에서 끝내고 그 뒤에는 아무것도 추가하지 마세요.
Docker 환경에서는 설치 가이드가 명확합니다. API 기본 URL의 localhost와 127.0.0.1는 컨테이너를 의미하므로 http://host.docker.internal:<port> 또는 기본 Linux 브리지의 http://172.17.0.1:<port> 같은 게이트웨이 주소를 사용하고, 호스트 루프백에 바인딩된 서버를 0.0.0.0처럼 Docker에서 접근할 수 있는 주소로 옮기세요. 그런 다음 읽고 있는 구성이 실제로 실행된 구성인지 확인하세요. A0_SET_ 프리셋은 초기 기본값일 뿐이며, "settings.json에 값이 저장되면 이 환경 변수보다 우선합니다." 재시작도 필요합니다. 별도로 이슈 #1769는 2026년 7월 15일에 열렸고 아직 열려 있으며, 모델에 등록된 제공자와 실제 제공하는 제공자가 다를 때 LiteLLM이 exit(-9)를 호출한다고 보고합니다. 이는 한 신고자의 분석이며 여기서 확인하거나 재현하지 않았습니다.
잘못된 수정으로 치르는 대가
실패한 유틸리티 역할을 잠재우는 가장 빠른 방법은 이를 주 모델로 지정하는 것입니다. 이 방법은 작동하지만, 설치 가이드가 요약과 메모리 추출에 사용한다고 설명하는 트래픽이 주 모델 요율로 청구됩니다. 다음 수치는 측정된 작업 비용이나 청구 상한이 아닌 예시용 토큰 산술입니다. 주 모델 작업이 하루 입력 1200k 토큰과 출력 60k 토큰, 유틸리티 트래픽이 입력 320k와 출력 24k라고 가정하고, 백만 토큰당 현재 Kunavo 카탈로그 요율을 적용합니다.
| 유틸리티 슬롯의 모델 | 1M당 입력 / 출력 | 하루 유틸리티 트래픽 |
|---|---|---|
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.924 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.325 |
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.308 |
주 역할 자체의 하루 모델 비용은 $3.150입니다. 유틸리티 역할을 Claude Sonnet 4.6로 통합하면 Claude Haiku 4.5 모델이 $0.308인 상황에서 $0.924가 추가됩니다. 다만 기능 요건을 주의하세요. 설치 가이드는 유틸리티 모델이 "메모리를 안정적으로 추출하고 통합할 수 있을 만큼 충분히 강력해야 한다"고 경고하며, 약 4B 수준의 매우 작은 모델은 안정적인 컨텍스트 추출에 대체로 실패한다고 설명합니다. 가이드는 이를 오류가 아니라 작업 실패로 설명하므로, "모델에서 오류가 발생했다"고 진단하면 안 되는 분기입니다.
Agent Zero 자체에는 라이선스 비용이 없습니다. main 브랜치의 LICENSE는 MIT 라이선스 문서이며, 저작권자는 "Agent Zero, s.r.o"입니다. 따라서 비용은 구성한 각 역할에서 사용하는 모델 토큰에 대해 발생합니다. Kunavo의 카탈로그 금액은 청구 금액의 하한선이지 상한선이 아닙니다. 업스트림이 요금을 보고하면 카탈로그 비용과 업스트림 비용에 해당 마크업을 곱한 금액 중 더 큰 금액이 청구됩니다. 최소 충전 금액은 선불 크레딧 $10입니다. 청구 세부 정보를 참조하세요.
역할 뒤에 둘 경로
| 경로 | 유리한 경우 | 이 실패 모드에서 발생하는 비용 |
|---|---|---|
| 공급자 직접 API | 하루 종일 한 제공자를 사용하며 해당 제공자의 캐싱 및 배치 조건을 활용할 때 | 제공자마다 고유한 항목과 접두사가 있으므로 두 번째 제공자는 정확히 설정해야 할 이름 집합이 하나 더 생깁니다 |
| 이름이 지정된 게이트웨이(OpenRouter) | 작업별로 모델을 전환하고 Agent Zero가 기본적으로 라우팅하기를 원할 때 | 채팅에만 네이티브로 적용됩니다. 임베딩 항목은 대신 명시적인 기본 URL과 함께 openai를 통해 라우팅됩니다 |
other를 통한 OpenAI 호환 게이트웨이 | Agent Zero에 항목이 없는 엔드포인트에서 키 하나와 잔액 하나만 사용할 때 | 자동 완성에 사용할 모델 목록이 없고, 기본 URL도 없으며, 자체 키가 설정되지 않으면 키가 OpenAI 이름으로 대체됩니다 |
| OAuth 플러그인을 통한 계정 로그인 | 이미 연결 가능한 계정(Codex 요금제, GitHub Copilot)에 비용을 지불하고 있으며 키를 붙여 넣고 싶지 않을 때 | README에는 이러한 연결이 사용자에게 API 키를 전혀 요구하지 않고 계정에 연결한다고 되어 있습니다. 또한 Google Cloud Gemini 항목은 구독이 아니라 Gemini API로 청구된다고 명시합니다 |
| 로컬 모델 서버 | 요청별 비용 없이 소규모 또는 비공개 작업을 수행할 때 | Docker 주소 규칙이 적용되며 유틸리티 역할의 기능 요건이 여기서 가장 엄격하게 작용합니다 |
역할별 예산은 Agent Zero API costs를, 세 번째 슬롯은 임베딩 모델 변경을, 일반적인 기본 URL 및 접두사 규칙은 OpenAI-compatible API를 참조하세요. Kunavo 키를 other에 연결하려면 오류 참조에서 시작한 다음 계정을 생성하세요. Agent Zero는 Kunavo 엔드포인트에 대해 런타임 테스트를 거치지 않았으므로 시도하는 동안 작동하는 경로를 유지하세요.
자주 묻는 질문
Agent Zero는 올바르게 입력한 모델 이름을 왜 거부하나요?
Agent Zero가 입력한 이름을 그대로 보내지 않기 때문입니다. agent0ai/agent-zero main의 models.py는 모든 LiteLLM 호출 전에 f"{provider}/{model}"을 구성합니다. 채팅 역할은 385행, 임베딩 역할은 800행입니다. provider 부분은 Settings 드롭다운의 라벨이 아니라 conf/model_providers.yaml의 litellm_provider 값입니다. 공급자 ID `other`("Other OpenAI compatible")의 경우 해당 값은 openai이고 _adjust_call_args가 이를 다시 재매핑하므로 LiteLLM이 받는 값은 openai/<your-model>입니다. 접두사 없이 순수 ID만 입력하세요. 두 코드 위치를 읽어 보면 openai/gpt-4o를 직접 입력할 경우 openai/openai/gpt-4o가 생성됩니다. 이 결과는 코드에서 추론한 것이며 관찰되었거나 문서화된 내용이 아닙니다. 2026년 9월 21일 소스 확인.
Agent Zero에서 LiteLLM 모델 오류가 발생하면 API 키가 잘못된 것인가요?
대개 그렇지 않으며, 상태 코드가 둘을 구분합니다. Agent Zero가 고정하는 litellm 1.88.1 wheel에서 인증 오류는 401의 AuthenticationError인 반면, 두 공급자 확인 오류는 400입니다. get_llm_provider_logic.py는 "LLM Provider NOT provided"와 함께 BadRequestError를 발생시키고, exceptions.py 902행의 BadRequestError 하위 클래스인 LiteLLMUnknownProvider는 "Unmapped LLM provider for this endpoint"를 포함합니다. 둘 다 정수 status_code를 포함하며 Agent Zero의 _is_transient_litellm_error는 408, 429 및 5xx에서만 상태 코드가 있는 오류를 재시도합니다. 따라서 두 오류 클래스 모두 첫 시도에서 표시되며 어느 하나도 다른 하나에 대한 증거가 아닙니다. 키를 교체하기 전에 모델 문자열과 base URL을 확인하세요.
Agent Zero에서 임베딩 모델만 왜 실패하나요?
해당 역할이 채팅 역할과 다른 방식으로 라우팅되고 재시도되기 때문입니다. models.py의 LiteLLMEmbeddingWrapper.embed는 try/except나 시도 루프 없이 LiteLLM의 embedding()을 호출하므로 오류 종류와 관계없이 첫 시도에서 발생합니다. 해당 역할의 기본 제공 값은 공급자 huggingface, 이름 sentence-transformers/all-MiniLM-L6-v2이며, models.py는 sentence-transformers/로 시작하는 huggingface 이름을 HuggingFace API 호출을 피한다고 코드에서 설명하는 프로세스 내 래퍼로 라우팅합니다. 따라서 여기서의 실패에는 네트워크 호출이 전혀 관여하지 않을 수도 있습니다. OpenRouter는 문서화된 분기 사례입니다. conf/model_providers.yaml은 채팅에서는 OpenRouter를 네이티브로 라우팅하지만 임베딩에서는 명시적인 api_base와 함께 litellm_provider openai로 라우팅하며, 이는 유지 관리자 TODO 아래에 있습니다. Kunavo는 임베딩 모델을 제공하지 않으므로 해당 슬롯은 로컬 기본값이나 이 단계를 판매하는 공급자에 맡겨야 합니다.
Agent Zero는 어떤 LiteLLM 버전을 사용하나요?
agent0ai/agent-zero main의 requirements.txt는 litellm==1.88.1을 고정하며, 인라인 주석은 "CVE-2026-42271 fix: patched floor is 1.83.7"입니다. PyPI에는 1.88.1이 2026년 6월 9일 업로드된 것으로 기록되어 있고, 현재 릴리스는 2026년 9월 20일 업로드된 1.102.0입니다. 따라서 1.88.1 이후 LiteLLM이 추가한 동작, 매개변수 지원 및 오류 문구는 Agent Zero 설치에 포함되지 않으며, 현재 LiteLLM 문서와 증상을 대조하면 실제로 실행 중이지 않은 코드를 설명하게 될 수 있습니다. 2026년 9월 21일 확인했습니다. 물론 컨테이너 내부에서 직접 pip install을 실행하면 버전이 바뀔 수 있습니다.
Agent Zero의 Model Name 필드에 공급자 접두사를 입력해야 하나요?
아니요. Agent Zero 자체 문서도 입력하는 필드에 관해 같은 내용을 설명합니다. FAQ에는 openai/gpt-5.3이 OpenRouter에는 올바르지만 네이티브 OpenAI 공급자에는 올바르지 않으며, 네이티브 OpenAI는 "접두사 없이" 입력한다고 나와 있습니다. 설치 가이드의 이름 지정 표도 OpenAI를 "Model name only"로 표시합니다. 이 문장들은 텍스트 상자를 설명하고, 코드는 입력한 값 위에 LiteLLM 공급자를 다시 붙입니다. 어느 계층을 말하는지 명시하면 둘 다 사실이며, 이를 흐리는 문장은 사실이 아닙니다. 다만 해당 표에는 주의할 점이 있습니다. OpenAI 행의 예시에 Anthropic 모델 ID를 사용하므로, 작동하는 OpenAI ID가 아니라 형식을 보여 주는 예시입니다.
Agent Zero는 왜 어떤 오류는 재시도하고 다른 오류는 재시도하지 않나요?
예외에 HTTP 상태가 포함되어 있으면 그 상태가 유일한 결정 기준입니다. models.py의 _is_transient_litellm_error는 먼저 정수 status_code를 확인합니다. 408, 429, 500, 502, 503 및 504는 true이고 다른 모든 5xx도 true이며 그 외 모든 상태는 false입니다. 따라서 400이나 401은 아무리 심각해 보여도 최종 오류입니다. 상태 코드가 없을 때만 예외 클래스, 타임아웃 및 연결 오류 등을 확인하는 방식으로 대체하므로, HTTP 상태가 없는 오류는 여전히 재시도될 수 있습니다. 또 하나의 조건이 사용자를 혼란스럽게 합니다. models.py 638행은 got_any_chunk가 true이면 재시도하지 않고 오류를 발생시키므로 스트리밍이 시작된 후 발생한 일시적 오류도 재시도되지 않습니다. "즉시 실패했다"는 사실만으로 오류가 400 또는 401이었다고 단정할 수는 없습니다.
Agent Zero의 동작은 2026년 9월 21일에 agent0ai/agent-zero의 main 브랜치(models.py와 conf/model_providers.yaml) 및 문서, 릴리스, 이슈를 소스에서 확인했습니다. LiteLLM 예외 클래스와 오류 문자열은 Agent Zero가 고정한 버전인 PyPI의 litellm 1.88.1 휠 내부에서 확인했습니다. 여기서는 런타임 테스트를 수행하지 않았습니다. 설치하지 않았고 오류를 처음부터 끝까지 재현하지도 않았습니다. Kunavo 토큰 요율은 실시간 카탈로그에서 가져왔으며 모든 달러 수치는 예시용 토큰 산술입니다.