Chinese Codex API Resellers Have a New Problem

Chinese services sell low-cost Codex API access by putting a layer between customers and a large number of ChatGPT subscriptions. A developer gets one API key. Behind it, the service chooses which subscription account will handle each request.

That setup has started causing a very specific problem. Some users are now being told to throw away an existing Codex conversation and start a new one after changing relay channels.

One Chinese relay operator published the error from OpenAI. A user who switched Codex channels inside an existing conversation hit a 400 response saying the encrypted content could not be verified. The operator's advice was blunt: start a new conversation, or delete the part of the conversation created through the other channel. The report is still public.

That is not a normal rate-limit error. It is a problem with how the resale setup works.

The service logs each subscription into a proxy and puts one API endpoint in front of the proxy. When one upstream account has used its quota, the proxy sends the next request through another account. A customer sees one API provider. The reseller sees a pool of accounts.

For a new, one-off prompt, that is easy. Account A answers one request. Account B answers the next one. There is no history to carry over.

The trouble starts when Codex has an existing conversation or starts using sub-agents.

OpenAI changed its newer multi-agent path on June 5. A parent agent's message to a child agent is now encrypted before Codex forwards it. The public Codex pull request says Responses encrypts the parent message, Codex forwards only ciphertext, and Responses decrypts it for the receiving agent. The encrypted state is also what Codex keeps in its history for that handoff.

That means a relay cannot simply read the parent-to-child instruction and replay it somewhere else. If it sends the next part of the job to another upstream account or another incompatible relay, OpenAI can reject the encrypted state. That is exactly what the relay operator above was warning about.

The public software used to build these account pools is dealing with the same problem. codex2api added a feature for continuing interrupted reasoning. Its July 9 implementation note says the encrypted reasoning content is tied to the upstream account and that changing accounts creates a mismatch. The workaround is to reuse the same account and the same upstream connection. That note is in the project's own pull request.

Two days later, someone opened a request for root-session account affinity in the same project. They had seen a parent on account A and children land on account B. Their proposed fix is unglamorous: once a job lands on A, keep every child on A. If A is full, wait for A. That is the request.

That is a bad trade for a reseller. The pool exists so that a full account can be replaced by another account. It can still do that for a new, simple prompt. It cannot safely do it in the middle of a Codex job with history and sub-agents. The customer gets a queue instead of the extra capacity they thought they were buying.

OpenAI has another reason to dislike these relays. In a February memo to Congress, it said Chinese companies had used third-party routers and unauthorized reseller networks to collect outputs for distillation. OpenAI never said this particular encryption change was made for that purpose. Still, a relay that cannot move encrypted agent state between its accounts is worse at pooling capacity and less useful for collecting an uninterrupted agent trace.

If a cheap Codex API now tells you to start a new conversation after changing channels, it is not just being annoying. It has lost the ability to carry the encrypted state from the old upstream account into the new one.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com