Decision guide · Not a model ranking
Start with the task.
Then pick the tool.
Do you need an answer, a deliverable, a code change, or a feature inside your own application? That distinction is more useful than choosing by product name alone.
These are starting points, not exclusive capabilities. OpenAI documents substantial overlap between Work and Codex. Availability depends on the account, workspace, platform and selected environment. Official comparison ↗
01 / An answer is the output
Use Chat to work through the question.
For an explanation, brainstorming or a short draft, a conversational result may be enough. You do not need to turn every question into a larger agent task.
Try a bounded request
“Compare these two outline options for a five-minute presentation. Explain the tradeoff; do not create a deck yet.”
Know when you are done
You can explain the choice and identify what evidence is still missing. If you now need a finished file, carry the agreed brief into a deliverable workflow.
02 / A reviewable deliverable
Consider ChatGPT Work when the output is a finished task.
OpenAI describes Work as a way to delegate multi-step work using sources, files and approved tools. Specify the deliverable and what you will check.
Try a bounded request
“Use only these three files to make a six-slide briefing. Separate evidence from recommendations, flag missing support, and stop at a draft for review. Do not send it.”
Know when you are done
Open the file, trace important claims to inputs, and request one precise correction. A download link alone is not evidence of a correct deliverable.
For local files or apps, check the selected environment. Cloud work does not automatically have access to everything on your computer. Source: getting started with Work ↗
See file evidence, examples and limits →03 / A project with changes to inspect
Consider Codex when the review needs technical detail.
Codex exposes development-oriented workflows for project files, commands, tests and diffs. Work and Codex overlap; Codex is not limited to source code.
Try a bounded request
“Fix this parser using the existing test suite. Add a regression for the failing input, preserve unrelated changes, and show the diff. Do not commit or deploy.”
Know when you are done
The relevant tests pass, the diff matches the request, and remaining risks are explicit. Passing tests are evidence for the cases they cover, not proof of every possible behavior.
04 / A capability inside your software
Consider the API when your application must call the model.
The API gives software a programmatic interface to OpenAI capabilities. That is a different job from asking an agent to create your application.
A useful dividing line
“Build a prototype support dashboard” is an agent task. “Have the dashboard summarize each permitted ticket at runtime” is an application integration. A project can need both.
Know when you are ready
Use synthetic examples first. Define access controls, server-side credential handling, evaluations, failure behavior and spending limits. Do not expose API credentials in a web page or assume a subscription establishes API access.
Before you start
Four boundaries to make explicit.
- Inputs: Which files, sources and accounts may the tool use? Start with non-sensitive samples.
- Environment: Does the task need your computer, a hosted workspace, or your application’s backend?
- Review: What observable result will you inspect—sources, formulas, page layout, test output or an evaluation set?
- Authority: Should the task stop before sending, sharing, purchasing or deploying? Say so.
If a feature is missing, check the official documentation, account and workspace controls. Do not buy a plan based only on this guide.
A starting point, not a universal winner.
These recommendations translate official product descriptions into task choices. We have not performed a comparative performance benchmark or tested access across plans. Choose the smallest workflow that produces a result you can inspect.
See what recently changed → · Explore other OpenAI offerings →