Dots vs Codex: Two Very Different Kinds of Autonomy

OpenAI's DevDay announcement listed dots as reachable "through ChatGPT or Codex" — a small phrase that's easy to skim past, but that quietly acknowledges something worth unpacking: OpenAI now runs two distinct autonomous-coding products, and they are not the same product wearing different names. Codex is OpenAI's dedicated coding agent, built around a session model — you give it a task, it works within a scoped environment, and it reports back. A dot is built around the opposite premise: it doesn't need a session to start, because it's already running.

Two different defaults

Codex, as OpenAI and independent coverage have described it since its earlier releases, operates as a bounded engagement: a developer kicks off a task — implement a feature, fix a failing test, refactor a module — and Codex works inside a defined scope, typically a sandboxed environment tied to a specific repository, until the task is done or handed back for review. The autonomy is real, but it's autonomy within a session you started. When the task ends, so does the run.

A dot inverts that. Per OpenAI's own framing, a developer's dot can watch a customer feedback channel continuously, decide on its own that something warrants a fix, draft that fix, and return a pull request with a demo video attached — without a human first opening a session and defining the task. The trigger isn't a prompt. It's a standing instruction plus whatever the dot's proactive research turns up in the meantime.

What that means for the actual coding work

This is the practical distinction worth internalizing if you're deciding which tool fits a given job. Codex-style, session-bound autonomy is the right fit when you already know the task: "migrate this API to the new schema," "add test coverage for this module." You're the one who noticed the work needed doing; Codex just needs to be told and then largely left alone to do it.

A dot is aimed at the earlier step in that chain — noticing that work needs doing in the first place. OpenAI's developer use case is explicitly framed around monitoring, not execution on request: the dot reads incoming feedback, decides a bug report is real and reproducible, and only then does something that looks like a Codex task — drafting a fix. In a fully built-out workflow, it's plausible a dot could be the thing that decides a Codex-style task is warranted, even if the two systems aren't described as literally handing work to each other in the sources available as of this writing. OpenAI hasn't published the technical detail of exactly how a dot's coding output relates to Codex's execution model under the hood, and this article won't guess at plumbing that hasn't been disclosed.

Codex answers "how do I get an agent to finish this specific task well." A dot answers "how do I get an agent to notice the task exists."

Why OpenAI needs both

It would be reasonable to ask why one company ships two separate autonomous-coding products instead of merging them into one. The most defensible reading is that they optimize for different failure modes. A session-bound coding agent that runs only when invoked is easier to reason about, audit, and roll back — you know exactly when it started and what it touched, because you started it. An always-on monitoring agent is more useful precisely because it doesn't need you to start it, but that convenience is also where the risk concentrates: an agent deciding on its own when something is worth acting on is a fundamentally harder thing to bound than an agent executing a task you handed it directly.

That's a version of the same tension covered in Custom Rules: How Dots Learn What They Are Allowed to Do — the more autonomy you grant on the initiation side, the more the guardrails have to do on the execution side to keep the outcome bounded. Codex sidesteps that by keeping initiation manual. A dot doesn't get that shortcut, which is exactly why OpenAI built Custom Rules, Auto-Review, and the Activity View specifically for it.

The comparison that actually matters to teams

For an engineering team deciding how to adopt either tool, the practical question isn't "which is smarter." It's "which decision am I comfortable delegating." Delegating execution of a well-specified task — the Codex model — is a much smaller leap of trust than delegating judgment about what's worth doing — the dot model. Most teams will reasonably start with the former and graduate to the latter only after enough confidence in Custom Rules and Auto-Review to feel comfortable with an agent making the first call unsupervised.

It's also worth situating both against the layer aiskill.market actually deals in. A Claude Code Skill is neither of these things — it's not an always-on monitoring agent and it's not a standing coding session either. It's a scoped, inspectable capability you install into an agent session you're already running, closer in spirit to a well-documented library than to either a dot or a Codex task. The three aren't competitors so much as three different answers to "how much should the agent decide on its own, and for how long."

A rough decision framework

Put plainly, the choice among the three roughly maps to a question about who's supplying the judgment at each stage of a piece of work. A skill supplies a specific, well-tested capability — parsing a file format, following a house style, running a checklist — that a human or another agent invokes deliberately, with the judgment about when to invoke it staying entirely with whoever's driving the session. Codex supplies sustained execution once a human has already exercised judgment about what needs doing; the judgment about what to build is still yours, and Codex's autonomy kicks in only after that decision is made. A dot supplies the earliest and least constrained layer of judgment — deciding, on its own, that something is worth acting on at all, based on standing instructions rather than a fresh prompt.

None of that makes one approach categorically better than the others; it makes them suited to different amounts of delegated judgment, and a mature engineering workflow will likely end up using all three at once — skills for well-defined repeatable capabilities, Codex-style sessions for scoped execution, and a dot, if adopted, for the narrower slice of work where noticing something needs doing is itself the hard part. Where OpenAI's own newer collaborative surface — ChatGPT Space — fits humans, dots, and Codex into one shared workspace is the subject we turn to next.

Part 4 of 30 in the ChatGPT Dots series. Previously: Every Dot Gets a Computer: What That Actually Means. Next: ChatGPT Space, Explained: Where Dots and Humans Meet. Browse more builder insights or explore AI skills at aiskill.market.