Codex CLI에 서드파티(third-party) 모델을 설정하더라도, 설정 파일을 저장하는 것만으로는 연결 확인이 완료되지 않습니다. 모델 목록 가져오기, API 본문, Profile 로딩, 도구 호출 순서로 확인하면 문제가 발생한 단계를 쉽게 분리할 수 있습니다.
본 기사에서는 2026년 11월 13일에 Windows PowerShell에서 진행한 기록을 사용합니다.
| 항목 | 검증 환경 |
|---|
| OS／셸 | Windows PowerShell |
PowerShell에서 다음 명령어를 실행합니다.
이번 출력은 codex-cli 0.168.0이었습니다.
버전이 정상적으로 표시되면, Codex CLI 본체는 설치된 것입니다. 아주 오래된 버전을 사용하고 있다면, 새로운 설정 항목을 추가하기 전에 업데이트합니다.
오래된 모델 목록을 그대로 Profile에 복사하는 것이 아니라, 현재 계정에서 보이는 목록을 먼저 확인합니다.
이번 목록 가져오기는 HTTP 200으로 응답받았으며, 170개의 모델이 반환되었습니다. 이전에 목록에 있던 12개 ID와 대조해 보니, 다음 7개가 발견되었습니다.
| 계열 | 현재 목록에서 발견된 ID |
|---|
| DeepSeek | deepseek-v4-pro, deepseek-v4-flash, deepseek-v4.1-flash |
| Kimi | kimi-k2.8-preview, kimi-k2.7-code |
| GLM | glm-5.3, glm-5.3-flash |
발견되지 않은 5개는 다음과 같습니다.
doubao-seed-2.1-pro,
doubao-seed-2.1-lite,
doubao-seed-2.0-mini,
doubao-seed-evolving,
minimax-m3입니다.
여기서 HTTP 200은 목록을 가져올 수 있었다는 것만을 의미합니다. 목록에 있는 모든 모델이 추론(inference)을 완료할 수 있다는 의미는 아닙니다.
config.toml
에서는 Provider와 인증 방법을 모아서 정의합니다.
if ([string]::IsNullOrWhiteSpace($env:CRAZYROUTER_API_KEY)) { "미설정" } else { "설정됨" }
echo $env:CRAZYROUTER_API_KEY
이 코드를 통해 전체 Key를 출력하지 마십시오. 스크린샷이나 오류 로그에도 포함시키지 마십시오. 설정됨은 PowerShell에서 변수가 감지되었음을 나타낼 뿐이며, Key의 유효성은 API 요청을 통해 확인합니다.
최소 테스트에서는 OK만 반환하도록 요청했습니다. deepseek-v4.1-flash의 결과는 다음과 같습니다:
| API | HTTP | 시간 | 입력/프롬프트 | 출력 | 표시 결과 |
|---|
| Responses | 200 | 2249ms | 35 token | 30 token | OK |
| Chat Completions | 200 | 2394ms | 35 token | 38 token | OK |
두 경우 모두 HTTP 200뿐만 아니라 표시 가능한 OK를 반환했습니다. Codex 측에서는 wire_api = "responses"를 사용합니다.
반면, glm-5.3-flash에서는 결과가 달랐습니다. 출력 상한이 16 token일 때는 거의 모든 것이 추론에 사용되어 마지막 OK가 나오지 않았습니다. 상한을 64 token으로 늘려도 표시 가능한 답변은 없었습니다.
이 경우 확인된 것은 인증과 라우팅까지만입니다. 본문이 없기 때문에 'API를 이용할 수 있었다'고 간주하지 않습니다.
짧은 DeepSeek 요청의 입력은 각각 35 token이었습니다. Responses의 출력은 30 token, Chat Completions는 38 token입니다. 반면, Codex의 Profile 실행에서는 세션 컨텍스트 로드와 도구 호출이 있기 때문에, 입력 91,635 token, 출력 850 token이 기록되었습니다. 먼저 짧은 API 테스트를 수행하면 답변을 반환하지 않는 모델로 인해 완전한 Codex 세션을 실행할 필요가 없습니다.
프로젝트 디렉토리에서 다음을 실행합니다.
codex --profile ds41-flash
시작 후, 모델명과 Provider가 Profile대로인지 확인합니다. --profile은 모델과 Provider를 함께 고정할 수 있습니다. -m만으로는 Provider 선택까지 대체하지 못합니다.
이번 확인 작업은 현재 프로젝트에 있는 README.md를 읽고 프로젝트의 목적을 반환하는 것이었습니다. 실제 세션 기록에는 다음 이벤트가 남아 있습니다.
- Profile
ds41-flash이 로드됨. - 모델은 deepseek-v4.1-flash였음. - Codex가 thread와 turn을 시작함.
Get-Content -LiteralPath README.md -TotalCount 60, cmd /c dir, echo hi, Get-Content README.md를 순차적으로 시도함. - 로컬의 커맨드 정책이 4개 명령어 모두를 거부하여 파일 본문은 읽히지 않았습니다.
여기까지로 Profile 로딩, 모델 요청, 도구 호출 시작은 확인되었습니다. 다만, 파일 읽기 작업의 완료는 확인되지 않았습니다. 남아있는 문제는 로컬의 샌드박스, 승인, 또는 커맨드 정책입니다.
실행 중에는 Model metadata not found; using fallback metadata도 표시되었습니다. 서드파티 모델이 Codex 내장 목록에 없는 경우, 폴백 메타데이터(fallback metadata)가 사용될 수 있습니다. 이 경고가 있는 상태에서는 컨텍스트 윈도우(context window), 기능 플래그(feature flag), token 추정치가 모델의 공개 값과 완전히 일치한다고 가정하지 않는 것이 안전합니다.
문제 증상 및 조치 사항
| 증상 | 먼저 확인해야 할 항목 | 조치 사항 |
|---|
401 Unauthorized | 새로운 PowerShell에서 환경 변수가 보이는지 | 창을 다시 열고 Key와 계정을 확인합니다. |
model not found | 현재 목록에 ID가 있는지 | 오래된 목록이 아닌, 현재의 ID를 복사합니다. |
| HTTP 200이나 본문이 비어 있음 | 출력 상한선 (Output limit) | 상한선을 늘리거나 다른 모델을 시도합니다. |
| Codex가 다른 모델로 실행됨 | Profile 이름, model, model_provider | |
| 3가지 항목을 종합적으로 확인 | | |
| 메타데이터 경고 (metadata warning) | Codex 내장 목록에 있는 모델인지 | 실제로 테스트한 범위만을 결론으로 합니다. |
| 툴 명령이 거부됨 | 샌드박스(Sandbox), 승인, 명령어 정책(Command policy) | 권한을 확인하고 동일한 작업을 재실행합니다. |
| 설정 변경이 반영되지 않음 | 오래된 터미널이나 세션 | Codex를 종료하고 새로운 PowerShell에서 시작합니다. |
이번에 확인된 것은 모델 목록 가져오기, deepseek-v4.1-flash를 이용한 2가지 종류의 API 응답, ds41-flash Profile 로딩 및 툴 호출 시작입니다.
설정은 Provider를 config.toml 파일에 모으고, 모델을 독립적인 Profile로 분리하여 codex --profile ds41-flash 명령어로 실행합니다. README.md 읽기는 네 가지 명령어 모두가 로컬 정책에 의해 거부되었기 때문에 아직 완료되지 않았습니다. 다음 확인 지점은 모델 이름이 아니라 로컬의 권한 설정입니다.
