Editorial illustration of a glowing neural-network orb and a small tool-wielding robot splitting from a shared root with loose wires on a warm desk scene

Last night I asked my agent a simple question: can we use Codex through the same API gateway I already route my other models through? On the surface it's a yes-or-no question about routing. The answer came back "yes, mechanically — but 'Codex' isn't what you think it is," and the next twenty minutes became a tour of a naming mess I'd been carrying around without noticing.

The part I had to unlearn: Codex is not one thing. It's at least three, all wearing the same name.

The three Codexes

When people say "Codex" in 2026, they usually mean one of three very different objects:

  • Codex the model — a family of models with "codex" in the name. The original codex-1 shipped in April 2025 as a version of OpenAI's o3 fine-tuned for software engineering. The family has since moved through GPT-5.3 Codex and into the GPT-5.5 generation. A model is just weights behind an API. Tokens in, tokens out.
  • Codex the harness — the agent runtime, and the part I'd been ignoring. The harness is the program that drives the model: it runs the planning loop, executes tools, manages context, threads, sandbox permissions, and approvals. It's a Rust library (Apache-2.0, open source), and it's the same engine behind every Codex surface.
  • Codex the product — the umbrella. The CLI, the web app, the VS Code extension, the desktop app (macOS in February, Windows in May), the ChatGPT Agent. Different surfaces, one harness, one account, one model family.

The model is the brain. The harness is the body that does things with the brain. The product is the store that sells you the whole package. Three different answers to "what is Codex?", all correct.

What I actually asked for

My question was narrower than all of that. I wanted to know whether I could drop "Codex" into a model field the way I'd drop in any other model string — same API shape, no special client, no CLI.

Mechanically, yes. A model named "codex" routes through an OpenAI-compatible API exactly like any other model. If all you want is Codex-the-model answering prompts, that works, and the naming makes it look like a clean swap.

What it does not give you is Codex-the-agent. No planning loop. No tool execution. No sandbox. No thread management. No ability to read a repo, edit files, run tests, and iterate until the tests pass. All of that behavior lives in the harness, and the harness isn't something you get by pointing a model field at a name. You get it by running the actual agent runtime — the CLI, the SDK, the app server — and letting it orchestrate the model.

This is the exact mistake the naming invites. "Codex" sounds like a single thing you can plug in, so people plug in the model and then wonder where the agent went.

A model is not an agent

The industry has a word for the distinction now, and it's worth stealing: harness engineering. A harness is "the program that drives the model, runs the tools it asks for, and manages context." The model is a component. The harness is the machine.

The confusion isn't new, but the stakes changed once models got good enough that the difference stopped being academic. A year ago, "give me a smarter model" was most of the game. Now the model is rarely the bottleneck — the loop around it is. Tool choice, context management, sandboxing, when to stop and ask, how to recover from a bad tool call. That's all harness, not weights.

You can see it in how OpenAI talks about the thing now. Their engineering write-ups are less about the model and more about the harness: WebSocket transport to kill HTTP round-trip latency, deferred tools to keep context windows lean, auto-review sub-agents that judge sandbox escalations, server-side compaction so agents can run for days. None of that ships in a model card. It ships in the runtime.

So "can I use Codex through my API gateway?" is really two questions in a trench coat:

  • "Can I call the Codex model through the gateway?" — sure, same as any model.
  • "Can I get the Codex agent through the gateway?" — no. The agent is not a model you call; it's a program you run.

The practical version

For me this settled into a simple rule: when someone says "Codex," ask which one they mean before you wire anything up.

  • If you want a smarter text generator, the model is fine, and you can route it like any other.
  • If you want something that reads your code, runs tools, and finishes tasks, you need the harness — which means the CLI, the SDK, or the app, not a model string.

The failure mode I almost walked into is the common one: assume "Codex" is a model, drop the name into a config field, get a plain model call back, and conclude "Codex is overhyped" because nothing agentic happened. It wasn't overhyped. I just asked the wrong thing.

The takeaway

Names collapse faster than the things they name. "Codex" went from a 2021 code-completion API, to a 2025 cloud agent, to a 2026 umbrella covering a model family, an open-source harness, and half a dozen surfaces — and every one of them still answers to the same word.

The next time you're about to plug something in because its name matches what you want, pause and check what the name is actually pointing at. A model and an agent are different machines. Only one of them fits in a model field.

I almost learned that the expensive way. What's the last name you assumed pointed at one thing, and found out pointed at three?