OpenAI Codex joins Trinity's growing engine family
A month ago we made a promise: Trinity treats the harness as the real unit of portability, and OpenAI Codex was on the way. It's here. In 0.3.0, Codex joined Claude as an engine you can run Trinity on — chosen from a settings page, not a migration.
This is the thesis paying off: the framework is the product, the harness is the engine. Trinity's planning, per-story worktree isolation, audit loops, and knowledge base run identically no matter which engine drives the tokens. You just got a second engine to choose from.
Pick your engine in Settings → AI Models
Open Settings → AI Models and Claude and Codex now sit side by side in the same picker, each model surfaced with an intelligence rating and a cost estimate so you can weigh them at a glance. Codex brings three:
| Codex model | Intelligence | Where it fits |
|---|---|---|
| GPT-5.5 | Highest | Architecture, complex planning, hard refactors |
| GPT-5.4 | Mid | Everyday implementation, review, story execution |
| GPT-5.4 Mini | Lean | Lightweight audits, commit messages, renames |
The effort slider you already use on Claude works the same way here — low / medium / high / xhigh — so dialing Codex up or down for a tier is muscle memory, not a new mental model.
Pick an engine once and it powers every AI action in Trinity — onboarding, planning in Architect, alignment sweeps, audits, the help assistant, and story runs alike. Not one surface; all of them. Set a default globally, then override it per team or per project when a particular codebase wants a particular engine.
The framework never branches
Here's why this was a setting and not a rewrite.
Underneath, Trinity drives every engine through a single AgentHarness interface with a small registry — two entries today, claude-code and codex. The planning pipeline, the worktree isolation, the multi-agent audit loop, the knowledge base — none of it knows or cares which engine is running. It never branches on the harness. That's the whole point of building above the harness layer instead of gluing yourself to one vendor's terms.
Structured framework. Swappable engine.
Switching from Claude to Codex changes which models move the tokens. It changes nothing about how Trinity plans, executes, audits, or remembers. The framework is the product. The engine is your choice.
Claude Code
Anthropic's official CLI agent
DefaultCodex CLI
OpenAI's open-source CLI agent
Coming SoonOpenCode
Open-source multi-provider agent
Coming SoonMix Claude and Codex in the same run
Trinity routes every task through one of four reasoning tiers — Reasoning, Standard, Fast, Micro — and each tier carries its own engine and model, stored as harness:provider:model. That means you can run Reasoning on Claude Opus and Standard on a GPT model in the same pipeline run, matching each class of work to the engine that's best and cheapest for it.
Point all four tiers at Codex and the defaults land sensibly: GPT-5.5 for Reasoning, GPT-5.4 for Standard, and GPT-5.4 Mini for Fast and Micro.
Architecture, complex planning
Most implementation, review
Lightweight audits, analysis
Commit messages, renames
Stored as harness : provider : model, per tier
Authentication: two paths, no migration
Trinity launches Codex through its official CLI, so auth reuses what you already have. Two paths:
- Your existing
codex login— Trinity reads the OAuth session from your local~/.codex/auth.json. If you've used Codex CLI on this machine, you're already signed in. - A Trinity-managed OpenAI API key — prefer to keep it scoped to the app? Drop a key in Project Settings → Secrets and Trinity uses that instead.
Either way, switching engines is a setting, not a checkout. And the bill stays honest: per-story spend and the AI Usage page read each provider's real structured usage — input, output, cache, and reasoning tokens — straight from the source, so what you see is what you were billed.
Already drive Codex CLI from your terminal? Trinity rides your existing session — pick Codex in Settings → AI Models and your next story run is on it. No new login.
What this means for you
If you came to Trinity worried about getting stuck inside one vendor's pricing or policy decisions, this is the answer in practice rather than in principle. Two engines, one framework, your call — set globally, overridden per project, mixed per tier. When OpenAI's models are ahead for a class of work, route to them. When Claude's are, route there. The framework doesn't flinch either way.
OpenCode is next
The roadmap named three harnesses, and Codex was the first to ship. OpenCode is next — the open-source, bring-your-own-provider engine. The scaffolding is already in the codebase; it's not in the picker yet, so consider it on the roadmap, not shipped. When it lands, it'll show up exactly where Codex did: side by side in the same picker, same effort slider, same framework underneath.
That's the shape of the whole bet. Every engine that gets better makes Trinity better, because the framework is what turns an engine's output into something you can actually ship. Codex is the second engine. It won't be the last.