OpenAI's Chat / Work / Codex Split: What It Means for How You Actually Build

OpenAI has stopped treating ChatGPT as one blurry catch-all and split the experience into three named products: Chat, Work, and Codex. The company's own one-liner sums up the intent — "Chat for answers. Work for workflows. Codex for development." If you build software, this reframing matters less as marketing and more as a decision tree: which surface do you actually reach for when you sit down to get something done?

Below is a practical breakdown of the three, plus the concrete Codex workflow features worth knowing — and a sober note on how much of the pitch to take on faith.

The three products, in plain terms

The split is really about how much autonomy and context each surface is built to carry.

• Chat is the fast path to an answer. Brainstorming, drafting, explaining a stack trace, rubber-ducking an architecture question — the things you'd previously open a chat window for. Low ceremony, quick turnaround.
• Work is aimed at multi-step workflows across the web, mobile, and desktop. OpenAI positions it as powered by the Codex harness and an agent runtime, able to operate across your connected apps and files and turn a stated goal into finished materials — sheets, docs, web outputs — rather than just text you then have to assemble yourself.
• Codex is the developer surface: repo-level work with your local code, terminals, and dev tools on the desktop, and Codex is now on mobile too. This is where you point an agent at an actual codebase.

Chat vs Work vs Codex — when to reach for which

The useful mental model: Chat is a conversation, Work is a runtime that produces artifacts, and Codex is where that runtime touches your source of truth — the repository.

What's new in Codex

Several of the more interesting additions sit inside Codex, and they're the ones most likely to change a developer's day-to-day.

• Diff editing and PR review. Codex can edit diffs directly and review pull requests, moving it from "writes code" toward "participates in the review loop."
• PR Chat. You can make follow-up edits on a pull request without leaving Codex — the back-and-forth that used to bounce you between the agent and the Git host now stays in one place.
• A built-in browser. Signed-in tabs, downloads, and annotations live inside Codex, and there's a Chrome extension too. That closes a familiar gap: agents that could reason about your app but couldn't actually see the rendered page.
• Computer Use for longer multi-step tasks, where the agent drives a UI over an extended sequence rather than a single call.
• Sites. OpenAI describes this as going from an idea to a published, secure app in minutes — the prompt-to-deployed-thing pipeline, folded into Codex.

If you're weighing Codex against the rest of the field, our Cursor vs Claude Code vs Codex breakdown is a useful companion — the product surface is only half the story; the model and the ergonomics are the other half.

The workflow features that actually change how you work

Product boundaries are one thing; the workflow primitives are where the leverage is. Three stand out.

The /goal loop in Codex. Instead of prompting for a change and hoping, /goal asks you to define the outcome, the constraints, and — crucially — the proof of completion, then runs a review / repair / validation loop against it. This is the same discipline good engineers already apply: don't describe the diff, describe the finished state and how you'll know it's done. Making that explicit gives the agent a target it can check itself against instead of stopping at "looks plausible."

Subagent threads. Codex can spin up parallel threads for different slices of a task — one exploring the codebase, one writing tests, one implementing — so the work fans out instead of crawling through a single linear conversation. If you want the deeper pattern here, we've written about splitting a big task across specialized subagents; the OpenAI version is the same idea wired into Codex natively.

API-triggered Workspace Agents. This is the one worth flagging for anyone building internal tooling. A ChatGPT Workspace Agent can be kicked off by an API trigger — a form submission, a support ticket, a CRM update, a backend event — run asynchronously, and write its result into a configured destination. That turns "an agent I chat with" into "an agent wired into my systems," which is a different category of tool. A ticket comes in, the agent runs, the output lands where you told it to. No human in the loop for the trigger.

The model context

All of this rides on OpenAI's new GPT-5.6 family — reported to come in Sol, Terra, and Luna tiers — which now powers Codex. If you care about the model layer specifically rather than the product wrapper, we covered GPT-5.6's Sol, Terra and Luna tiers separately.

On the token-efficiency side, OpenAI points to a few levers worth knowing regardless of which agent you use:

• Prompt caching to avoid re-paying for stable context.
• reasoning.context: all_turns paired with previous_response_id to carry reasoning across turns.
• Programmatic Tool Calling, where the model writes and runs JavaScript that orchestrates tool calls inside a sandbox instead of firing them one at a time.
• Auditing your AGENTS.md and Skills — leaner instructions mean fewer tokens burned re-reading boilerplate on every run.

That last point is the cheapest win on the list and the easiest to ignore: bloated agent instruction files quietly tax every single run.

A grain of salt

Here's the part to keep your engineering skepticism switched on for. Almost everything above is OpenAI describing its own products, so read the capability claims as vendor claims until your own repo proves them. "Turns a goal into finished materials" and "a published, secure app in minutes" are aspirations stated by the company; how they hold up on a messy, real-world codebase is exactly the thing you can't know from a launch post.

If you come across benchmark comparisons — including any framed against competitors like Claude Fable 5 — treat them as self-reported and not independently verified. That's not an accusation; it's just how first-party benchmarks work. The neutral move is the same one you'd make with any tool: run it on a task you already understand the answer to, watch where it drifts, and decide from evidence rather than the slogan.

Bottom line

The Chat / Work / Codex split is a genuinely useful clarification of what ChatGPT is for at any given moment: quick answers, multi-step workflows that produce artifacts, and repo-level development. The Codex additions — PR Chat, a real browser, /goal, subagents, Sites, and API-triggered Workspace Agents — are the parts most likely to change how you actually build, especially if you're wiring agents into internal systems rather than just chatting with them. Take the performance claims as claims, prove them on your own code, and adopt the pieces that survive contact with your real work.