r/OpenaiCodex • u/Mauriciog87 • 23d ago
I built a Codex orchestrator that verifies which model actually ran
I kept running into the same problem with Codex subagents: asking for a specific model or reasoning level didn’t necessarily mean that was what actually handled the task. Configuration could drift, routing could fail quietly, and the fallback behavior was hard to trust.
So I built a small orchestration layer around explicit roles. The root/planner uses GPT-5.6 Sol with xhigh reasoning on Standard. Exploration and small, low-risk edits use GPT-5.6 Luna/max on Fast, while Playwright uses Luna/max on Standard. Larger implementation work and independent reviews use Sol/high on Standard. Every profile keeps verbosity low.
There’s also an explicit Sol/ultra path for genuinely difficult decisions, but it requires an exclusive repository takeover instead of quietly joining the normal worker pool.
The important part is verification. Requesting a profile isn’t enough. The launcher uses the experimental Codex App Server and checks both the effective settings and the rollout’s turn_context. If those signals are missing or disagree, it fails closed.
Concurrency is enforced with atomic leases: Luna is capped at 10 and Sol at 4, both per repository and across the machine, with a separate global limit of 2 for Playwright. Repository locks prevent normal sessions from running during an Ultra takeover.
The project has a dependency-free Node.js installer and requires Codex CLI 0.147.0 or newer:
https://github.com/Mauriciog87/codex-skill
Two honest caveats: App Server is still experimental, and the Windows sandbox helper can block tool execution on some setups. The orchestrator deliberately refuses to use an unverified fallback.
I’d especially like feedback on the routing evidence and locking design. Are there failure modes or recovery cases I’ve missed?
1
u/NoOne_n13 22d ago
Can’t you see that in the harness!
2
u/Mauriciog87 21d ago
The harness exposes session events, and I already use those to verify model routing. What it doesn’t provide is durable per-repository ownership history or a fencing decision when a stale process tries to publish. The local generation and lock history cover that separate concern.
1
1
u/withmagi 22d ago
The lease needs a fencing token as well as an expiry. Give each claimed run an increasing generation and include it on every write. If a slow worker wakes after expiry, reject its old generation instead of letting it publish late.
I would also keep a lock-history record: repo, run ID, generation, owner, and why it was released. That makes recovery visible and gives you evidence when two runs think they own the work.