Codex CLI 모델 선택: /model로 모델과 reasoning effort를 처음 고르는 법
TL;DR
Codex CLI를 연 뒤 운영체제 셸이 아니라 TUI 입력창에
/model
을 입력합니다. 현재 계정에 표시된 모델을 고르고 제공되는 reasoning level을 선택한 다음
/status
에서 모델과 reasoning 표시를 확인하면 첫 설정이 끝납니다. 공식 문서의 예시나 다른 사용자의 화면보다 지금 내 picker를 기준으로 판단해야 합니다.
핵심 3줄 요약
핵심 1
/model
은 Codex CLI의 active model과 제공되는 reasoning effort를 고르는 slash command입니다.
핵심 2
모델과 reasoning level 목록은 현재 계정의 picker에서 확인하며 플랜·지역·가격·최소 버전을 문서 밖에서 추정하지 않습니다.
핵심 3
첫 완료 기준은 모델 요청이나 파일 수정이 아니라 선택 결과를
/status
에서 확인하고 기록하는 것입니다.
이 글에서 다룰 내용
-
/model을 어디에 입력하고 어떤 화면을 확인하는지 - 모델 선택과 Fast service tier 전환이 왜 다른지
- 현재 picker에서 모델과 reasoning level을 고르는 순서
-
/status로 적용 결과를 확인하는 방법 - 실제 프로젝트 작업 전에 남길 검토 기록과 승인 지점
Codex CLI
/model
은 무엇인가
/model
은 Codex CLI의 active model을 고르고, 해당 모델에서 제공될 때 reasoning effort까지 선택하는 명령입니다. OpenAI 공식 문서의 섹션 이름은
Set the active model with /model
이며, Codex를 열고 composer에서 명령을 실행한 뒤 popup에서 모델을 고르라고 안내합니다.
이 명령은 운영체제 셸에 입력하는
codex -m <model_name>
과 위치가 다릅니다.
/model
은 이미 열린 Codex TUI의 입력창에서 실행합니다. 모델을 선택하면 transcript에 변경 결과가 표시되고, 공식 문서는
/status
로 다시 확인하라고 안내합니다.
/fast
와도 구분해야 합니다. 최근 공개한
/fast
글은 현재 모델의 Fast service tier를 켜고 끄는 흐름입니다.
이번 글의
/model
은 사용할 모델과 제공되는 reasoning level을 고르는 기능입니다. 첫 명령, picker, 확인할 상태가 모두 다릅니다.
언제 이 기능이 잘 맞는가
Codex를 시작했는데 현재 어떤 모델이 선택됐는지 확신하기 어려울 때 먼저 확인합니다. 작업 설명을 입력하기 전 picker를 열면 현재 계정에서 실제로 선택할 수 있는 항목을 볼 수 있습니다.
같은 세션에서 다른 종류의 작업으로 넘어가기 전에 선택 상태를 재확인할 때도 유용합니다. 다만 모델 이름만 바꾼다고 작업 결과가 검증되는 것은 아닙니다. 요구 사항, 변경 금지 범위, 테스트, 사람의 diff 검토는 별도로 남겨야 합니다.
이 기능은 여러 모델의 우열을 가리는 도구가 아닙니다. 이 글의 첫 시험은 한 모델을 현재 reasoning level로 다시 선택하고 상태를 읽는 데서 끝납니다.
실제 코드 요청, 도구 실행, 파일 변경은 다음 승인 단계로 분리합니다. 현재 계정의 picker가 선택 범위의 기준입니다.
시작 전에 확인할 경계
공식
/model
섹션은 모델 선택과
/status
검증 순서를 설명하지만 플랜, 지역, 언어, 운영체제, 최소 버전, 모델별 가격을 확정하지 않습니다. 문서의 예시 모델이 보이지 않아도 원인을 업데이트나 재설치로 단정하지 않습니다. 현재 계정의 picker와 조직 정책부터 확인합니다.
2026년 8월 25일
codex-cli 0.144.6
격리 시험에서는
Select Model and Effort
화면과 별도의
Select Reasoning Level
화면을 확인했습니다. reasoning 목록에는
Low (default)
,
Medium
,
High
,
Extra high
,
More reasoning
항목이 보였습니다. 이는 해당 버전과 시험 계정에서 관찰한 값이며 모든 계정의 고정 목록이 아닙니다.
첫 시험은 비민감한 빈 디렉터리에서 진행합니다. 실제 저장소, 고객 자료, 자격증명, 운영 명령을 넣지 않습니다. picker를 열고 현재 모델을 다시 선택한 뒤
/status
를 확인하는 동안 모델 turn과 프로젝트 파일 생성은 필요하지 않습니다.
/model
로 모델과 reasoning level을 고르는 순서
1단계: 비민감한 작업 폴더에서 Codex를 엽니다
실제 프로젝트 대신 빈 시험 폴더에서 Codex CLI를 시작합니다. 화면 상단의
model:
줄에 현재 모델이 표시될 수 있지만 이 표시는 현재 상태 확인용입니다. 선택지를 바꾸려면 composer를 사용합니다.
2단계: 입력창에
/model
을 씁니다
›
가 보이는 Codex TUI composer에
/model
을 입력합니다. 운영체제 셸 프롬프트에 쓰지 않습니다. Enter를 누르기 전에 slash command가 인식됐는지 확인하면 일반 요청으로 잘못 보내는 일을 줄일 수 있습니다.
격리 시험에서는 완성 항목을 선택했습니다. 이어서 Enter를 한 번 더 누르자
Select Model and Effort
picker가 열렸습니다.
키 입력 방식은 현재 TUI의 completion 상태에 따라 다를 수 있으므로 popup이 열렸는지 화면으로 확인합니다. 모델 응답이 시작되면 명령 실행 증거로 취급하지 않습니다.
3단계: 현재 계정의 모델 목록을 읽습니다
picker에서 현재 모델에는
(current)
표시가 붙었습니다. 위·아래 키로 항목을 이동하되 다른 문서의 목록을 그대로 재현하려고 하지 않습니다. 공식 문서는
gpt-5.6-luna
와
gpt-5.6-terra
를 예로 들지만 실제 선택 범위는 지금 보이는 popup이 기준입니다.
처음에는 기존 current 모델을 다시 선택합니다. 기능 위치와 다음 화면을 확인하면서 의도하지 않은 모델 변경을 피할 수 있습니다.
4단계: 제공되는 reasoning level을 고릅니다
모델을 선택하면 현재 화면이
Select Reasoning Level
로 이어질 수 있습니다. 각 항목의 화면 설명을 읽고 승인된 수준을 선택합니다. 특정 level이 보이지 않으면 현재 모델에서 제공된다고 추정하지 않습니다.
격리 시험에서는
gpt-5.6-sol
의
Low (default)
를 그대로 선택했습니다. 이 확인은 Low가 모든 작업에 적합하다는 추천이 아니라 picker와 상태 검증 흐름을 재현하기 위한 것입니다.
5단계: 선택 결과를
/status
에서 확인합니다
composer로 돌아오면
/status
를 실행합니다. 시험 화면의
Model:
줄에는
gpt-5.6-sol (reasoning low, summaries auto)
가 표시됐습니다. 최소한 선택한 모델과 reasoning 표시가 의도와 맞는지 확인합니다.
공식 문서는 새 모델이 transcript에 확인된다고 설명하고
/status
검증을 권합니다. 특정 필드의 위치나 전체 상태 항목은 고정값으로 가정하지 않습니다. 상태에서 필요한 정보만 읽고 계정, session ID, 제한 정보는 외부 기록에 복사하지 않습니다.
6단계: 첫 시험 기록을 남기고 종료합니다
기록에는 확인 날짜, 설치 버전, 선택한 모델, reasoning 표시, 프로젝트 파일 생성 여부, 모델 turn 시작 여부만 남깁니다. 시험에서는
codex-cli 0.144.6
,
gpt-5.6-sol
,
reasoning low
, 프로젝트 파일 0개, 모델 turn 없음으로 확인했습니다.
이 기록은 품질 평가나 벤치마크가 아닙니다. 실제 프로젝트에서 어떤 모델을 사용할지는 작업 범위와 조직 정책을 확인한 사람이 별도로 승인합니다.
그대로 복사해 쓸 검토 프롬프트
목표: 현재 선택한 Codex 모델과 reasoning level이 다음 작업의 첫 검토에 맞는지 확인한다.
허용 입력: 비민감한 작업 목적, 예상 파일 수, 변경 금지 범위, 선택한 모델명, /status의 reasoning 표시
제외 입력: 소스 코드 전문, 자격증명, 고객 데이터, 운영 명령, 계정 정보, session ID
출력 형식: 현재 선택 | 작업 요구 | 확인할 위험 | 다음 행동의 4열 검토표와 확인 필요 항목
완료 기준: 설정과 작업 요구를 분리하고 실제 코드·명령·파일을 사용하지 않은 검토표를 만든다.
추정 금지: picker에 없는 모델·reasoning level·플랜·가격·지역·성능을 지어내지 않는다.
승인 지점: 모델 변경, 실제 프로젝트 열기, 도구 실행, 파일 수정은 사람이 검토표를 확인한 뒤 별도로 승인한다.
아래 프롬프트는
/model
선택을 마친 뒤 실제 작업을 시작하기 전에 사용합니다. 민감한 코드나 파일을 붙이지 않고 작업 범위만 검토하는 용도입니다.
프롬프트의 답변도 추천 근거일 뿐입니다. picker의 실제 선택지와 조직 정책을 사람이 대조해야 다음 단계로 넘어갈 수 있습니다.
실전 활용 팁
모델 선택과 작업 검증을 한 단계로 묶지 않습니다.
/model
과
/status
는 현재 세션 설정을 확인하는 기능이며 테스트 통과, 코드 정확성, 보안 검토를 대신하지 않습니다.
설정을 바꿀 때는 변경 전과 변경 후의
Model:
줄만 비교하면 기록이 단순해집니다. 계정 이메일, session ID, limits 같은 정보는 공개 문서나 팀 채널에 남기지 않습니다. 화면 캡처가 필요하다면 먼저 가립니다.
작업 중
/fast
,
/statusline
, profile 설정을 함께 볼 수 있습니다. 기록에는 각 역할을 분리합니다.
/fast
는 service tier,
/statusline
은 footer 표시,
--profile
은 세션 시작 시 불러오는 설정 계층입니다.
/model
의 완료 기준은 active model과 reasoning 표시 확인입니다.
주의할 점
높은 reasoning level이 항상 더 정확하다고 단정하지 않습니다. 현재 UI의 설명은 선택을 돕지만 실제 결과는 입력, 저장소 상태, 도구 권한, 테스트와 검토 절차의 영향을 함께 받습니다.
공식 문서에 예시 모델명이 있다고 해서 모든 사용자에게 같은 목록이 제공되는 것은 아닙니다. 보이지 않는 모델을 강제로 활성화하려고 설정 파일, 인증, 조직 정책을 바꾸지 않습니다. 지원 조건이 불분명하면 현재 계정 화면과 관리자 안내를 확인합니다.
첫 시험에서 실제 작업을 보내지 않습니다.
/model
과
/status
만으로 위치와 상태를 확인할 수 있습니다. 모델 변경, reasoning level 변경, usage가 발생하는 실제 요청은 별도 승인 뒤 실행합니다.
자주 묻는 질문
/model
은 운영체제 셸에 입력하나요?
아닙니다. Codex CLI가 열린 뒤
›
가 보이는 TUI composer에 입력합니다. 새 세션 시작 옵션인
codex -m <model_name>
과 입력 위치가 다릅니다.
모델을 고르면 reasoning level도 항상 나오나요?
공식 문서는 reasoning effort를 사용할 수 있을 때 함께 고른다고 설명합니다. 현재 모델과 계정의 picker에 표시된 항목만 사용하고 보이지 않는 level을 추정하지 않습니다.
/status
가 모델과 reasoning을 모두 보여 주나요?
2026년 8월 25일
codex-cli 0.144.6
시험에서는
Model:
줄에 모델과
reasoning low
가 함께 표시됐습니다. 필드 구성은 고정이라고 단정하지 말고 현재 화면에서 선택 결과를 확인합니다.
/fast
와
/model
은 같은 기능인가요?
아닙니다.
/fast
는 현재 모델의 Fast service tier를 전환하고
/model
은 active model과 제공되는 reasoning level을 선택합니다. 첫 명령과 기대 결과가 다릅니다.
출처
공식 문서는
/model
입력, popup 선택, transcript 확인,
/status
검증을 설명합니다. 설치 표면 기록은 2026년 8월 25일
codex-cli 0.144.6
의 비민감한 격리 시험에서 확인했습니다.
마무리
입력 위치를 알면 Codex CLI 모델 선택은 금방 끝납니다. composer에서
/model
을 열고 현재 계정의 모델과 reasoning level을 고른 뒤
/status
에서 결과를 확인합니다.
첫 시험은 설정 확인에서 멈춥니다. 실제 프로젝트 작업은 범위, 금지 사항, 테스트와 승인자를 정한 다음 시작해야 모델 선택과 결과 검증이 섞이지 않습니다.
