인바운드 Codex 엔드포인트

OpenAI Codex CLI 자체를 shunt로 향하게 하고 ChatGPT/Codex OAuth 계정 풀에 걸쳐 로드 밸런싱하기.

이 사이트의 다른 가이드는 모두 Claude Code를 다른 백엔드로 라우팅합니다. shunt는 그 반대 방향으로도 동작할 수 있습니다: 옵트인 원시 OpenAI Responses 패스스루로, Codex CLI가 자체 base_url을 shunt로 향하게 하고 ChatGPT/Codex OAuth 계정 풀에 걸쳐 로드 밸런싱되도록 합니다. 옵트인이므로 [server.codex_endpoint]가 없으면 관련 라우트가 하나도 등록되지 않고 shunt의 기본 HTTP 화면은 그대로 유지됩니다.

이는 Codex 멀티 계정과 동일한 계정 풀 위에 만들어졌습니다 — 선택, 쿨다운, 갱신은 변경 없이 공유됩니다. 정확한 페일오버 표와 리로드 시맨틱을 포함한 전체 명세는 M11 동작 명세를 참고하세요.

엔드포인트 활성화, Codex CLI를 shunt로 향하게 하기, 클라이언트 인증, 계정 프로비저닝, 자격이 부여된 모델 선택까지 처음부터 끝까지의 설정 안내는 Codex CLI 연결을 따르세요. 이 페이지는 엔드포인트가 무엇을 하는지에 집중하고, 그 가이드는 어떻게 연결하는지의 체크리스트입니다.

엔드포인트 활성화

[server.codex_endpoint]   # 모든 키 선택; 기본값 표시됨
provider = "codex"        # chatgpt_oauth 프로바이더여야 함

shunt check
shunt run

시작 검증은 알 수 없는 provider나 auth = "chatgpt_oauth"를 쓰지 않는 프로바이더를 거부합니다 — 이 엔드포인트는 운영자의 Codex bearer를 주입하므로 chatgpt_oauth 프로바이더만 자격이 있습니다. 모든 키와 기본값은 구성 레퍼런스를, 등록된 라우트는 HTTP 엔드포인트를 참고하세요.

이 옵트인은 Codex CLI 모델 탐색도 파싱 가능하게 만듭니다. GET /models와 GET /backend-api/codex/models는 유효한 폴백 {"models":[]}를 반환합니다. 공유 GET /v1/models 경로에서는 client_version 쿼리 필드가 Anthropic 형태의 헤더보다 우선하여 Codex 형태를 선택하고, 그 필드가 없으면 기존 Anthropic 탐색 응답은 변경되지 않습니다. 이 요청들은 기존 모델 탐색 인증 게이트를 거치며, shunt는 불완전한 Codex 모델 행을 만들지 않습니다.

웹 검색

Codex CLI의 내장 웹 검색 도구(web.run)는 /responses를 붙이는 것과 같은 base URL의 {base_url}/alpha/search로 요청을 보냅니다. shunt는 base URL 형식마다 이 경로를 등록합니다:

POST /backend-api/codex/alpha/search
POST /alpha/search
POST /v1/alpha/search

검색은 Responses 턴과 같은 [server.auth] 정책과 같은 ChatGPT/Codex 계정 풀(세션 고정 선택, 장애 조치, 갱신)을 사용하며, 요청 본문과 응답을 백엔드의 /codex/alpha/search로 그대로 중계합니다. 검색은 모델 턴이 아니므로 [[server.codex_endpoint.routes]]가 적용되지 않고 항상 [server.codex_endpoint].provider로 전달됩니다. 이 라우트는 POST만 받습니다 — 이 도구에는 WebSocket 형식이 없습니다.

클라이언트 analytics sink

Codex CLI는 제품 analytics도 base URL로 전송합니다. shunt는 CLI가 만들 수 있는 두 경로를 모두 받아들입니다:

POST /backend-api/codex/analytics-events/events
POST /codex/analytics-events/events

이 라우트들은 Responses 라우트와 동일한 [server.auth] 정책을 따르지만, 텔레메트리를 업스트림으로 전달하지는 않습니다. 풀링된 계정 하나를 고르면 클라이언트 이벤트가 그 계정에 잘못 귀속되기 때문입니다. 인증 후에는 본문이 잘못됐거나, 읽을 수 없거나, 너무 크더라도 항상 200 {}을 반환합니다.

페이로드와 이벤트 속성은 로깅되지도 내보내지지도 않습니다. shunt는 정제된 event_type만 옵트인 shunt.codex_client_events 카운터의 event 속성으로 기록합니다: 이름에는 소문자 ASCII 문자, 숫자, ., _, -가 최대 64바이트까지 올 수 있고, 유효하지 않은 이름은 other로, 해석되지 않은 배치는 unparsed가 됩니다. Sentry나 OpenTelemetry 메트릭이 활성화되어 있지 않다면 이는 순수한 폐기 sink입니다.

Codex CLI를 shunt로 향하게 하기

Codex CLI는 사용하는 base URL이 무엇이든 항상 그 뒤에 /responses를 붙이므로, 다음 두 가지 ~/.codex/config.toml 형태 모두 동작합니다:

ChatGPT 백엔드의 base URL을 흉내 내기:

chatgpt_base_url = "http://127.0.0.1:3001/backend-api/codex"

또는 커스텀 모델 프로바이더(최상위 model_provider가 이를 선택해야 하며, 그렇지 않으면 CLI는 내장 프로바이더를 유지합니다):

model_provider = "shunt"

[model_providers.shunt]
base_url = "http://127.0.0.1:3001/v1"
wire_api = "responses"

커스텀 프로바이더를 쓰면(CLI에 로컬 로그인이 필요 없도록 requires_openai_auth = false를 추가하세요) shunt를 가리키는 순간 Codex CLI 자체의 ~/.codex/auth.json은 무의미해집니다 — 계정은 매 요청마다 shunt의 풀에서 옵니다. 반면 chatgpt_base_url 형태는 CLI를 ChatGPT 로그인 모드로 유지하므로 여전히 로컬 로그인이 필요하고, 게이팅되지 않은 엔드포인트에서만 동작합니다: CLI의 ChatGPT bearer는 구성된 shunt 토큰이 아니므로 [server.auth]가 이를 거부합니다.

클라이언트 인증

shunt에 [server.auth]가 구성되어 있다면 — 루프백을 넘어서는 모든 경우에 권장됩니다 — 클라이언트 토큰을 OpenAI 스타일 Bearer 키(OPENAI_API_KEY 또는 커스텀 프로바이더의 env_key, LiteLLM/llmgateway 방식)로 제시하거나 x-shunt-token 헤더로 제시하세요:

# A. Bearer — 내장 openai 프로바이더. base URL은 ~/.codex/config.toml에 설정하고
#    OPENAI_BASE_URL 환경 변수로는 설정하지 마세요: 환경 변수를 쓰면 CLI의 Responses
#    WebSocket이 wss://api.openai.com을 계속 가리켜 shunt를 우회합니다. 연결 가이드의
#    "Codex CLI를 shunt로 향하게 하기"를 참고하세요.
openai_base_url = "http://127.0.0.1:3001/v1"

export OPENAI_API_KEY="<shunt-token>"      # Authorization: Bearer로 전송됨

# B. 헤더 — 커스텀 프로바이더가 이를 실어 보냅니다(파일 밖에 두려면 env_http_headers 사용):
[model_providers.shunt]
base_url = "http://127.0.0.1:3001/v1"
wire_api = "responses"
http_headers = { "x-shunt-token" = "<token>" }

[server.auth]가 없으면 엔드포인트는 도달할 수 있는 누구에게나 열려 있습니다 — 루프백이나 개인 용도에는 받아들일 만하지만 공유 게이트웨이에는 적절하지 않습니다. 클라이언트가 제시한 자격 증명은 shunt에 인증하는 데에만 사용됩니다: 이 값은(그리고 CLI가 보내는 어떤 Authorization이든) 제거되며 업스트림으로 전달되지 않습니다. [server.admin] 자격 증명 헤더(기본값 x-shunt-admin-token, 또는 [server.admin] header가 지정한 이름)도 제거됩니다 — 관리 화면이 바로 그 슬롯에서 인증하며, 관리 자격 증명은 업스트림 계정을 프로비저닝할 수 있기 때문입니다. cookie 헤더도 통째로 제거됩니다: 관리 화면은 세션 쿠키 역시 그 슬롯에서 수락하고, shunt는 쿠키 저장소를 두지 않으므로 업스트림이 이에 의존할 일이 없습니다. x-api-key도 [server.auth]가 설정되지 않은 경우를 포함해 무조건 제거됩니다 — 대상 프로바이더는 부팅 시점에 chatgpt_oauth 전용으로 검증되므로, 인바운드 x-api-key 값은 이 업스트림에 대해 결코 유효한 자격 증명이 될 수 없습니다. Claude Code의 apiKeyHelper처럼 Authorization과 x-api-key에 같은 키를 넣는 클라이언트라도 두 번째 슬롯을 통해 그 키가 새어 나가지 않습니다. 인바운드 클라이언트가 실제 Codex CLI이므로, 패스스루는 그 요청 헤더를 그대로 전달하고(version, originator, OpenAI-Beta, x-codex-*, …) 선택된 풀 계정의 Authorization bearer와 chatgpt-account-id만 바꿔 넣습니다. 전체 인증 안내는 Codex CLI 연결을 참고하세요.

WebSocket 전송

세 개의 Responses 경로는 HTTP POST와 인증된 WebSocket GET 업그레이드를 모두 허용합니다. 인증은 101 Switching Protocols 전에 완료됩니다. 소켓에서 generate: false 웜업은 로컬에서 완료되며, 일반 response.create는 기존 HTTP 계정 풀을 재사용하고 업스트림 스트리밍을 강제하여 첫 번째 터미널 이벤트까지 각 SSE data: 페이로드를 WebSocket 텍스트 프레임으로 전달합니다. 턴을 교체하거나 소켓을 닫으면 진행 중인 업스트림 본문이 취소됩니다. 클라이언트 프레임과 SSE 이벤트는 4 MiB로 제한되고, 전송에는 바운디드 백프레셔가 적용되며, 오류 프레임에는 안전한 응답 메타데이터만 포함됩니다.

[server.auth]가 없으면 브라우저의 업그레이드는 Origin과 Host를 비교해 검사하는데, 이 검사는 같은 호스트의 http와 https를 구분하지 못합니다. 따라서 루프백 이외의 용도에서는 [server.auth]로 엔드포인트를 보호하세요.

계정 프로비저닝

Codex 멀티 계정과 동일한 풀을 재사용합니다:

codex login
shunt login codex --name main

[[providers.codex.accounts]]
name = "main"

[[providers.codex.accounts]]가 구성되지 않았고 shunt 계정 스토어도 비어 있으면, 엔드포인트는 기본 ~/.codex/auth.json 자격 증명 하나로 폴백합니다 — 풀링도 페일오버도 없습니다 — 따라서 [server.codex_endpoint]를 설정하는 즉시 Codex 로그인 하나만으로도 동작합니다. (핸들러는 먼저 계정 스토어를 스캔해 발견한 계정을 풀에 넣으므로, 가져온 스토어 계정은 여전히 풀링을 활성화합니다.)

모델을 다른 업스트림으로 라우팅하기

기본적으로 모든 요청은 [server.codex_endpoint]에 지정된 프로바이더 하나로 갑니다. 선택적인 [[server.codex_endpoint.routes]] 테이블을 쓰면 Codex CLI가 모델 id로 다른 Responses 호환 업스트림을 고를 수 있습니다. 라우트가 없는 모델은 기존의 고정 프로바이더 동작을 그대로 유지합니다.

여러 벤더가 Codex CLI용 네이티브 Responses 엔드포인트를 문서화하고 있습니다: Z.ai GLM(https://api.z.ai/api/v1), DeepSeek(https://api.deepseek.com), Kimi Code(https://api.kimi.com/coding/v1), MiniMax(https://api.minimax.io/v1), Mimo(https://api.xiaomimimo.com/v1), OpenRouter(https://openrouter.ai/api/v1), Vercel AI Gateway(https://ai-gateway.vercel.sh/codex/v1), 그리고 순정 OpenAI. shunt는 프로바이더의 base_url 뒤에 /responses를 붙이므로, 벤더가 Codex용으로 안내하는 그 base URL을 그대로 적으면 됩니다. 업스트림은 Responses API를 네이티브로 구현해야 합니다 — Responses → Chat Completions 어댑터는 없습니다.

[providers.glm]
kind = "responses"
auth = "api_key"
api_key_env = "GLM_API_KEY"
base_url = "https://api.z.ai/api/v1"

[providers.deepseek]
kind = "responses"
auth = "api_key"
api_key_env = "DEEPSEEK_API_KEY"
base_url = "https://api.deepseek.com"

[server.codex_endpoint]
provider = "codex"

[[server.codex_endpoint.routes]]
model = "glm-5.3"
provider = "glm"

[[server.codex_endpoint.routes]]
model = "deepseek-v4-flash"
provider = "deepseek"

upstream_model은 선택 사항이며 기본값은 model입니다. CLI에 입력하는 id와 벤더가 실제로 제공하는 id가 다를 때 지정하세요. 라우팅 대상 프로바이더는 실제 자격 증명을 가져야 합니다 — 클라이언트 자신의 Authorization은 항상 제거되므로, 자격 증명이 없는 인증 모드(passthrough 또는 none)는 부팅 시 거부됩니다. shunt에 내장된 kimi 프리셋은 kind = "anthropic"이므로, Kimi Code로 향하는 Codex 라우트에는 별도의 kind = "responses" 프로바이더가 필요합니다 — Anthropic 종류의 프리셋으로 Codex 모델을 라우팅하면 부팅 시 거부됩니다.

CLI 쪽에서는 Codex가 shunt를 바라보게 하고 model로 라우트를 선택합니다:

# ~/.codex/config.toml
model = "glm-5.3"
model_provider = "shunt"
model_catalog_json = "~/.codex/models.json"

[model_providers.shunt]
base_url = "http://127.0.0.1:3001/v1"
wire_api = "responses"
env_key = "SHUNT_TOKEN"

shunt는 Codex CLI 디스커버리 요청에 유효한 폴백인 {"models":[]}로 응답하지만, 디스커버리 목록에 Codex 라우트를 노출하지는 않습니다. CLI는 이들 벤더가 안내하는 대로 model_catalog_json이 가리키는 ~/.codex/models.json 카탈로그에서 슬러그 메타데이터를 얻습니다. shunt 라우트를 고르는 것은 오직 model 값입니다.

ChatGPT가 아닌 업스트림으로 라우팅된 요청에서 달라지는 점:

헤더 허용 목록. 새 허용 목록은 먼저 클라이언트의 content-type(없으면 application/json)과 accept만 가져온 뒤, 해석된 자격 증명과 라우팅 대상 업스트림 자체가 요구하는 헤더를 더합니다: xAI/Grok에서는 생략되는 OpenAI-Beta: responses=experimental, xai_oauth 라우트의 Grok CLI identity 헤더 세트, 그리고 api_key 라우트가 정확히 api.openai.com을 대상으로 하며 비어 있지 않은 conversation id가 해석된 경우 새로 생성한 네 개의 세션 친화도 헤더(session-id, thread-id, x-client-request-id, x-codex-window-id)입니다. 클라이언트가 보낸 authorization, x-api-key, chatgpt-account-id, originator, version, user-agent, session-id, thread-id, x-client-request-id, x-codex-*, x-shunt-*는 계속 제거되며, 순정 OpenAI용 값도 전달하는 것이 아니라 새로 생성합니다. xAI와 그 밖의 서드파티 OpenAI 호환 호스트에는 세션 친화도 헤더가 추가되지 않습니다. API 키 경로는 accept: text/event-stream도 새로 만들지 않습니다.
본문 model 재작성. upstream_model이 요청된 모델과 다르면 shunt가 최상위 model만 바꾸고 나머지 필드는 그대로 둡니다. JSON 객체가 아닌 본문은 그대로 보내지 않고 400으로 거부합니다.
identity 인코딩. zstd 요청 본문은 먼저 디코딩되며 — 순정 Responses API는 그 인코딩을 받지 않습니다 — content-encoding은 전달되지 않습니다.
자격 증명 하나, 페일오버 없음. 라우팅된 서드파티 뒤에는 페일오버 풀이 없으므로 429나 5xx는 회전을 유발하지 않고 retry-after와 함께 그대로 릴레이됩니다. 풀을 인식하는 유일한 예외는 이름 있는 계정이 있는 xai_oauth 라우트입니다. 이 라우트도 요청을 한 번만 보내고(업스트림 실패는 회전하지 않고 릴레이) 자격 증명은 풀 선택 순서에서 로그인을 불러올 수 있는 첫 계정입니다(프로바이더의 account/accounts 범위를 적용). 로그인을 불러오지 못한 계정은 쿨다운되고 건너뜁니다. 이름 있는 계정이 없으면 ~/.shunt/xai-auth.json입니다.

매칭은 정확 일치이며 대소문자를 구분하고 문자 집합 제한이 없습니다. 따라서 MiniMax-M3, openai/gpt-5.6-sol, ~openai/gpt-latest 같은 벤더 슬러그도 적은 그대로 라우팅됩니다. 다른 chatgpt_oauth 프로바이더로 향하는 라우트라면 전체 풀 패스스루가 그대로 유지됩니다. 라우트는 라이브 구성에서 읽으므로 리로드 시점에 반영됩니다.

지출 한도

[server.spend]를 구성하면 이 엔드포인트도 /v1/messages와 같은 주체별 상한을 검사하고 계측합니다. 구성하지 않으면 아래 내용은 적용되지 않습니다. 전체 동작은 Gateway spend limits(영문)를 참고하세요.

검사 시점. 모든 턴은 업스트림을 호출하기 전에 검사합니다. 세 Responses 경로의 HTTP POST와 Responses WebSocket이 모두 대상입니다. 주체는 정적 [server.auth] 토큰 이름, 검증된 JWT 이메일, 또는 [server.auth]가 꺼져 있을 때의 익명 주체입니다. 이 엔드포인트는 gateway 로그인 세션을 받지 않습니다.
거부 응답. 상한을 넘은 턴은 429와 {"error":{"message":…,"type":"usage_limit_reached","code":"usage_limit_reached","resets_at":<에포크 초>}}를 받고, retry-after, x-should-retry: false, x-codex-promo-message: <blocked_message> 헤더가 붙습니다. promo 헤더는 blocked_message가 순수 ASCII일 때만 보내며, 텍스트는 항상 메시지에도 들어갑니다. 이름이 붙는 상한은 도달한 상한 중 가장 늦게 리셋되는 것입니다. fail_closed_on_error가 켜져 있으면, 지출 상태를 확인할 수 없는 상한 보유 주체를 같은 type으로 거부하며 resets_at과 retry-after는 없습니다.
Codex CLI가 보여 주는 것. 고정된 버전 rust-v0.159.3에서 Codex CLI는 이 오류를 재시도하지 않습니다. resets_at으로 만든 자체 문구(“You’ve hit your usage limit … Try again at”)를 표시하고, 헤더가 있으면 promo 메시지를 함께 보여 주며, 서버 메시지는 무시합니다. 이는 Codex CLI의 동작이므로 다른 버전에서는 다를 수 있습니다.
WebSocket. 거부된 response.create에는 같은 오류와 retry-after, x-codex-promo-message를 담은 {"type":"error","status":429,"error":{…},"headers":{…}} 프레임 하나가 갑니다. 소켓은 열린 채로 유지되고, 이후 각 턴을 새로 검사하며, generate: false 워밍업은 검사하지 않습니다.
웹 검색. /alpha/search와 그 별칭은 상한을 넘으면 거부되며 계측하지 않습니다.
계측. 완료된 턴은 Responses usage로 청구되어 /v1/messages가 쓰는 것과 같은 카운터에 합산되므로, 하나의 상한이 두 표면을 함께 제한합니다. 캐시된 토큰은 캐시 읽기 요율, 나머지 입력은 입력 요율로 청구하며, 추론 토큰은 출력에 포함되고 캐시 쓰기는 없습니다. 사용량 보고 없이 끝난 턴(클라이언트 종료, 교체된 턴, 끊어진 스트림)은 요청 본문으로 추정한 입력에 이미 전달된 출력을 더한 하한으로 청구합니다. 스트리밍이 아닌 2xx JSON 본문도 같은 방식으로 usage에서 청구하며, 입력을 보고하지 않은 본문은 대신 추정한 입력으로 청구합니다.
GPT 가격. 내장 요금표에는 GPT/Codex 가격이 없으므로 해당 모델은 행을 추가하기 전까지 알 수 없는 모델 요율(백만 토큰당 $5 / $25 / $0.50 / $6.25, 모델당 경고 한 번)로 청구됩니다.

[[server.spend.pricing.overrides]]
upstream = "codex"       # 엔드포인트의 provider
model = "gpt-6.1-sol"
input = 1.00             # 예시 요율, 100만 토큰당 USD
output = 8.00
cache_read = 0.10
cache_write = 1.00

`/v1/messages`와 다른 점

변환이 없습니다. 인바운드 Responses 본문은 바이트 단위로 그대로 업스트림에 전달되고, 업스트림 응답도 — SSE든 JSON이든, 성공이든 오류든 — 그대로 릴레이됩니다(status와 content-type 보존). Anthropic Messages ⇄ Responses 변환 단계는 아예 없습니다.
압축된 요청 본문도 그대로 통과합니다. 현재 Codex 릴리스는 ChatGPT 백엔드와 통신할 때 요청 본문을 zstd로 압축하며, 여기에는 이 엔드포인트를 가리키는 chatgpt_base_url 형태도 포함됩니다. 바이트와 그 content-encoding: zstd 헤더는 변경 없이 전달되고, shunt는 메트릭·로그·스팬에 쓸 요청의 model을 읽기 위해 메모리에서 사본만 추가로 디코딩합니다. shunt가 디코딩할 수 없는 본문도 릴레이에는 문제가 없으며 — model 레이블만 unknown으로 낮아지고, 그 이유를 밝히는 경고가 남습니다.
모델 기반 라우팅은 선택 기능입니다. 기본적으로 모든 요청은 [server.codex_endpoint]에 지정된 단 하나의 프로바이더로 가고 본문의 model은 그대로 전달됩니다. [[server.codex_endpoint.routes]]를 쓰면 정확히 일치하는 model이 해당 항목의 프로바이더를 선택합니다 — 모델을 다른 업스트림으로 라우팅하기 참고.
소진 시에도 그대로 릴레이합니다. 풀링된 모든 계정을 시도했고 업스트림 응답이 최소 한 번 돌아왔다면, shunt는 그것을 Anthropic 형식의 오류로 다시 만들지 않고 마지막 응답을 변경 없이 릴레이합니다. Responses 클라이언트는 실제 ChatGPT 백엔드에서 받았을 원시 형태를 기대하기 때문입니다.
게이트웨이 소유 오류는 OpenAI 형식입니다. 실패가 shunt 자신의 것일 때 — 잘못됐거나 없는 클라이언트 토큰(401), 업스트림 응답 없이 풀을 해석할 수 없는 경우(502), 지나치게 큰 요청 본문, 구성되지 않은 엔드포인트 — shunt는 이를 동일한 status 코드와 함께 OpenAI Responses 오류 형태({"error":{"message":…,"type":…,"code":null}})로 반환합니다. 그러면 Codex CLI가 Anthropic의 {"type":"error",…} 봉투가 아니라 자체 오류 경로로 이를 해석합니다. 릴레이되는 업스트림 오류(백엔드의 429/4xx/5xx)는 여전히 그대로 통과합니다.
두 가지 인바운드 전송. HTTP POST는 바이트 충실도를 유지하며, WebSocket GET은 바운디드 이벤트 전달을 추가합니다. 이는 프로바이더의 아웃바운드 websocket = true 설정에 의존하지 않습니다.

보안

루프백을 넘어서는 모든 경우에 [server.auth]로 이 엔드포인트를 게이팅하세요 — 프로바이더가 매 요청마다 실제 Codex bearer를 주입합니다.
클라이언트 자신의 자격 증명은 어떤 것도 Codex 백엔드에 닿지 않습니다. 패스스루는 Codex CLI 자체의 요청 헤더를 그대로 전달하고 선택된 풀 계정의 bearer와 chatgpt-account-id만 바꿔 넣습니다(shunt 클라이언트 토큰 헤더, [server.admin] 자격 증명 헤더, cookie 헤더 전체, 내부용 x-shunt-inbound-client 라벨, 클라이언트의 Authorization/chatgpt-account-id, 그리고 x-api-key는 모두 제거되며 전달되지 않습니다).
부팅 시 한 번 결정되는 것은 엔드포인트의 HTTP 라우트 등록뿐입니다. 런타임에 [server.codex_endpoint]를 켜거나 끄면 해당 경로를 추가·제거하려면 재시작이 필요하다는 경고가 로깅됩니다. 테이블이 담고 있는 내용은 모두 핫 리로드됩니다 — 대상 provider와 [[server.codex_endpoint.routes]] 모델 테이블 전체를 매 요청마다 라이브 config에서 읽으므로, 라우트를 추가·수정·삭제하면 리로드 시점에 반영됩니다.