ChatGPT Chat·Work·Codex 선택 가이드: 모델과 effort를 업무에 맞추는 법
ChatGPT에서 무엇을 쓸지 고민할 때는 원하는 결과부터 정하는 편이 좋습니다. 대화로 생각을 정리할지, 검토할 파일을 만들지, 저장소를 수정할지에 따라 Chat·Work·Codex를 고르고, 작업의 복잡도와 검증 방법에 맞춰 모델과 effort를 조절하는 실용적인 기준을 살펴봅니다.
이 글은 2026-10-23에 확인한 공식 문서를 기준으로 합니다. 메뉴와 지원 모델은 요금제, 앱 버전, 워크스페이스 설정 및 배포 단계에 따라 다릅니다. 아래 추천 조합은 비교 실험을 시작하기 위한 제안이며, 측정된 성능 순위나 모든 계정의 기본값을 뜻하지 않습니다.
1. Chat·Work·Codex는 원하는 결과와 검토 화면으로 고른다
ChatGPT 공식 서비스에서 Chat은 질문과 대화를 이어 가는 데, Work는 여러 단계를 거쳐 검토할 결과를 만드는 데 적합합니다. Codex 공식 시작 안내는 코드 변경과 개발 도구를 중심으로 살펴볼 수 있습니다. 여기서 Work는 작업 방식의 이름이며 회사용 구독 상품 이름과 구분해야 합니다.
| 시작할 곳 | 잘 맞는 요청 | 완료 여부를 판단할 대상 |
|---|---|---|
| Chat | 개념 설명, 짧은 문장 수정, 아이디어 비교, 요구사항 질문 | 이해가 되었는가, 다음 결정을 내릴 수 있는가 |
| Work | 여러 자료를 조사해 보고서·발표자료·스프레드시트 만들기 | 원본과 대조할 수 있는 파일, 출처, 누락 항목 |
| Codex | 저장소 탐색, 버그 수정, 기능 구현, 테스트와 PR 검토 | diff, 실행 결과, 테스트, 변경의 영향 |
Work와 Codex의 핵심 기능은 상당 부분 겹칩니다. Work도 프로젝트를 만들 수 있고 Codex도 자료 조사와 문서 작업을 할 수 있습니다. 개발자는 구현과 문서를 같은 Codex 작업에서 끝내는 편이 편할 수 있고, 기획자는 파일 미리보기를 중심으로 Work를 쓰는 편이 편할 수 있습니다. 업무마다 세 모드를 모두 거칠 필요는 없습니다. (공식 사용 가이드)
OpenAI 공개 문서의 모드 비교표. 실제 계정의 설정 화면이 아닌 공식 설명 페이지다. (출처: Use ChatGPT, 2026-10-23 캡처) 이미지 크게 보기.
2. 모델은 업무 유형에, effort는 해결해야 할 추론에 맞춘다
Work·Codex에서 GPT-6.1 Sol은 복잡한 작업의 실용적인 출발점, GPT-6 Luna는 범위가 명확한 반복 작업, GPT-6 Astra는 판단이 까다로운 작업의 후보로 삼을 수 있습니다. 공식 안내는 Sol의 경우 클라이언트 기본 effort, Luna는 High, Astra는 Light에서 시작하도록 설명합니다. GPT-6.1 Sol·GPT-6 Sol·GPT-6 Luna는 일반 Chat에서 제공되는 모델이 아닙니다. (지원 모델과 시작 설정)
따라서 Chat에 “Sol Medium을 고르라”는 안내를 그대로 적용하지 마세요. Chat은 현재 계정에 표시되는 기본 모델로 시작하고, 해당 화면에서 제공하는 추론 옵션이 있을 때 비교하는 편이 좋습니다. 확인한 공식 문서는 Chat 전체 계정에 공통인 세부 모델·effort 목록을 확정하지 않으므로, 이 글도 Chat에 Work의 설정 이름을 강제로 대응시키지 않습니다. 깊은 조사와 파일 완성이 필요해지면 Work의 선택지를 검토하세요.
아래는 공식 모델 선택 가이드를 실제 업무에 적용한 권장 시작 조합입니다. Sol Medium이 보이지 않으면 제공되는 기본값을 사용합니다.
| 업무 상황 | 시작할 곳과 모델·effort | 결과가 부족할 때 바꿀 것 |
|---|---|---|
| 짧은 질문, 글의 방향 잡기 | Chat의 기본 모델·기본 추론 설정 | 질문 범위와 독자, 원하는 길이를 먼저 명확히 한다 |
| 정해진 양식으로 회의 메모 정리 | Work · Luna High | 빠진 항목의 예시와 필수 필드를 준다 |
| 자료 여러 개로 수정 가능한 보고서 만들기 | Work · Sol Medium | 근거의 충돌을 해결해야 하면 Extra High를 비교한다 |
| 중요한 글의 뉘앙스·최종 구성 다듬기 | Work · Astra Light, 필요하면 Medium | 독자·평가 기준·좋은 예시를 더한다 |
| 재현 절차가 있는 일반 버그 수정 | Codex · Sol Medium | 여러 모듈의 원인을 추적해야 하면 High 또는 Extra High |
| 설계 대안과 상충하는 요구사항 평가 | Work 또는 Codex · Astra Medium | 해결되지 않는 핵심 쟁점에 Extra High 또는 Max를 한정한다 |
“Luna High보다 Astra Light가 항상 약하다”처럼 모델 사이에서 effort 이름만 비교하지는 마세요. 모델을 바꾸는 것과 같은 모델에 더 많은 추론 시간을 주는 것은 별개의 선택입니다. 동일한 입력으로 결과의 오류, 수정 횟수, 대기 시간과 사용량을 비교해야 자신에게 맞는 조합을 찾을 수 있습니다.
3. Light부터 Ultra까지: 언제 올려야 하는가
아래 예시는 업무 분해를 위한 제안입니다. 모든 모델이 모든 단계를 지원하는 것은 아닙니다. 데스크톱·웹·IDE의 Light는 CLI에서 Low로 표시되며, 모델 세대가 달라지면 같은 명칭의 효과도 동일하다고 볼 수 없습니다. (effort 공식 안내)
| effort | 적용하기 좋은 상황 | 요청에 함께 적을 내용 |
|---|---|---|
| Light / Low | 문구 교체, 단순 추출처럼 정답 조건이 좁은 작업 | 수정 범위와 유지할 요소 |
| Medium | 몇 단계의 구현·분석·문서 작성 | 목표, 입력 자료, 완료 조건 |
| High | 의존 관계나 예외 상황을 더 살펴야 하는 작업 | 관련 모듈, 재현 절차, 경계 조건 |
| Extra High | 여러 근거·설계 선택 사이의 충돌을 풀어야 하는 작업 | 비교 기준과 채택·기각 이유 |
| Max | 분리하기 어려운 핵심 문제 하나에 깊은 검토가 필요한 경우 | 풀어야 할 쟁점 하나와 반례 검증 |
| Ultra | 독립적으로 조사·검토할 수 있는 큰 작업 | 역할별 범위, 공통 산출물 형식, 통합 기준 |
Max는 한 작업에 더 많은 추론 시간을 주고, Ultra는 최대 추론과 하위 에이전트의 병렬 작업을 활용합니다. Luna는 Max까지 지원하며 Ultra는 지원하지 않습니다. 지원 모델과 계정에서도 Ultra가 모든 요청에 필요한 것은 아닙니다. (Max·Ultra 지원, 하위 에이전트 동작)
예를 들어 상태 동기화 버그의 모순을 좁히는 일은 Max를 비교할 후보입니다. 큰 변경을 접근성·회귀 위험·문서 일관성으로 나누어 검토하는 일은 Ultra를 시험할 후보입니다. Ultra 요청에서는 각 검토자의 역할과 최종 통합 책임을 지정하세요. 세 작업이 같은 파일을 동시에 수정해야 한다면 조사와 수정 단계를 분리하는 편이 결과를 검토하기 쉽습니다.
4. 실제 설정에서는 Power·Effort·Speed를 구분한다
데스크톱 Work·Codex 또는 지원되는 웹 Work에서 입력창 아래 모델 컨트롤을 엽니다. Power는 미리 구성된 조합을 고르는 UI이며, 같은 모델의 effort만 바꾸는 눈금으로 생각하면 헷갈립니다. 세부 선택이 필요하면 Advanced에서 Model, Effort, Speed를 확인합니다. 공식 미리보기의 모델 이름과 단계 수는 예시이므로 자신의 계정 화면을 기준으로 선택하세요. (모델 선택 UI)
OpenAI 공개 문서의 상호작용 예시. 그림의 6 Sol은 예시 선택이며 현재 권장 모델 목록 전체를 뜻하지 않는다. (출처: Models, 2026-10-23 캡처) 이미지 크게 보기.
CLI 사용자는 /model에서 모델과 effort를 고르고, 지원되는 Max·Ultra는 More reasoning…에서 확인할 수 있습니다. 데스크톱에서 지원되는 Ultra가 슬라이더에 안 보이면 Settings → Configuration → Ultra in model picker slider 설정을 확인합니다. 이 설정을 켜도 계정에 없는 모델 접근권이 생기지는 않습니다. (공식 설정 절차)
Ultra와 Ultrafast는 서로 다른 설정입니다. Fast·Ultrafast는 응답 속도와 사용량에 관한 선택입니다. 추론 깊이를 조절하는 Extra High·Max·Ultra와 구분해야 합니다. 우선 Standard 속도로 품질 기준을 맞추고, 실제로 기다리는 시간이 병목일 때 사용량 증가를 감수할지 판단하는 편이 좋습니다. (속도와 사용량)
5. 실전 예시: 온보딩 개선을 대화에서 구현까지 연결하기
다음은 직접 응용할 수 있도록 구성한 예시이며, 특정 회사에서 측정한 도입 사례는 아닙니다. 준비물은 사용자 피드백, 현재 화면, 프로젝트의 실행·검증 방법입니다. 모델을 올리기 전에 이 입력을 갖추세요.
Chat: 먼저 풀어야 할 문제를 좁힌다
Chat 기본 설정으로 피드백과 화면을 제공하고, 문제 정의를 대화로 다듬습니다.
첨부한 온보딩 피드백에서 관찰된 문제와 추측을 구분해 주세요. 첫 방문자의 가입 완료를 방해하는 가설 세 개를 비교하고, 지금 결정할 수 없는 항목은 질문으로 남겨 주세요. 아직 구현안은 만들지 말고 문제 정의와 성공 기준부터 정리해 주세요.
결과에서 사용자가 실제로 말한 내용과 모델의 추론을 구분했는지 확인합니다. “전환율을 높인다”보다 “오류 뒤에 복구 방법이 보인다”처럼 확인 가능한 조건을 남겨야 다음 단계가 쉬워집니다.
Work: 승인할 수 있는 실행 문서를 만든다
정리한 문제 정의를 파일로 저장하거나 새 작업에 첨부합니다. Work에서 Sol Medium을 출발점으로 다음처럼 요청할 수 있습니다.
첨부한 문제 정의와 화면을 바탕으로 개선 제안 문서를 만들어 주세요. 근거, 변경할 화면, 유지할 동작, 접근성 확인 항목, 완료 조건을 포함하세요. 각 제안에 피드백 출처를 연결하고 확인되지 않은 수치는 넣지 마세요. 최종 파일과 미결정 사항 목록을 함께 보여 주세요.
Work에는 결과의 형식과 확인 기준을 함께 주는 것이 효과적입니다. 자료 수집만 요청하면 구현에 필요한 결정이 빠질 수 있습니다. 문서의 제안과 원본 피드백을 대조한 뒤, 채택한 내용만 남긴 승인본을 준비합니다. (Work 시작 가이드)
Codex: 승인본을 구현하고 검증한다
실제 저장소를 선택하고 승인본을 명시적으로 연결합니다. 작은 변경은 Sol Medium으로 시작합니다.
승인된 onboarding-brief.md에 따라 가입 오류 복구 UI를 구현해 주세요. 먼저 관련 코드와 프로젝트 지침을 읽고 변경 범위를 정하세요. 기존 동작을 유지하면서 필요한 검증을 실행하고 모바일·데스크톱 화면을 확인하세요. 완료 후 변경 파일, 검증 결과, 남은 문제를 보고하고 PR 초안을 준비해 주세요.
이 예시는 저장소에 해당 파일을 준비했다는 가정입니다. 새 작업이 이전 대화를 전부 알고 있다고 기대하지 말고, 승인 문서·관련 파일·수정하지 않을 범위·검증 명령을 다시 연결하세요. 코드가 생성되었다는 사실과 동작이 확인되었다는 사실도 구분합니다. 테스트를 실행하지 못했다면 원인과 미검증 범위를 결과에 남깁니다.
6. 실행 위치와 권한은 모델 설정과 따로 정한다
내 컴퓨터의 파일·실행 중인 서버·로그인된 앱이 필요하면 로컬 작업을 검토합니다. Codex의 Local은 현재 프로젝트 폴더에서, Worktree는 분리된 Git 작업 폴더에서 실행되며 둘 다 내 컴퓨터를 사용합니다. Cloud는 준비된 원격 환경에서 실행됩니다. 클라우드로 바꾼다고 로컬 파일, 브라우저 로그인, VPN 연결이 자동으로 복사되지는 않습니다. (Codex 실행 환경)
예를 들어 지금 띄운 개발 서버의 화면을 고치는 일은 로컬이 편합니다. 다른 작업과 파일 변경을 분리해야 하면 Worktree를 고려합니다. 원격에서 재현 가능한 저장소 작업은 의존성과 검증 명령을 갖춘 Cloud 환경을 준비할 수 있습니다. 웹과 모바일에서도 지원되는 클라우드 작업을 시작하거나 이어 갈 수 있으므로 Codex를 데스크톱 전용으로 이해하지 마세요. (시작 방법과 지원 화면)
도구 접근과 외부 변경 권한도 별개입니다. 보고서가 필요하다면 “파일을 만들어 보여 달라”, 발송까지 필요하다면 대상과 내용을 구체적으로 요청하세요. effort를 높여도 없는 자료나 권한이 생기지는 않습니다. 필요한 연결과 권한은 권한 안내에서 따로 확인합니다.
7. 설정을 올리기 전에 실패 원인을 확인한다
결과가 부족하면 다음 순서로 점검해 보세요.
- 자료가 없었는가? 최신 파일과 원본 출처를 연결합니다. 파일을 못 읽은 상태에서 Max로 바꿔도 근거는 늘지 않습니다.
- 완료 조건이 모호했는가? 필요한 결과의 형식, 범위, 허용할 변경을 구체화합니다.
- 추론이 빠졌는가? 근거는 충분하지만 예외나 관계를 놓쳤다면 같은 모델에서 effort를 한 단계 높여 비교합니다.
- 판단의 질이 부족했는가? 문장 뉘앙스, 설계 통합, 충돌하는 요구사항이 계속 문제라면 더 강한 모델을 같은 입력으로 시험합니다.
- 도구 실행이 실패했는가? 설치, 권한, 네트워크, 검증 환경을 고칩니다. 실행 실패를 사고력 부족으로 취급하지 않습니다.
반복 업무는 대표 입력 세 개 정도로 작은 비교 기록을 남기는 편이 좋습니다. 예를 들어 “빠진 요구사항 수 / 검토 후 수정 횟수 / 완료까지 시간 / 사용량”을 기록합니다. 가장 높은 설정을 고정하기보다, 요구 수준을 충족한 가장 가벼운 조합을 기본으로 삼습니다.
Work와 Codex는 사용량·크레딧 한도를 공유합니다. 더 긴 작업과 많은 도구 호출, 속도 옵션에 따라 소비도 달라지므로 메시지 개수만으로 비용을 예상하지 마세요. ChatGPT 구독으로 쓰는 한도와 API 키로 쓰는 토큰 과금 역시 구분해야 합니다. 정확한 계정별 조건은 가격·사용량 문서를 확인하세요.
8. 오늘 시작할 때 적용할 기준
짧은 질문과 문제 정의는 Chat 기본 설정으로, 파일을 완성하는 업무는 Work에서 Sol 기본값 또는 Medium으로, 저장소 변경은 Codex에서 Sol 기본값 또는 Medium으로 시작해 보세요. 범위가 일정한 반복 작업은 Luna High, 세밀한 판단이 중요한 결과물은 Astra Light·Medium을 비교할 만합니다.
그다음 결과를 보고 effort를 조절합니다. Max를 선택할 때는 깊게 풀어야 할 문제 하나를, Ultra를 선택할 때는 독립적으로 나눌 작업과 통합 기준을 설명하세요. 어떤 설정이든 마지막에는 원본과 결과를 대조하고, 실제 파일이나 실행 화면에서 완료 조건을 확인하는 습관이 필요합니다.
When choosing how to use ChatGPT, start with the result you want. Use Chat, Work, or Codex according to whether you need to develop an idea through conversation, produce a file you can review, or change a repository. Then adjust the model and reasoning effort to the complexity of the task and how you will verify it.
This guide follows official documentation checked on 2026-10-23. Menus and available models vary by plan, app version, workspace settings, and rollout. The combinations below are starting points for comparison, not measured rankings or universal account defaults.
1. Choose Chat, Work, or Codex around the result and review interface
In ChatGPT, Chat suits questions and conversation, while Work suits taking a task through several steps to a reviewable result. The official Codex guide introduces development workflows and tools. Work here names a way of working; distinguish it from the name of a business subscription.
| Start here | Suitable requests | What to check for completion |
|---|---|---|
| Chat | Explain a concept, revise a sentence, compare ideas, clarify requirements | Can you understand the issue and make the next decision? |
| Work | Research several sources and produce a report, presentation, or spreadsheet | Files that can be checked against originals, sources, and gaps |
| Codex | Explore a repository, fix a bug, implement a feature, test, or review a PR | Diffs, execution results, tests, and impact of the change |
Work and Codex overlap substantially in their core capabilities. Work can build projects, and Codex can research and write documents. Developers may find it convenient to finish implementation and documentation in one Codex task; planners may prefer Work's focus on file previews. Every task does not need to pass through all three modes. (Official usage guide)
Mode comparison on OpenAI's public documentation page, rather than an account's settings screen. (Source: Use ChatGPT, captured 2026-10-23) View full-size image.
2. Match the model to the work and effort to the reasoning required
In Work and Codex, GPT-6.1 Sol is a practical starting point for complex work, GPT-6 Luna is a candidate for clearly scoped recurring tasks, and GPT-6 Astra suits demanding judgment. Official guidance suggests starting with the client's default effort for Sol, High for Luna, and Light for Astra. GPT-6.1 Sol, GPT-6 Sol, and GPT-6 Luna are not available in ordinary Chat. (Supported models and starting settings)
Do not apply “select Sol Medium” directly to Chat. Start with the default model shown in your Chat account, and compare reasoning options when that interface offers them. The official documentation checked here does not establish one detailed model-and-effort list common to every Chat account, so this guide does not force Work's setting names onto Chat. Consider Work's options when deeper research and completed files become the goal.
The following suggested starting combinations apply the official model selection guide to practical work. If Sol Medium is unavailable, use the offered default.
| Situation | Surface, model, and effort to try | What to change if the result falls short |
|---|---|---|
| Quick questions or shaping an article | Chat's default model and reasoning setting | Clarify the scope, audience, and desired length first |
| Organizing meeting notes into a fixed template | Work · Luna High | Provide examples of omissions and required fields |
| A revisable report from several sources | Work · Sol Medium | Compare Extra High when conflicting evidence needs resolution |
| Refining nuance and final structure in important writing | Work · Astra Light, then Medium if needed | Add the audience, evaluation criteria, and good examples |
| An ordinary bug with reproduction steps | Codex · Sol Medium | Try High or Extra High when tracing causes across modules |
| Evaluating designs and competing requirements | Work or Codex · Astra Medium | Reserve Extra High or Max for unresolved central questions |
Do not compare effort names across models as though “Astra Light must be weaker than Luna High.” Changing models and giving one model more reasoning time are different decisions. Compare errors, revision count, waiting time, and usage on identical inputs to find a useful combination.
3. From Light to Ultra: when to increase effort
These examples suggest how to structure work. Not every model supports every level. Light in desktop, web, and IDE interfaces appears as Low in the CLI, and the same label does not imply the same effect across model generations. (Official effort guidance)
| Effort | A suitable situation | Include in your request |
|---|---|---|
| Light / Low | Narrow tasks such as replacing copy or extracting simple data | Scope of the edit and what must remain intact |
| Medium | Implementation, analysis, or writing with a few steps | Goal, inputs, and completion criteria |
| High | Work needing closer attention to dependencies or exceptions | Relevant modules, reproduction steps, and edge cases |
| Extra High | Resolving conflicts between evidence or design choices | Comparison criteria and reasons to accept or reject options |
| Max | Deep examination of one central problem that is hard to divide | One question to resolve and checks for counterexamples |
| Ultra | A large task with independently researchable or reviewable parts | Role boundaries, a shared output format, and integration criteria |
Max gives one task more reasoning time; Ultra combines maximum reasoning with parallel subagent work. Luna supports Max but not Ultra. Even with a supported model and account, Ultra is unnecessary for many requests. (Max and Ultra support, subagent behavior)
Narrowing a contradiction in a state synchronization bug is a candidate for comparing Max. Reviewing a large change separately for accessibility, regression risk, and documentation consistency is a candidate for Ultra. Define each reviewer's role and who integrates the findings. If three tasks must edit the same file, separating investigation from editing makes the result easier to review.
4. Distinguish Power, Effort, and Speed in the controls
Open the model control beneath the composer in desktop Work or Codex, or supported web Work. Power selects preset combinations; treating it as a dial that changes only one model's effort causes confusion. Open Advanced to inspect Model, Effort, and Speed separately. The official preview's names and number of steps are illustrative, so use the options shown in your account. (Model selection interface)
An interactive example in OpenAI's public documentation. The pictured 6 Sol selection does not represent the complete current recommended model list. (Source: Models, captured 2026-10-23) View full-size image.
In the CLI, select a model and effort with /model; supported Max and Ultra options appear under More reasoning…. If a supported Ultra option is missing from the desktop slider, check Settings → Configuration → Ultra in model picker slider. Enabling that display does not grant access to a model your account lacks. (Official configuration steps)
Ultra and Ultrafast are different settings. Fast and Ultrafast concern speed and usage. Distinguish them from Extra High, Max, and Ultra, which concern reasoning. First meet your quality bar at Standard speed; then decide whether waiting time justifies the additional usage. (Speed and usage)
5. Practical example: take an onboarding improvement from conversation to code
This is an adaptable example, not a measured company deployment. Prepare user feedback, current screens, and the project's run and verification instructions. Assemble those inputs before increasing the model setting.
Chat: narrow the problem first
Provide feedback and screens using Chat's default settings, then refine the problem through conversation.
Separate observed problems from assumptions in the attached onboarding feedback. Compare three hypotheses about what prevents new visitors from completing signup, and leave questions for issues we cannot decide yet. Define the problem and success criteria before proposing an implementation.
Check whether the result distinguishes what users actually said from the model's inferences. A verifiable condition such as “a recovery action is visible after an error” gives the next stage more direction than “increase conversion.”
Work: create an execution document you can approve
Save the agreed problem definition or attach it to a new task. Start Work with Sol Medium and try a request like this.
Create an improvement proposal from the attached problem definition and screens. Include evidence, affected screens, behavior to preserve, accessibility checks, and completion criteria. Link each proposal to its feedback source and omit unverified numbers. Show the final file together with a list of unresolved decisions.
Give Work both the output format and evaluation criteria. A research-only request may omit decisions needed for implementation. Compare the proposals with the original feedback, then prepare an approved version containing the choices you accepted. (Getting started with Work)
Codex: implement and verify the approved brief
Select the actual repository and explicitly attach the approved brief. Begin a small change with Sol Medium.
Implement the signup error recovery UI according to the approved onboarding-brief.md. Read the relevant code and project instructions first, then define the change's scope. Preserve existing behavior, run appropriate checks, and inspect mobile and desktop screens. Report changed files, verification results, and remaining issues, and prepare a draft PR.
This example assumes you have placed that file in the repository. Do not assume a new task knows every previous conversation: connect the approved document, relevant files, excluded scope, and verification commands again. Distinguish generating code from verifying its behavior. If tests cannot run, record the reason and what remains unverified.
6. Choose execution location and permissions separately
Consider local work when you need files, running servers, or signed-in apps on your computer. Codex Local works in the current project folder; Worktree uses a separate Git working directory. Both run on your computer. Cloud uses a prepared remote environment. Moving to Cloud does not automatically copy local files, browser sign-ins, or VPN access. (Codex environments)
Local work is convenient for fixing a screen on an already running development server. Consider Worktree when changes need isolation from another task. For reproducible remote repository work, prepare a Cloud environment with dependencies and verification commands. Supported cloud tasks can also start or continue on web and mobile, so Codex should not be understood as desktop-only. (Getting started and available surfaces)
Tool access and permission for external changes are separate, too. If you need a report, ask for a file to review; if you also need it sent, specify the content and recipient. Increasing effort does not supply missing sources or permissions. Check necessary connections and access in the permissions guide.
7. Diagnose the failure before increasing settings
When a result falls short, check in this order.
- Were sources missing? Connect current files and original sources. Max cannot add evidence from a file the agent could not read.
- Was completion ambiguous? Specify the result's format, scope, and permitted changes.
- Was reasoning incomplete? If evidence was sufficient but relationships or exceptions were missed, compare one higher effort level on the same model.
- Was judgment inadequate? If nuance, design integration, or competing requirements remain problematic, test a stronger model with the same inputs.
- Did a tool fail? Fix installation, access, network, or verification conditions. Do not treat execution failures as reasoning failures.
For recurring work, keep a small comparison record with roughly three representative inputs. Track missing requirements, revision count after review, completion time, and usage. Make the lightest combination that meets your standard the default instead of fixing every task at the highest setting.
Work and Codex share usage and credit limits. Longer tasks, additional tool calls, and speed options affect consumption, so message count alone is a poor cost estimate. Also distinguish ChatGPT subscription allowances from API-key token billing. Check the pricing and usage documentation for account-specific conditions.
8. A starting routine for today
Try Chat's defaults for quick questions and problem definition, Work with Sol's default or Medium for completed files, and Codex with Sol's default or Medium for repository changes. Compare Luna High for predictable recurring work and Astra Light or Medium when careful judgment matters.
Adjust effort after inspecting the result. With Max, state the one problem needing deep examination. With Ultra, define independent work and integration criteria. Whatever the setting, compare results with their sources and verify completion in the actual file or running interface.
选择如何使用 ChatGPT 时，最好先明确需要的结果。想通过对话梳理思路、制作可审阅的文件，还是修改代码仓库？据此选择 Chat、Work 或 Codex，再按照任务复杂度和验证方式调整模型与推理强度。
本文依据 2026-10-23 核实的官方文档。菜单与可用模型会随套餐、应用版本、工作区设置及推出进度而变化。下文的组合是比较实验的起点，并非实测排名，也不代表所有账户的默认值。
1. 根据结果和审阅界面选择 Chat、Work 或 Codex
在 ChatGPT 官方服务中，Chat 适合提问与持续对话，Work 适合通过多个步骤完成可审阅的成果。Codex 官方入门指南则介绍围绕代码修改和开发工具的工作方式。这里的 Work 是工作方式的名称，应与企业订阅产品的名称区分。
| 从哪里开始 | 适合的请求 | 判断是否完成的依据 |
|---|---|---|
| Chat | 解释概念、修改短句、比较思路、澄清需求 | 是否理解了问题，能否做出下一步决定 |
| Work | 调研多份材料，制作报告、演示文稿或电子表格 | 可与原始资料对照的文件、来源和遗漏项 |
| Codex | 探索仓库、修复错误、实现功能、运行测试及审阅 PR | diff、执行结果、测试和修改影响 |
Work 与 Codex 的核心能力有很大重叠。 Work 也可以构建项目，Codex 也能调研和编写文档。开发者可能更适合在一个 Codex 任务里完成实现与文档；策划人员可能更喜欢以文件预览为中心的 Work。不必让每项工作都经过三种模式。(官方使用指南)
OpenAI 公开文档中的模式比较表，并非某个账户的设置界面。(来源：Use ChatGPT，截于 2026-10-23) 查看大图.
2. 模型匹配工作类型，effort 匹配推理需求
在 Work 和 Codex 中，GPT-6.1 Sol 是复杂任务的实用起点，GPT-6 Luna 适合范围明确的重复任务，GPT-6 Astra 可用于判断难度较高的工作。官方建议 Sol 从客户端默认 effort 开始，Luna 从 High 开始，Astra 从 Light 开始。GPT-6.1 Sol、GPT-6 Sol 和 GPT-6 Luna 不在普通 Chat 中提供。(支持的模型与起始设置)
因此，不要把“选择 Sol Medium”直接套用到 Chat。Chat 可以先使用当前账户显示的默认模型，若界面提供推理选项，再进行比较。此次核实的官方文档并未确定适用于所有 Chat 账户的详细模型与 effort 清单，所以本文也不会强行把 Work 的设置名称映射到 Chat。需要深入调研并完成文件时，再考虑 Work 的选项。
下表将官方模型选择指南应用到实际工作，给出建议起始组合。若没有 Sol Medium，使用界面提供的默认值。
| 工作情境 | 建议的界面、模型与 effort | 结果不理想时调整什么 |
|---|---|---|
| 简短提问、确定文章方向 | Chat 默认模型与默认推理设置 | 先明确问题范围、读者和所需长度 |
| 按固定模板整理会议笔记 | Work · Luna High | 提供遗漏示例与必填字段 |
| 用多份资料制作可修改的报告 | Work · Sol Medium | 需要解决证据冲突时比较 Extra High |
| 调整重要文章的语气与最终结构 | Work · Astra Light，必要时 Medium | 补充读者、评价标准与优秀示例 |
| 有复现步骤的一般错误修复 | Codex · Sol Medium | 跨模块追踪原因时尝试 High 或 Extra High |
| 评估设计方案与相互冲突的需求 | Work 或 Codex · Astra Medium | 将 Extra High 或 Max 留给尚未解决的核心问题 |
不要仅凭 effort 名称跨模型比较，例如认为“Astra Light 一定弱于 Luna High”。切换模型与让同一模型投入更多推理时间是两种不同选择。应使用相同输入，比较错误、修改次数、等待时间和用量，找到适合自己的组合。
3. 从 Light 到 Ultra：什么时候需要提高强度
以下例子用于帮助拆分工作，并非所有模型都支持全部等级。桌面、网页和 IDE 界面的 Light 在 CLI 中显示为 Low；不同代模型的同名等级也不一定具有相同效果。(effort 官方说明)
| effort | 适用情况 | 请求中应提供的内容 |
|---|---|---|
| Light / Low | 替换文案、简单提取等答案范围很窄的工作 | 修改范围与必须保留的内容 |
| Medium | 包含若干步骤的实现、分析或写作 | 目标、输入资料与完成条件 |
| High | 需要进一步检查依赖关系或异常情况 | 相关模块、复现步骤与边界条件 |
| Extra High | 解决多份证据或设计选择之间的冲突 | 比较标准及接受、拒绝方案的理由 |
| Max | 深入审查一个难以拆分的核心问题 | 一个待解决的问题与反例验证 |
| Ultra | 可以独立调研或审阅的大型任务 | 各角色的范围、统一输出格式与整合标准 |
Max 为单个任务提供更多推理时间，Ultra 则结合最高推理强度与子智能体并行工作。 Luna 支持到 Max，不支持 Ultra。即使账户和模型支持 Ultra，也并非每个请求都需要使用。(Max 与 Ultra 支持情况、子智能体的工作方式)
例如，定位状态同步错误中的矛盾，可以比较 Max 的效果。将大型变更分别从无障碍、回归风险和文档一致性角度审阅，则适合尝试 Ultra。应明确每位审阅者的职责以及谁负责整合结果。如果三个任务必须修改同一文件，将调查与修改分阶段进行，会更容易审阅成果。
4. 在设置中区分 Power、Effort 与 Speed
在桌面 Work、Codex 或受支持的网页 Work 中，打开输入框下方的模型控件。Power 选择的是预设组合，不能简单理解为只改变同一个模型 effort 的刻度。需要精确选择时，在 Advanced 中分别查看 Model、Effort 与 Speed。官方预览里的模型名称和档位数量只是示例，请以自己账户的界面为准。(模型选择界面)
OpenAI 公开文档中的交互示例。图中的 6 Sol 只是示例选项，不代表当前推荐模型的完整清单。(来源：Models，截于 2026-10-23) 查看大图.
CLI 用户可以通过 /model 选择模型与 effort，在 More reasoning… 中查看支持的 Max、Ultra。桌面滑块未显示受支持的 Ultra 时，可检查 Settings → Configuration → Ultra in model picker slider。打开该显示选项不会获得账户原本没有的模型访问权。(官方设置步骤)
Ultra 与 Ultrafast 是不同设置。 Fast、Ultrafast 关注响应速度与用量，应与控制推理的 Extra High、Max、Ultra 区分。建议先用 Standard 速度达到质量要求，再判断等待时间是否值得额外用量。(速度与用量)
5. 实践示例：将新用户引导优化从对话推进到实现
下面是可自行改用的示例，并非某家公司的实测应用案例。先准备用户反馈、当前页面以及项目的运行和验证方法，再考虑提高模型设置。
Chat：先缩小问题范围
使用 Chat 默认设置提供反馈与页面，通过对话完善问题定义。
请区分附件中的新用户引导反馈里已观察到的问题与推测。比较三个阻碍首次访问者完成注册的假设，对尚无法决定的内容提出问题。暂时不要给出实现方案，先整理问题定义与成功标准。
检查结果是否区分了用户实际表达的内容与模型推断。相比“提高转化率”，“出错后可以看到恢复操作”这样的可验证条件，更有利于推进下一步。
Work：制作可批准的执行文档
将确定的问题定义保存成文件，或附加到新任务。可以从 Work 的 Sol Medium 开始提出如下请求。
根据附件中的问题定义与页面，制作改进提案文档。包含依据、需要修改的页面、保留的行为、无障碍检查项与完成条件。为每条提案关联反馈来源，不要加入未经核实的数字。展示最终文件和未决事项清单。
向 Work 同时提供结果格式和评价标准。只要求收集资料，可能遗漏实现所需的决定。将提案与原始反馈对照，再准备仅保留已采纳内容的批准版本。(Work 入门指南)
Codex：实现并验证批准版本
选择实际仓库，并明确附上批准的文档。小范围修改可从 Sol Medium 开始。
按照已批准的 onboarding-brief.md 实现注册错误恢复 UI。先阅读相关代码与项目规范，再确定修改范围。保持原有行为，执行必要检查，并查看移动端和桌面端页面。完成后报告修改文件、验证结果和遗留问题，并准备 PR 草稿。
此例假设仓库中已准备好该文件。不要期待新任务知道全部历史对话，应重新关联批准文档、相关文件、排除的修改范围和验证命令。也应区分“代码已生成”与“行为已验证”。若无法运行测试，应在结果中记录原因及未验证范围。
6. 运行位置和权限应单独决定
需要本机文件、运行中的服务器或已登录应用时，可以考虑本地任务。Codex Local 在当前项目目录运行，Worktree 在独立的 Git 工作目录运行，两者都使用你的电脑。Cloud 使用准备好的远程环境。切换到云端并不会自动复制本地文件、浏览器登录状态或 VPN 访问。(Codex 运行环境)
修改当前开发服务器上的页面时，本地工作较方便。需要与其他任务的文件修改隔离时，可考虑 Worktree。可在远程复现的仓库任务，可以准备包含依赖与验证命令的 Cloud 环境。受支持的云端任务也能在网页和移动端开始或继续，因此不应把 Codex 理解为桌面专用工具。(入门方法与使用界面)
工具访问权与对外修改权限也要单独考虑。需要报告时，请要求“生成文件供审阅”；还需要发送时，应明确内容和接收者。提高 effort 不会凭空补充资料或权限。所需连接与访问权限可另查权限指南。
7. 提高设置之前，先诊断失败原因
结果不够好时，可以按以下顺序检查。
- 缺少资料吗？ 连接最新文件和原始来源。无法读取文件时，切到 Max 也不会增加证据。
- 完成条件模糊吗？ 明确成果格式、范围和允许修改的内容。
- 推理遗漏了吗？ 证据充分但漏掉例外或关联时，在同一模型上提高一级 effort 进行比较。
- 判断质量不足吗？ 如果语气、设计整合或冲突需求仍有问题，用相同输入测试更强模型。
- 工具执行失败了吗？ 修复安装、权限、网络或验证环境，不要把执行失败当成推理不足。
对于重复工作，可以用约三个代表性输入建立简短比较记录，例如“遗漏需求数／审阅后修改次数／完成时间／用量”。不要固定使用最高设置，而应把达到要求的最轻量组合设为默认。
Work 与 Codex 共享用量和积分限额。任务长度、工具调用次数与速度选项都会影响消耗，因此不能仅凭消息数量估算成本。ChatGPT 订阅额度与 API 密钥的 token 计费也应区分。账户的具体条件请查看价格与用量文档。
8. 今天就能采用的起始方式
简短提问和问题定义先用 Chat 默认设置；完成文件的工作从 Work 的 Sol 默认值或 Medium 开始；仓库修改从 Codex 的 Sol 默认值或 Medium 开始。范围稳定的重复任务可以比较 Luna High，重视细致判断的成果可以比较 Astra Light 或 Medium。
随后根据结果调整 effort。选择 Max 时，说明一个需要深入解决的问题；选择 Ultra 时，明确可独立拆分的工作与整合标准。不论采用哪种设置，都应将原始资料与结果对照，并在实际文件或运行界面中核实完成条件。
ChatGPTで何を使うか迷ったら、まず必要な成果を決めると選びやすくなります。対話で考えを整理するのか、確認できるファイルを作るのか、リポジトリを変更するのか。目的からChat・Work・Codexを選び、作業の複雑さと検証方法に合わせてモデルとeffortを調整する実践的な基準を紹介します。
この記事は2026-10-23に確認した公式ドキュメントに基づきます。メニューと利用可能なモデルは、プラン、アプリのバージョン、ワークスペース設定、提供段階によって異なります。以下の組み合わせは比較を始めるための提案であり、実測ランキングや全アカウント共通の初期値ではありません。
1. Chat・Work・Codexは成果と確認画面から選ぶ
ChatGPT公式サービスでは、Chatは質問と対話、Workは複数の手順を通じて確認可能な成果を完成させる用途に向いています。Codex公式入門ガイドでは、コード変更と開発ツールを中心とした使い方を確認できます。ここでのWorkは作業方式の名前であり、企業向け契約の名称とは区別してください。
| 始める場所 | 向いている依頼 | 完了を判断する対象 |
|---|---|---|
| Chat | 概念の説明、短文の修正、アイデア比較、要件の確認 | 理解できたか、次の判断ができるか |
| Work | 複数資料を調査して報告書・スライド・表計算ファイルを作る | 原資料と照合できるファイル、出典、抜け漏れ |
| Codex | リポジトリ調査、バグ修正、機能実装、テスト、PRレビュー | diff、実行結果、テスト、変更の影響 |
WorkとCodexの中核機能は大きく重なっています。 Workもプロジェクトを作れますし、Codexも調査や文書作成ができます。開発者なら実装と文書を一つのCodexタスクで仕上げる方が便利な場合があります。企画担当者なら、ファイルのプレビューを中心に扱うWorkが使いやすいでしょう。毎回三つのモードをすべて経由する必要はありません。(公式利用ガイド)
OpenAI公開ドキュメントのモード比較表。個人アカウントの設定画面ではなく、公式の説明ページ。(出典：Use ChatGPT、2026-10-23撮影) 画像を拡大表示.
2. モデルは仕事の種類に、effortは必要な推論に合わせる
Work・Codexでは、GPT-6.1 Solを複雑な仕事の実用的な出発点、GPT-6 Lunaを範囲が明確な反復作業、GPT-6 Astraを難しい判断が必要な仕事の候補と考えられます。公式案内では、Solはクライアントの標準effort、LunaはHigh、AstraはLightから始めるよう説明されています。GPT-6.1 Sol・GPT-6 Sol・GPT-6 Lunaは通常のChatでは提供されません。(対応モデルと開始設定)
したがって「Sol Mediumを選ぶ」という案内をそのままChatに適用しないでください。Chatは現在のアカウントに表示される標準モデルから始め、その画面に推論の選択肢がある場合に比較するのがよいでしょう。今回確認した公式文書は、全Chatアカウントに共通する詳細なモデル・effort一覧を確定していないため、この記事でもWorkの設定名をChatに無理に対応させません。深い調査やファイルの完成が必要になったらWorkの選択肢を検討します。
以下は公式のモデル選択ガイドを実務に当てはめた開始時の推奨組み合わせです。Sol Mediumがなければ、提供されている標準値を使います。
| 作業の状況 | 始める場所・モデル・effort | 成果が足りない場合の調整 |
|---|---|---|
| 短い質問、記事の方向性を決める | Chatの標準モデル・標準推論設定 | 質問の範囲、読者、長さを先に明確にする |
| 決まった形式で会議メモを整理する | Work · Luna High | 抜けた項目の例と必須欄を渡す |
| 複数資料から修正可能な報告書を作る | Work · Sol Medium | 根拠の矛盾を解く必要があればExtra Highと比較する |
| 重要な文章のニュアンスや最終構成を整える | Work · Astra Light、必要ならMedium | 読者、評価基準、良い例を追加する |
| 再現手順のある一般的なバグ修正 | Codex · Sol Medium | 複数モジュールの原因追跡ならHighやExtra High |
| 設計案と競合する要件の評価 | WorkまたはCodex · Astra Medium | 未解決の中心課題にExtra HighやMaxを絞って使う |
「Astra LightはLuna Highより必ず弱い」のように、モデルをまたいでeffort名だけを比較しないでください。モデルを変えることと、同じモデルに推論時間を多く与えることは別の選択です。同じ入力で誤り、修正回数、待ち時間、使用量を比べると、自分に合う組み合わせが見えてきます。
3. LightからUltraまで：いつ上げるか
次の例は仕事の分解を考えるための提案です。すべてのモデルが全段階に対応するわけではありません。デスクトップ・Web・IDEのLightはCLIではLowと表示され、モデル世代が変われば同じ名称の効果も同じとは限りません。(effortの公式案内)
| effort | 向いている状況 | 依頼に含める内容 |
|---|---|---|
| Light / Low | 文言置換や単純抽出など、正解条件が狭い作業 | 修正範囲と残す要素 |
| Medium | 数段階の実装・分析・文書作成 | 目的、入力資料、完了条件 |
| High | 依存関係や例外を詳しく見る作業 | 関連モジュール、再現手順、境界条件 |
| Extra High | 複数の根拠や設計案の矛盾を解く作業 | 比較基準と採用・不採用の理由 |
| Max | 分割しにくい一つの中心課題を深く検討する場合 | 解くべき論点一つと反例の検証 |
| Ultra | 独立して調査・レビューできる大きな仕事 | 役割ごとの範囲、共通の出力形式、統合基準 |
Maxは一つのタスクに推論時間を多く与え、Ultraは最大限の推論とサブエージェントによる並列作業を活用します。 LunaはMaxまで対応し、Ultraには対応しません。対応モデルとアカウントでも、すべての依頼にUltraが必要なわけではありません。(Max・Ultraの対応、サブエージェントの動作)
たとえば状態同期バグの矛盾を絞る仕事は、Maxを比較する候補です。大きな変更をアクセシビリティ、回帰リスク、文書の整合性に分けてレビューする仕事は、Ultraを試す候補です。Ultraでは各担当の役割と最終統合の責任を指定します。三つの作業が同じファイルを変更するなら、調査と編集を分けた方が成果を確認しやすくなります。
4. 設定画面ではPower・Effort・Speedを区別する
デスクトップのWork・Codex、または対応するWeb Workで、入力欄の下にあるモデル設定を開きます。Powerは事前に構成された組み合わせを選ぶUIです。同じモデルのeffortだけを動かす目盛りだと考えると混乱します。細かく選びたいときはAdvancedでModel、Effort、Speedを個別に確認します。公式プレビューの名称と段階数は例なので、自分のアカウント画面を基準に選びましょう。(モデル選択UI)
OpenAI公開文書の操作例。図の6 Solは例としての選択であり、現在の推奨モデル一覧全体を示すものではない。(出典：Models、2026-10-23撮影) 画像を拡大表示.
CLIでは/modelでモデルとeffortを選び、対応するMax・UltraはMore reasoning…で確認できます。デスクトップのスライダーに対応するUltraが表示されなければ、Settings → Configuration → Ultra in model picker sliderを確認します。この表示設定を有効にしても、契約にないモデルのアクセス権は得られません。(公式設定手順)
UltraとUltrafastは別の設定です。 Fast・Ultrafastは応答速度と使用量の選択であり、推論を調整するExtra High・Max・Ultraとは区別します。まずStandardの速度で品質基準を満たし、待ち時間が実際のボトルネックになったときに使用量の増加を受け入れるか判断するとよいでしょう。(速度と使用量)
5. 実践例：オンボーディング改善を対話から実装につなげる
以下は応用できるように構成した例で、特定企業で効果を測った導入事例ではありません。ユーザーフィードバック、現在の画面、プロジェクトの実行・検証方法を用意します。モデル設定を上げる前に、この入力を揃えましょう。
Chat：まず解く問題を絞る
Chatの標準設定でフィードバックと画面を渡し、対話で問題定義を整理します。
添付したオンボーディングのフィードバックから、観察された問題と推測を分けてください。初回訪問者の登録完了を妨げる仮説を三つ比較し、まだ判断できない事項は質問として残してください。実装案はまだ作らず、問題定義と成功基準を先に整理してください。
ユーザーが実際に述べたこととモデルの推論が分かれているか確認します。「コンバージョンを高める」よりも「エラー後に復旧方法が見える」のような確認可能な条件を残すと、次に進みやすくなります。
Work：承認できる実行文書を作る
合意した問題定義をファイルに保存するか、新しいタスクに添付します。WorkでSol Mediumを出発点に、次のように依頼できます。
添付した問題定義と画面から改善提案書を作ってください。根拠、変更する画面、維持する動作、アクセシビリティ確認項目、完了条件を含めてください。各提案をフィードバックの出典に結び付け、未確認の数値は入れないでください。最終ファイルと未決事項の一覧を見せてください。
Workには成果の形式と確認基準を一緒に渡すと効果的です。資料収集だけを頼むと、実装に必要な決定が抜ける場合があります。提案と原資料を照合し、採用した内容だけを残した承認版を用意します。(Work入門ガイド)
Codex：承認版を実装して検証する
実際のリポジトリを選び、承認版を明示的に渡します。小さな変更はSol Mediumから始めます。
承認済みのonboarding-brief.mdに従って登録エラーの復旧UIを実装してください。まず関連コードとプロジェクト指針を読み、変更範囲を決めてください。既存の動作を維持し、必要な検証を実行してモバイルとデスクトップの画面を確認してください。完了後に変更ファイル、検証結果、残る問題を報告し、PRの下書きを準備してください。
この例は、該当ファイルをリポジトリに用意した前提です。新しいタスクが過去の会話をすべて知っていると期待せず、承認文書、関連ファイル、変更しない範囲、検証コマンドを再度渡します。コードの生成と動作確認も区別してください。テストできなければ、理由と未検証範囲を結果に残します。
6. 実行場所と権限はモデル設定とは別に決める
自分のコンピューターのファイル、起動中のサーバー、ログイン済みアプリが必要ならローカル作業を検討します。CodexのLocalは現在のプロジェクトフォルダー、Worktreeは分離されたGit作業フォルダーを使い、どちらも自分のコンピューターで動きます。Cloudは準備されたリモート環境で実行します。Cloudに切り替えても、ローカルファイル、ブラウザーのログイン、VPN接続が自動でコピーされるわけではありません。(Codexの実行環境)
起動済みの開発サーバーの画面を修正するならローカルが便利です。別の作業から変更を分離したいときはWorktreeを検討します。リモートで再現できるリポジトリ作業なら、依存関係と検証コマンドを備えたCloud環境を用意できます。対応するクラウド作業はWebやモバイルでも開始・継続できるため、Codexをデスクトップ専用と理解しないでください。(始め方と利用画面)
ツールへのアクセスと外部変更の権限も別です。報告書が必要なら「ファイルを作って見せてほしい」、送信も必要なら対象と内容を具体的に指定します。effortを上げても不足する資料や権限は得られません。接続とアクセスは権限ガイドで別途確認します。
7. 設定を上げる前に失敗の原因を確認する
成果が不十分なら、次の順に確認してみてください。
- 資料が不足していたか。 最新ファイルと原資料を渡します。読めなかったファイルの根拠は、Maxに変えても増えません。
- 完了条件が曖昧だったか。 成果の形式、範囲、許可する変更を明確にします。
- 推論が抜けていたか。 根拠は十分なのに例外や関連を見落としたなら、同じモデルでeffortを一段上げて比較します。
- 判断の質が足りなかったか。 ニュアンス、設計の統合、競合要件が問題なら、同じ入力でより強いモデルを試します。
- ツールが失敗したか。 インストール、権限、ネットワーク、検証環境を直します。実行失敗を推論不足と扱わないようにします。
反復業務では、代表的な入力を三つほど使って小さな比較記録を残すと役立ちます。たとえば「欠けた要件数／レビュー後の修正回数／完了時間／使用量」を記録します。常に最高設定に固定するのではなく、必要水準を満たした最も軽い組み合わせを標準にします。
WorkとCodexは使用量とクレジットの上限を共有します。長い作業、ツール呼び出しの増加、速度設定でも消費が変わるので、メッセージ数だけで費用を見積もらないでください。ChatGPT契約の利用枠と、APIキーによるトークン課金も区別します。アカウントごとの条件は料金・使用量の文書で確認してください。
8. 今日から始める基準
短い質問と問題定義はChatの標準設定、ファイルを完成させる仕事はWorkでSolの標準値またはMedium、リポジトリ変更はCodexでSolの標準値またはMediumから試してみてください。範囲が安定した反復作業にはLuna High、細かな判断が重要な成果にはAstra Light・Mediumを比較できます。
その後、結果を見てeffortを調整します。Maxなら深く解くべき問題を一つ、Ultraなら独立した作業と統合基準を説明します。どの設定でも原資料と成果を照合し、実際のファイルや動作画面で完了条件を確認する習慣が必要です。
Para elegir cómo usar ChatGPT, empieza por el resultado que necesitas. Escoge Chat, Work o Codex según quieras desarrollar una idea conversando, producir un archivo revisable o modificar un repositorio. Después ajusta el modelo y el esfuerzo de razonamiento a la complejidad de la tarea y a su método de verificación.
Esta guía se basa en documentación oficial consultada el 2026-10-23. Los menús y modelos disponibles varían según el plan, la versión de la aplicación, la configuración del espacio de trabajo y el despliegue. Las combinaciones propuestas son puntos de partida para comparar, no clasificaciones medidas ni valores predeterminados universales.
1. Elige Chat, Work o Codex según el resultado y la interfaz de revisión
En ChatGPT, Chat encaja con preguntas y conversaciones, mientras que Work permite avanzar por varios pasos hasta obtener un resultado revisable. La guía oficial de inicio de Codex presenta los flujos de desarrollo y sus herramientas. Aquí Work nombra una forma de trabajar; conviene distinguirla del nombre de una suscripción empresarial.
| Dónde empezar | Peticiones adecuadas | Qué comprobar para dar la tarea por terminada |
|---|---|---|
| Chat | Explicar conceptos, revisar frases, comparar ideas, aclarar requisitos | Si entiendes el problema y puedes tomar la siguiente decisión |
| Work | Investigar varias fuentes y crear informes, presentaciones u hojas de cálculo | Archivos contrastables con los originales, fuentes y omisiones |
| Codex | Explorar repositorios, corregir errores, implementar funciones, probar y revisar PR | Diffs, resultados de ejecución, pruebas e impacto del cambio |
Work y Codex comparten gran parte de sus capacidades principales. Work puede construir proyectos, y Codex puede investigar y redactar documentos. A un desarrollador puede convenirle terminar implementación y documentación en una tarea de Codex; alguien dedicado a planificación puede preferir Work y sus vistas previas de archivos. No todas las tareas necesitan pasar por los tres modos. (Guía oficial de uso)
Comparación de modos en la documentación pública de OpenAI; no es la configuración de una cuenta particular. (Fuente: Use ChatGPT, captura del 2026-10-23) Ver imagen a tamaño completo.
2. Adapta el modelo al trabajo y el esfuerzo al razonamiento necesario
En Work y Codex, GPT-6.1 Sol es un punto de partida práctico para trabajos complejos, GPT-6 Luna encaja con tareas repetibles y bien delimitadas, y GPT-6 Astra es una opción cuando hace falta un juicio exigente. La guía oficial propone empezar con el esfuerzo predeterminado del cliente para Sol, High para Luna y Light para Astra. GPT-6.1 Sol, GPT-6 Sol y GPT-6 Luna no están disponibles en el Chat convencional. (Modelos compatibles y ajustes iniciales)
Por tanto, no apliques directamente «selecciona Sol Medium» a Chat. Empieza con el modelo predeterminado que aparezca en tu cuenta y compara opciones de razonamiento si esa interfaz las ofrece. La documentación consultada no establece una lista detallada de modelos y esfuerzos común a todas las cuentas de Chat, por lo que esta guía tampoco impone los nombres de Work a Chat. Considera las opciones de Work cuando necesites investigación profunda y archivos terminados.
Estas combinaciones iniciales recomendadas aplican la guía oficial de selección de modelos a situaciones prácticas. Si Sol Medium no está disponible, utiliza el valor predeterminado ofrecido.
| Situación | Interfaz, modelo y esfuerzo iniciales | Qué cambiar si el resultado no basta |
|---|---|---|
| Preguntas breves o definir el enfoque de un artículo | Modelo y razonamiento predeterminados de Chat | Aclarar primero alcance, público y extensión |
| Organizar notas de reuniones en una plantilla fija | Work · Luna High | Proporcionar ejemplos de omisiones y campos obligatorios |
| Crear un informe revisable a partir de varias fuentes | Work · Sol Medium | Comparar Extra High si hay que resolver pruebas contradictorias |
| Afinar matices y estructura final de un texto importante | Work · Astra Light; Medium si hace falta | Añadir público, criterios de evaluación y buenos ejemplos |
| Corregir un error común con pasos de reproducción | Codex · Sol Medium | Probar High o Extra High al rastrear causas entre módulos |
| Evaluar diseños y requisitos en conflicto | Work o Codex · Astra Medium | Reservar Extra High o Max para cuestiones centrales sin resolver |
No compares nombres de esfuerzo entre modelos suponiendo que «Astra Light siempre es inferior a Luna High». Cambiar de modelo y darle más tiempo de razonamiento al mismo modelo son decisiones distintas. Compara errores, número de revisiones, espera y consumo con entradas idénticas para encontrar una combinación adecuada.
3. De Light a Ultra: cuándo aumentar el esfuerzo
Estos ejemplos ayudan a estructurar el trabajo. No todos los modelos admiten todos los niveles. Light en escritorio, web e IDE aparece como Low en la CLI, y el mismo nombre no implica el mismo efecto entre generaciones de modelos. (Orientación oficial sobre esfuerzo)
| Esfuerzo | Situación adecuada | Qué incluir en la petición |
|---|---|---|
| Light / Low | Tareas acotadas como sustituir texto o extraer datos sencillos | Alcance del cambio y elementos que deben conservarse |
| Medium | Implementación, análisis o redacción con varios pasos | Objetivo, materiales y criterios de finalización |
| High | Trabajo que requiere examinar dependencias o excepciones | Módulos pertinentes, reproducción y casos límite |
| Extra High | Resolver conflictos entre evidencias o alternativas de diseño | Criterios de comparación y motivos para aceptar o descartar |
| Max | Examinar a fondo un problema central difícil de dividir | Una cuestión concreta y comprobación de contraejemplos |
| Ultra | Trabajo grande con partes investigables o revisables por separado | Alcance de cada rol, formato común y criterios de integración |
Max da más tiempo de razonamiento a una tarea; Ultra combina razonamiento máximo con trabajo paralelo de subagentes. Luna admite Max, pero no Ultra. Incluso con una cuenta y un modelo compatibles, muchas peticiones no necesitan Ultra. (Compatibilidad de Max y Ultra, funcionamiento de los subagentes)
Acotar una contradicción en un error de sincronización de estado es un candidato para comparar Max. Dividir la revisión de un cambio grande entre accesibilidad, riesgo de regresión y coherencia documental es un candidato para Ultra. Define el papel de cada revisor y quién integra los resultados. Si tres tareas deben editar el mismo archivo, separar investigación y edición facilita la revisión.
4. Distingue Power, Effort y Speed en los controles
Abre el control de modelo bajo el cuadro de entrada en Work o Codex de escritorio, o en Work web cuando esté disponible. Power selecciona combinaciones predefinidas: interpretarlo como un control que solo modifica el esfuerzo del mismo modelo resulta confuso. Abre Advanced para comprobar Model, Effort y Speed por separado. Los nombres y el número de posiciones de la vista previa oficial son ilustrativos; guíate por tu propia cuenta. (Interfaz de selección de modelos)
Ejemplo interactivo de la documentación pública de OpenAI. La selección 6 Sol de la imagen no representa la lista completa de modelos recomendados actualmente. (Fuente: Models, captura del 2026-10-23) Ver imagen a tamaño completo.
En la CLI, selecciona modelo y esfuerzo con /model; las opciones compatibles de Max y Ultra aparecen en More reasoning…. Si Ultra es compatible pero no aparece en el control de escritorio, revisa Settings → Configuration → Ultra in model picker slider. Activar su visualización no concede acceso a modelos que tu cuenta no tenga. (Pasos oficiales de configuración)
Ultra y Ultrafast son ajustes distintos. Fast y Ultrafast afectan a velocidad y consumo. Distínguelos de Extra High, Max y Ultra, que se refieren al razonamiento. Primero alcanza tu nivel de calidad con velocidad Standard; después decide si la espera justifica el consumo adicional. (Velocidad y consumo)
5. Ejemplo práctico: mejorar la incorporación de usuarios desde la conversación hasta el código
Este ejemplo está pensado para adaptarlo, no es un despliegue empresarial con resultados medidos. Prepara comentarios de usuarios, pantallas actuales e instrucciones de ejecución y verificación del proyecto antes de aumentar los ajustes del modelo.
Chat: delimita primero el problema
Con la configuración predeterminada de Chat, aporta comentarios y pantallas, y concreta el problema conversando.
Separa los problemas observados de las suposiciones en los comentarios adjuntos sobre la incorporación de usuarios. Compara tres hipótesis sobre qué impide completar el registro a quienes visitan por primera vez y formula preguntas para las cuestiones aún sin resolver. Define primero el problema y los criterios de éxito, sin proponer todavía una implementación.
Comprueba que el resultado distinga lo que realmente dijeron los usuarios de las inferencias del modelo. Una condición verificable como «hay una acción de recuperación visible después de un error» orienta mejor el siguiente paso que «aumentar la conversión».
Work: crea un documento de ejecución que puedas aprobar
Guarda la definición acordada del problema o adjúntala a una tarea nueva. Empieza con Sol Medium en Work y prueba una petición como esta.
Crea una propuesta de mejora a partir de la definición del problema y las pantallas adjuntas. Incluye evidencias, pantallas afectadas, comportamiento que conservar, comprobaciones de accesibilidad y criterios de finalización. Vincula cada propuesta a su comentario de origen y omite cifras sin verificar. Muestra el archivo final y una lista de decisiones pendientes.
Indica a Work tanto el formato como los criterios de revisión. Pedir solo recopilación de materiales puede dejar fuera decisiones necesarias para implementar. Contrasta las propuestas con los comentarios originales y prepara una versión aprobada que contenga las opciones aceptadas. (Primeros pasos con Work)
Codex: implementa y verifica el documento aprobado
Selecciona el repositorio real y conecta explícitamente el documento aprobado. Para un cambio pequeño, empieza con Sol Medium.
Implementa la interfaz de recuperación de errores del registro según onboarding-brief.md, ya aprobado. Lee primero el código pertinente y las instrucciones del proyecto, y delimita el cambio. Conserva el comportamiento existente, ejecuta las comprobaciones necesarias e inspecciona las pantallas en móvil y escritorio. Informa de archivos modificados, resultados de verificación y problemas pendientes, y prepara un borrador de PR.
El ejemplo supone que ese archivo ya está en el repositorio. No des por hecho que una tarea nueva conoce todas las conversaciones anteriores: vuelve a conectar el documento aprobado, los archivos relevantes, lo que no debe cambiar y los comandos de verificación. Distingue también entre generar código y verificar su comportamiento. Si no pueden ejecutarse las pruebas, registra el motivo y lo que queda sin comprobar.
6. Decide la ubicación de ejecución y los permisos por separado
Considera trabajo local si necesitas archivos, servidores activos o aplicaciones con sesión iniciada en tu ordenador. Local de Codex trabaja en la carpeta actual; Worktree utiliza un directorio de trabajo Git separado. Ambos se ejecutan en tu equipo. Cloud usa un entorno remoto preparado. Cambiar a Cloud no copia automáticamente archivos locales, sesiones del navegador ni acceso VPN. (Entornos de Codex)
Trabajar localmente resulta cómodo para corregir una pantalla de un servidor de desarrollo ya activo. Considera Worktree cuando debas aislar los cambios de otra tarea. Para trabajo reproducible en un repositorio remoto, prepara un entorno Cloud con dependencias y comandos de verificación. Las tareas de nube compatibles también pueden iniciarse o continuarse desde web y móvil; Codex no debe entenderse como una herramienta exclusiva de escritorio. (Inicio y superficies disponibles)
El acceso a herramientas y los permisos para cambios externos también son decisiones independientes. Si necesitas un informe, pide un archivo para revisar; si además quieres enviarlo, especifica destinatario y contenido. Aumentar el esfuerzo no proporciona fuentes ni permisos ausentes. Consulta las conexiones y accesos necesarios en la guía de permisos.
7. Diagnostica el fallo antes de aumentar los ajustes
Si el resultado es insuficiente, revisa lo siguiente en este orden.
- ¿Faltaban fuentes? Conecta archivos actuales y fuentes originales. Max no añade evidencias de un archivo que no pudo leerse.
- ¿Era ambiguo el criterio de finalización? Concreta formato, alcance y cambios permitidos.
- ¿Faltó razonamiento? Si había evidencias suficientes pero se omitieron relaciones o excepciones, compara un nivel superior en el mismo modelo.
- ¿Faltó calidad de juicio? Si persisten problemas de matiz, integración de diseño o requisitos enfrentados, prueba un modelo más capaz con las mismas entradas.
- ¿Falló una herramienta? Corrige instalación, acceso, red o entorno de verificación. No trates un fallo de ejecución como falta de razonamiento.
Para trabajos recurrentes, conserva una comparación breve con unas tres entradas representativas. Registra, por ejemplo, requisitos omitidos, revisiones posteriores, tiempo total y consumo. Usa por defecto la combinación más ligera que cumpla tus criterios, en lugar de fijar siempre el nivel máximo.
Work y Codex comparten límites de uso y créditos. Las tareas largas, más llamadas a herramientas y las opciones de velocidad afectan al consumo, por lo que contar mensajes no basta para estimar costes. Distingue además la cuota de una suscripción ChatGPT de la facturación por tokens con una clave API. Consulta las condiciones de tu cuenta en la documentación de precios y uso.
8. Una rutina para empezar hoy
Prueba los valores predeterminados de Chat para preguntas breves y definición del problema; Work con Sol predeterminado o Medium para archivos terminados; y Codex con Sol predeterminado o Medium para cambios de repositorio. Compara Luna High en tareas recurrentes predecibles y Astra Light o Medium cuando importe un juicio cuidadoso.
Después ajusta el esfuerzo según el resultado. Con Max, especifica un problema que requiera examen profundo. Con Ultra, define partes independientes y criterios de integración. Sea cual sea el ajuste, contrasta resultados y fuentes, y verifica los criterios de finalización en el archivo real o en la interfaz en funcionamiento.