일상 운전

5.1좋은 지시의 구성요소

공식공식 베스트 프랙티스는 프롬프트에 넣을 기본 네 가지를 제시합니다. 목표(무엇을 바꾸거나 만들려는가), 맥락(어떤 파일·폴더·문서·예제·에러가 관련되는가), 제약(어떤 표준·구조·안전 요구·관례를 따라야 하는가), 완료 조건(무엇이 참이면 끝인가). 이렇게 주면 범위가 좁혀지고 가정이 줄고 검토하기 쉬운 결과가 나옵니다. best-practices

공식완벽한 프롬프트가 전제 조건은 아닙니다. 공식 문서는 "코덱스는 프롬프트가 완벽하지 않아도 쓸 만하고, 명확한 프롬프트는 결과를 더 신뢰할 수 있게 만든다"고 구분해 적습니다. 큰 저장소나 위험이 큰 작업일수록 그 차이가 커집니다. best-practices

네 요소를 넣은 지시 예

목표: 결제 실패 시 재시도 로직이 중복 청구를 만드는 버그를 고친다.
맥락: services/billing/retry.ts, 재현 테스트는 tests/billing/retry.spec.ts 의 3번 케이스.
제약: 공개 API 시그니처를 바꾸지 않는다. 새 의존성을 추가하지 않는다.
완료 조건: 3번 케이스가 통과하고, 기존 결제 테스트 전체가 그대로 통과한다.

공식프롬프팅 문서는 여기에 경계를 한두 개만 명시하라고 덧붙입니다. 잘못 바뀌면 결과를 못 쓰게 되는 것, 또는 다른 사람에게 영향이 가기 전에 검토하고 싶은 것에 한정합니다. 모든 단계를 통제하려 들 필요는 없습니다. prompting

5.2에디터 맥락을 쓰는 지시

공식IDE 확장의 값은 이미 열린 맥락을 재설명하지 않는 데 있습니다. 열린 파일, 선택한 코드, 최근 채팅을 컴포저에서 바로 참조합니다. codex/ide

공식CLI에서는 @를 입력해 작업 공간의 파일을 검색하고 그 경로를 프롬프트에 넣습니다. /mention으로 파일이나 폴더를 붙일 수도 있고, /ide로 열린 파일과 현재 선택 영역 같은 IDE 맥락을 다음 프롬프트에 포함시킬 수 있습니다. developer-commands

5.3작업을 쪼개는 기준

공식기준은 "한 채팅에 하나의 일관된 결과"입니다. 같은 문제의 연장이면 같은 채팅에 있는 편이 낫습니다. 추론 흐름이 보존되기 때문입니다. 작업이 실제로 갈라질 때만 분기합니다. 프로젝트 전체를 채팅 하나에 몰아넣는 것은 공식 문서가 명시한 흔한 실수 중 하나입니다. 맥락이 부풀고 시간이 갈수록 결과가 나빠집니다. best-practices

위 네 명령의 근거는 모두 CLI 명령 레퍼런스입니다. developer-commands

5.4계획을 먼저 받기

공식작업이 복잡하거나 모호하거나 설명하기 어려우면 코딩 전에 계획을 먼저 시킵니다. 가장 쉽고 효과적인 방법은 플랜 모드입니다. /plan 또는 Shift+Tab으로 전환합니다. 플랜 모드에서 코덱스는 맥락을 모으고, 확인 질문을 하고, 구현 전에 더 나은 계획을 세웁니다. best-practices

공식원하는 것이 흐릿할 때 쓰는 두 번째 방법은 거꾸로 인터뷰시키기입니다. 코덱스에게 먼저 질문하게 하고, 가정을 뒤집어 보게 한 뒤, 흐릿한 아이디어를 구체적인 것으로 바꾸고 나서 코드를 쓰게 합니다. best-practices

관행플랜 모드가 값을 하는 지점은 "계획이 좋아서"가 아니라 계획 단계에서 틀린 가정이 보이기 때문입니다. 구현이 끝난 뒤에 방향이 틀렸다는 것을 알면 그 턴 전체가 낭비되지만, 계획에서 잡으면 한 문장으로 고쳐집니다. 공식 베스트 프랙티스와 쿡북의 실행 계획 문서가 같은 이유를 듭니다. 후자는 계획서를 "긴 구현이 시작되기 전에 코덱스가 취할 접근을 검증하는" 문서로 정의합니다. best-practices cookbook codex_exec_plans

5.5오래 걸리는 작업 다루기

공식여러 단계가 걸리는 일에는 /goal로 목표 모드를 켭니다. 목표 텍스트가 첫 프롬프트이자 완료 판정 기준이 됩니다. 데스크톱 앱·CLI·IDE 확장 모두에서 씁니다. long-running-work

공식목표는 코덱스가 자기 진행을 스스로 검증할 수 있게 씁니다. 세 가지를 넣습니다. long-running-work

공식 문서의 목표 예시

Migrate this codebase from JavaScript to TypeScript. Preserve existing behavior,
compile in strict mode without explicit `any` types, and make the full test suite pass.

공식결과가 아직 불분명하면 /plan으로 시작해 인터뷰를 시키고, 측정 가능한 성공 기준이 나온 뒤 /goal로 넘깁니다. 데스크톱 앱에서는 컴포저 위에 진행 행이 떠서 일시정지·재개·수정·해제를 할 수 있습니다. long-running-work

5.6중간 개입

공식코덱스가 이미 일하는 중에도 개입할 수 있습니다. CLI에서 방식이 셋으로 갈립니다. developer-commands

공식큐에 넣은 슬래시 명령은 실행 시점에 해석되므로 명령 메뉴나 오류는 현재 턴이 끝난 뒤에 나타납니다. 슬래시 자동완성은 큐에 넣기 전에도 동작합니다. developer-commands

공식세션을 끝내는 것은 Ctrl+C 또는 /exit입니다. 공식 문서는 중요한 작업을 저장하거나 커밋한 뒤에만 쓰라고 덧붙입니다. developer-commands

6.1CLI 화면 구성

공식codex를 서브커맨드 없이 실행하면 대화형 터미널 UI(TUI)가 열립니다. 전역 플래그가 그대로 적용되고 이미지 첨부도 받습니다. 웹 검색은 기본이 캐시 모드이고, 실시간 탐색이 필요하면 --search를 씁니다. developer-commands

공식지금 세션이 어떤 상태인지는 /status가 답합니다. 활성 모델, 승인 정책, 쓰기 허용 경로, 남은 컨텍스트 용량을 확인할 수 있습니다. 하단 상태줄에 무엇을 띄울지는 /statusline으로, 터미널 창 제목은 /title로 고릅니다. developer-commands

세션 상태 확인

/status

6.2슬래시 명령 전량

공식컴포저에 /를 입력하면 슬래시 목록이 열립니다. 아래는 공식 레퍼런스의 CLI 내장 명령을 목적별로 묶은 것입니다. 원문은 알파벳순 한 표이고, 여기서는 쓰임에 따라 나눴습니다. developer-commands

공식/permissions와 /approve는 쓰임이 다릅니다. 앞은 물어보지 않고 할 수 있는 범위 자체를 조정하고, 뒤는 자동 검토가 거부한 동작 하나를 재시도할 때만 씁니다. developer-commands

6.3단축키

공식CLI 대화형 단축키는 여덟 개가 문서화돼 있습니다. developer-commands

공식단축키가 손에 안 맞으면 /keymap으로 재정의하고 config.toml에 저장합니다. 데스크톱 앱과 IDE 확장의 단축키는 각 표면의 명령 레퍼런스에 따로 있습니다. reference/commands

6.4이미지 입력

공식에러 스크린샷, 아키텍처 다이어그램, 디자인 레퍼런스를 첫 프롬프트와 함께 넘기거나 대화형 컴포저에 붙여 넣습니다. CLI 플래그는 codex --image입니다. codex/cli image-inputs

공식프롬프팅 문서는 이미지를 넣을 때 어디를 보라는 것인지를 함께 적으라고 안내합니다. 이미지만 던지고 알아서 읽기를 기대하지 않는 편이 낫습니다. prompting

6.5통합 터미널

공식데스크톱 앱의 각 채팅에는 그 프로젝트나 워크트리 범위로 묶인 터미널이 딸려 있습니다. 오른쪽 위 터미널 아이콘이나 Ctrl+`로 엽니다. integrated-terminal

공식이 터미널의 값은 앱을 떠나지 않고 검증할 수 있다는 데 있습니다. 코덱스가 현재 터미널 출력을 읽을 수 있으므로, 돌아가는 개발 서버 상태나 실패한 빌드를 참조하면서 함께 일할 수 있습니다. integrated-terminal

공식자주 쓰는 명령은 로컬 환경의 액션으로 정의해 둡니다. 액션은 앱에서 단축 항목으로 나타나고 통합 터미널에서 실행됩니다. 상세는 L4 27장에 있습니다. integrated-terminal

6.6웹 검색 켜기

공식로컬 코덱스 채팅은 기본이 캐시 검색입니다. 캐시 모드는 OpenAI가 관리하는 색인에서 결과를 가져오므로 임의의 실시간 페이지를 가져오지 않고, 그만큼 프롬프트 인젝션 노출이 줄어듭니다. 줄어드는 것이지 없어지는 것은 아닙니다. web-search

한 번만 실시간 검색으로

codex --search "Summarize the latest release notes for this dependency"

config.toml 로 기본값 바꾸기

web_search = "cached"     # 기본값
# web_search = "live"     실시간 탐색(--search 와 같음)
# web_search = "indexed"  검색 색인이 게이트할 때만 외부 접근 허용
# web_search = "disabled" 도구 자체를 끔

공식검색 활동은 대화형 전사와 codex exec --json 출력에 web_search 항목으로 남습니다. 전체 접근 샌드박스로 돌면 웹 검색은 기본이 실시간이 됩니다. web-search agent-approvals-security

7.1서브커맨드 지도

공식CLI는 대화형 세션 하나가 아니라 여러 서브커맨드의 묶음입니다. 목적별로 나누면 이렇습니다. developer-commands

7.2자주 쓰는 플래그

공식공식 레퍼런스는 성숙도 라벨과 함께 플래그 전량을 표로 싣습니다. 여기서는 첫 달에 실제로 손이 가는 것만 추립니다. 전량은 원문이 정본입니다. developer-commands

공식공식 문서가 안전 수칙으로 세 가지를 명시합니다. 감독 없이 도는 로컬 작업에는 --sandbox workspace-write를 쓰고, 전용 샌드박스 VM 안이 아니면 --dangerously-bypass-approvals-and-sandbox를 피하며, 쓰기 범위를 넓혀야 할 때는 danger-full-access 대신 --add-dir를 씁니다. CI에서는 --json과 --output-last-message를 함께 씁니다. developer-commands

공식CLI는 기본값을 ~/.codex/config.toml에서 물려받고, 명령줄의 -c key=value가 그 실행에 한해 우선합니다. developer-commands

7.3세션 재개

공식codex resume은 기본적으로 현재 작업 디렉터리 범위에서 --last를 찾습니다. 전체 세션에서 찾으려면 --all을 붙입니다. 재개 시 전역 플래그(모델·샌드박스 등)를 그대로 받습니다. developer-commands

터미널

# 현재 디렉터리의 가장 최근 세션
codex resume --last

# 모든 세션에서 고르기
codex resume --all

# 이전 세션을 새 채팅으로 분기
codex fork --last

공식현재 작업 디렉터리가 세션의 저장된 디렉터리와 다르면 코덱스가 어느 쪽을 쓸지 묻습니다. 매번 묻지 않게 하려면 tui.resume_cwd를 "current" 또는 "session"으로 설정합니다. 명시적인 --cd가 이 설정보다 우선합니다. developer-commands

7.4설정을 명령줄에서 덮기

공식한 번만 다르게 돌리고 싶을 때는 설정 파일을 고치지 않고 -c로 덮습니다. 값은 TOML로 해석되므로 JSON 문법을 쓰면 안 됩니다. developer-commands

한 번만 네트워크를 열고 정책을 걸어 실행

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

공식같은 조합을 반복해 쓰게 되면 프로파일 파일로 저장하고 --profile로 부릅니다. 프로파일은 $CODEX_HOME/<이름>.config.toml에 둡니다. agent-approvals-security

~/.codex/readonly_quiet.config.toml

approval_policy = "never"
sandbox_mode    = "read-only"

codex --profile readonly_quiet

7.5전체 표는 어디에

공식플래그와 서브커맨드 전량, 그리고 각각의 성숙도 라벨은 공식 명령 레퍼런스가 정본입니다. 이 가이드는 그 표를 복사하지 않습니다. 사본은 반드시 낡고, 낡은 표가 실제 목록보다 먼저 읽히면 없는 옵션을 쓰게 됩니다. developer-commands

지금 내 버전이 실제로 아는 것 확인하기

codex --help
codex exec --help
codex doctor

8.1코드 탐색 시키기

공식큰 저장소에서 가장 큰 개선은 그 작업에 맞는 맥락과 무엇을 하라는 명확한 구조를 주는 것입니다. 관련 파일·폴더·문서·예제·에러를 지정하고, 필요하면 @로 파일을 붙입니다. best-practices

관행탐색 지시는 "이 코드를 설명해 줘"보다 답이 무엇에 쓰일지를 붙일 때 쓸모가 커집니다. 예를 들어 "이 모듈을 고쳐야 하는데, 바꾸면 깨질 수 있는 호출부를 먼저 찾아 줘"는 탐색과 다음 작업이 이어집니다.

8.2편집과 diff 검토

공식변경은 승인하기 전에 봅니다. CLI에서는 /diff가 추적되지 않는 파일까지 포함한 git diff를 보여 줍니다. 데스크톱 앱과 IDE 확장에는 리뷰 패널이 있습니다. developer-commands code-review

공식데스크톱 앱의 리뷰 패널은 코덱스가 만든 변경만이 아니라 저장소의 상태 전체를 비춥니다. 기본은 Unstaged이고, Staged·Commit·Branch·Last turn으로 범위를 바꿉니다. 이 패널은 프로젝트가 git 저장소 안에 있어야 동작합니다. code-review

공식특정 줄에 인라인 코멘트를 달 수 있고, 이것이 코덱스를 정확한 수정으로 이끄는 가장 빠른 방법인 경우가 많습니다. 코멘트를 남긴 뒤 의도를 분명히 하는 메시지를 한 번 보냅니다. code-review

8.3명령 실행 위임

공식기본값에서 코덱스는 네트워크 접근이 꺼진 상태로 돕니다. 로컬에서는 OS가 강제하는 샌드박스가 닿을 수 있는 범위를 제한하고(보통 현재 작업 공간), 승인 정책이 언제 멈춰 물을지를 정합니다. agent-approvals-security

공식실행 시점에 코덱스는 폴더가 버전 관리 중인지 보고 기본값을 권합니다. 버전 관리되는 폴더면 Auto(작업 공간 쓰기 + 요청 시 승인), 아니면 read-only입니다. 작업 공간에는 현재 디렉터리와 /tmp 같은 임시 디렉터리가 포함되고, 지금 무엇이 포함되는지는 /status로 봅니다. agent-approvals-security

이 표는 공식 문서의 조합표를 옮긴 것입니다. agent-approvals-security

공식workspace-write에서도 쓰기 허용 경로 안의 일부는 보호됩니다. .git, .agents, .codex가 읽기 전용으로 남고 보호는 재귀적입니다. .git이 포인터 파일이면 그것이 가리키는 실제 git 디렉터리도 보호됩니다. agent-approvals-security

8.4큰 저장소에서 범위 좁히기

공식코덱스가 맞는 파일을 찾긴 하는데 너무 많은 문서를 읽는다면, 그것이 AGENTS.md에 라우팅 지침을 넣을 신호입니다. 어느 디렉터리·파일을 우선할지 적습니다. customization/overview

공식지침 파일은 여러 위치에 둘 수 있고 작업 디렉터리에 가까운 파일이 우선합니다. 저장소 전체 규칙은 루트에, 서비스별 규칙은 그 서비스 디렉터리에 둡니다. 그래야 관계없는 변경이 서비스별 맥락을 짊어지지 않습니다. third-party/github agent-configuration/agents-md

공식지침 파일 크기 자체가 사용량에 영향을 줍니다. 공식 요금 문서는 한도를 오래 쓰는 방법 중 하나로 "AGENTS.md를 저장소 안에 중첩해 주입되는 맥락 양을 줄이라"를 듭니다. pricing

지침 파일 설계 전체는 L2 13장에서 다룹니다.

8.5프로젝트와 채팅 정리

공식관련된 채팅·파일·소스를 묶는 단위가 프로젝트입니다. 데스크톱 앱의 로컬 프로젝트는 여러 폴더를 담을 수 있고, 각 폴더가 다른 git 저장소일 수 있습니다. 그 경우 리뷰 패널의 저장소 선택기로 저장소를 오가며 볼 수 있습니다. projects code-review

관행프로젝트를 나누는 기준은 저장소가 아니라 같은 맥락을 공유하는가입니다. 프론트와 백엔드가 한 기능을 위해 함께 움직인다면 한 프로젝트에 두 폴더를 넣는 편이, 저장소마다 프로젝트를 만드는 것보다 오가는 비용이 적습니다.

9.1코드 리뷰 받기

공식/review는 전용 리뷰어를 띄웁니다. 선택한 diff를 읽고 우선순위가 매겨진 실행 가능한 지적을 내놓으며, 작업 트리를 바꾸지 않습니다. code-review

공식리뷰를 다른 모델로 돌리고 싶으면 config.toml의 review_model을 설정합니다. 리뷰를 현재 채팅이 아니라 별도 채팅에서 열려면 데스크톱 앱은 Settings > General > Code review에서 Detached를, IDE 확장은 chatgpt.reviewDelivery를 detached로 둡니다. code-review

공식비대화로 돌리려면 codex review를 씁니다. 대상은 정확히 하나만 고르고, --uncommitted·--base·--commit과 커스텀 프롬프트는 서로 충돌합니다. --title은 --commit과만 함께 씁니다. developer-commands

9.2리뷰 규칙 쓰기

공식코덱스는 저장소에서 AGENTS.md를 찾아 해당하는 코드 리뷰 규칙을 따릅니다. 규칙이 다루는 코드에 가장 가까운 파일에 ## Code Review Rules 섹션을 둡니다. third-party/github

AGENTS.md

## Code Review Rules

### Experiment cohorts
- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

공식좋은 규칙의 조건이 넷으로 정리돼 있습니다. 저장소 고유의 결과에 집중할 것(무엇을 왜 잡아야 하는지), 안전한 경로나 예외를 함께 적을 것(진짜 문제와 정상 동작을 구분하게), 범위를 좁히고 오래 갈 것(바뀌기 쉬운 함수 이름보다 결과 기준으로), 기계적 검사는 CI에 남길 것(포맷·린트는 리뷰 규칙이 아닙니다). 두세 개로 시작해 실제 지적을 보고 다듬습니다. third-party/github

9.3GitHub PR 리뷰

공식PR 코멘트에 @codex review를 남기면 코덱스가 반응하고 표준 GitHub 코드 리뷰를 남깁니다. GitHub에서는 P0·P1 문제만 표시해 코멘트가 고위험 항목에 머무르게 합니다. third-party/github

공식모든 PR을 자동으로 리뷰하게 하려면 코덱스 설정에서 Automatic reviews를 켭니다. 그러면 새 PR이 리뷰에 올라올 때마다 @codex review 없이 리뷰가 붙습니다. 선행 조건은 그 저장소에 대한 클라우드 설정과 GitHub push 또는 admin 권한입니다. third-party/github

한 번만 초점을 좁혀 요청하기

@codex review for issues in the database migration

9.4보안 리뷰 맛보기

공식일반 코드 리뷰와 별개로, GitHub PR을 대상으로 하는 심층 보안 리뷰가 있습니다(연구 프리뷰). 이것은 코덱스 시큐리티라는 별도 제품군의 일부이고, 스캔 엔진·발견 항목·커버리지 같은 개념이 따로 붙습니다. security/security-review security

이 편에서는 존재와 경계만 짚습니다. 설치·스캔·CI 배선·SDK를 포함한 전체는 L5 35장에 있습니다. 일상 운전에서 알아 둘 것은 하나입니다. 보안 리뷰가 필요한 변경을 일반 리뷰로 덮었다고 착각하지 않는 것입니다.

9.5테스트·디버깅 루프

공식변경을 요청하는 데서 멈추지 않습니다. 필요하면 테스트를 만들게 하고, 관련 검사를 돌리게 하고, 결과를 확인하게 하고, 받아들이기 전에 리뷰하게 합니다. 코덱스가 이 루프를 대신 돌 수 있지만 무엇이 "잘된 것"인지 알아야 가능하고, 그 기준은 프롬프트나 AGENTS.md에서 옵니다. best-practices

관행버그 수정에서 가장 확실한 순서는 재현 먼저입니다. 실패하는 테스트를 먼저 만들게 하고, 그 테스트가 실패하는 것을 눈으로 본 뒤, 고치게 합니다. 이 순서를 지키면 "고쳤다"는 주장이 검증 가능해집니다. 같은 형태가 두 곳에서 요구됩니다. 코덱스 시큐리티 문서는 수정마다 "고치기 전에 실패하고 고친 뒤에 통과하는" 좁은 회귀 테스트를 붙이라고 하고, 쿡북의 실행 계획 규격은 수용 기준을 "새 테스트가 변경 전에 실패하고 후에 통과한다"로 쓰라고 명시합니다. security/plugin/fix-findings cookbook codex_exec_plans

10.1채팅과 스레드

공식CLI 세션은 저장되고 이름을 붙일 수 있습니다. 세션 선택기를 정리하고 싶지만 전사는 남기고 싶으면 codex archive, 전사까지 지우려면 codex delete입니다. 세션 ID가 세션 이름보다 우선합니다. developer-commands

공식codex delete --force는 세션 UUID에만 씁니다. 이름으로 지정한 세션은 확인을 거칩니다. 같은 이름이 여러 개이거나 모호할 때 실수로 지우지 않게 하기 위해서입니다. developer-commands

10.2이어가기와 검색

공식같은 저장소의 최근 채팅을 다시 열거나, 오래된 작업으로 돌아가야 할 때 로컬 채팅을 가로질러 검색할 수 있습니다. CLI에서는 codex resume, 세션 안에서는 /resume입니다. codex/cli

관행재개할지 새로 열지는 맥락이 자산인지 부담인지로 정합니다. 같은 문제를 계속 파고 있으면 재개가 이득이고, 앞선 시도가 틀린 방향이었다면 그 전사를 끌고 가는 것이 오히려 방해가 됩니다. 후자면 새 채팅에서 결론만 요약해 넘깁니다.

10.3표면 사이 이동

공식로컬에서 시작한 작업을 클라우드로 넘기고 결과만 회수할 수 있습니다. CLI에서는 codex cloud로 활성·완료 채팅을 훑고 작업을 제출하고 결과를 로컬 저장소에 적용합니다. IDE 확장에서도 긴 작업을 클라우드에 위임하고 돌아와 결과를 검토합니다. codex/cli codex/ide

공식클라우드 채팅의 최신 diff를 로컬에 붙이는 전용 명령도 있습니다. codex apply는 패치된 파일을 출력하고, git apply가 실패하면(예: 충돌) 0이 아닌 코드로 끝납니다. developer-commands

공식CLI 세션을 데스크톱 앱에서 이어받으려면 /app을 씁니다(macOS·Windows). developer-commands

10.4알림 설계

공식데스크톱 앱 설정에서 턴 완료 알림을 끄기 / 배경일 때만 / 항상 중에 고르고, 권한 요청과 질문 알림은 별도 스위치로 켭니다. 사이드바의 벨(Activity)에서 읽지 않음·실행 중·응답 대기 채팅을 모아 볼 수 있습니다. notifications

관행"항상"으로 두면 알림이 배경 소음이 되고, "끄기"로 두면 승인 대기에서 몇십 분씩 멈춰 있게 됩니다. 실용적인 기본값은 배경일 때만 + 권한 요청 알림 켜기입니다. 사람이 꼭 필요한 순간에만 부릅니다.

10.5폰에서 이어받기

공식Remote는 연결된 컴퓨터에서 도는 코덱스 작업을 폰에서 시작·안내·승인·검토하게 합니다. remote

설정과 SSH 원격 연결까지 포함한 전체는 L4 29장에 있습니다. 일상 운전에서는 "승인 대기 때문에 자리에 묶이지 않아도 된다"는 것만 알아 두면 됩니다.

11.1모델 계열

공식권장 모델은 GPT-5.6 계열 셋입니다. Sol은 복잡하고 열린 작업, Terra는 일상의 실용적 기본값, Luna는 추출·분류·변환처럼 결과가 명확하고 양이 많은 작업입니다. models

공식로컬 기본 모델은 config.toml의 model 항목으로 정합니다. 지정하지 않으면 권장 모델이 쓰입니다. 클라우드 채팅의 기본 모델은 현재 바꿀 수 없습니다. models

config.toml

model = "gpt-5.6"

11.2추론 강도와 속도

공식원칙은 하나입니다. 필요한 결과를 내는 가장 낮은 추론 강도를 씁니다. 계획·분석·검증이 더 필요한 작업에서만 올립니다. GPT-5.5의 추론 강도가 GPT-5.6에 그대로 대응되지는 않으므로, 익숙한 작업을 낮은 값으로 한 번 돌려 보고 조정하라고 문서가 안내합니다. models

근거는 모델 문서와 속도 문서입니다. models agent-configuration/speed

CLI에서 Fast 모드

/fast on
/fast off
/fast status

config.toml 로 고정

service_tier = "fast"

[features]
fast_mode = true

11.3무엇이 한도를 쓰는가

공식ChatGPT Work와 코덱스는 사용량을 공유합니다. 같은 요금·크레딧·한도를 씁니다. agent-configuration/speed

공식턴이 도는 중에 한도에 닿아도 진행 중인 그 턴은 계속할 수 있습니다(공정 사용 한도 범위 안에서). Plus·Pro는 추가 크레딧을 구매할 수 있고, 유연 요금제를 쓰는 Business·Edu·Enterprise는 워크스페이스 크레딧을 추가할 수 있습니다. 모든 사용자는 API 키로 추가 로컬 채팅을 돌릴 수 있고 그때는 표준 API 요금이 붙습니다. pricing

지금 내 사용량 보기

/usage

11.4절약 실전 수칙

공식공식 문서가 제시하는 한도 절약 방법은 여섯 가지입니다. 프롬프트 크기 통제, 소스 자료 제한, 출력을 필요에 맞추기, AGENTS.md 크기 줄이기(저장소 안에 중첩), MCP 서버 수 제한(서버마다 맥락이 늘어납니다), 일상 작업은 작은 모델로. pricing

관행이 중 효과가 가장 큰 것은 대개 MCP 서버 정리와 지침 파일 다이어트입니다. 둘 다 모든 턴에 붙는 고정 비용이라, 프롬프트를 아무리 짧게 써도 사라지지 않기 때문입니다. 쓰지 않는 MCP 서버는 꺼 두고, 지침 파일은 "지금 이 작업에 필요한가"로 걸러 냅니다.

관행반대로 효과가 작은데 자주 시도되는 것은 모델을 무조건 낮추기입니다. 낮은 모델이 두 번 실패하고 세 번째에 성공하면 총 소모는 더 큽니다. 결과가 명확한 반복 작업에서만 내리고, 모호한 작업에서는 오히려 올리는 편이 쌉니다.