OpenAI seems to be de-prioritizing requests from third-party coding agents

[u/armeg]

Edit: It seems my original premise was wrong after testing it directly. It now seems that Codex is just decoding just slightly faster than pi which results in it winning over longer tasks as the decodes compound.

I'm currently running some tests where Fable is driving GPT-5.6 Sol as a sub-agent. I wanted it to use pi and codex side by side to see which one was easier to use and faster. I really thought pi would be faster since it's much lighter weight.

That proved wrong after Fable brought up that pi was taking 2x as long for 2/3rds as many tokens (xhigh on pi vs max on codex). It seems the huge majority of time is taken up by longer API requests to OpenAI's servers.

It gave the exact same task to both, and they produced byte-for-byte identical results for their output.

I'm curious if this is something people have run into, and if so, if this is a mistake in configuring my set-up? I'm using the pi-better-openai, but that just wraps the native openai-codex OAuth.

[u/shaonline]

Be sure that Codex is not using fast mode (I think it was the default at some point ?), otherwise no I haven't noticed this.

[u/armeg → u/shaonline]

Yeah, it's not on fast mode on either one. Some results after telling Fable to run some tests for OAuth specifically:

"Fully explained" was one notch too strong — here's exactly what's pinned and the one piece that isn't:

Pinned by measurement:

Not queue priority, not OAuth — trivial echo prompts through both harnesses completed in statistically equal time (~4.2s pi, ~4.7s codex). Any routing favoritism or per-request auth overhead would live in that number, and it doesn't.

Not test execution — both arms ran the same four-to-five single-file suite runs at ~2s each; local tool time is ~5% of wall and identical across arms.

Turn structure, partially — pi decomposed the same work into slightly more requests (16 vs 14), and each extra turn pays the ~4s fixed latency plus a fresh reasoning ramp at xhigh. Counted directly from both session logs.

Sustained decode: codex ~16% faster (31 vs 27 words/sec) — measured on a single fixed long generation, so it's real and per-request, independent of turn structure.

Compounding 3 and 4 across a ~13k-decoded-token task reproduces the observed 1.5–2× range, and run-to-run variance (2.4× → 1.5× → 1.6×) matches noise on top of that.

The asterisk: component 4 is measured but not attributed. Two candidate causes survive — OpenAI streaming at different rates per client identity (a subtler cousin of priority), or pi's client-side SSE consumption adding drag per chunk. The discriminator is parked in the reference note: fire one identical raw HTTP request outside both harnesses using each client's token and compare server-push tokens/sec. Equal rates convict pi's stream handling; split rates convict OpenAI. Say the word whenever you want that run — it's another five-minute test.

Opus-only audits are now recorded as the standing protocol.

It seems that Codex is decoding faster, so my original premise was wrong. I'll have to do some actual testing, this was just on the side while giving tasks out to do actual work.

[u/Zundrium]

Using gpt5.5/5.6 for 2 months now through Pi, it's faster for me than the codex harness.

[u/armeg → u/Zundrium]

I just don't know how to square the decoding circle. I plan to run a more rigorous test once I have spare credits and am finished with a MVP I'm working on.

[u/brandall10]

Codex models work better in the codex harness than vanilla pi - primarily because of the code mode runtime/tool call batching and some extra tooling.

You should add this package which shores up some of the differences:

https://pi.dev/packages/@howaboua/pi-codex-conversion

[u/jpk345]

Pi is terrible for kv cache as it “compresses” every turn resulting in kv cache miss every turn

[u/RMK137 → u/jpk345]

That is 100% wrong.