feat(codex): forward quota telemetry to the client

[rikbrown]

Problem

Codex reports how much of a ChatGPT subscription is spent in two places: x-codex-* headers on an HTTP response, and a codex.rate_limits event on the WebSocket transport. Neither reaches the client. The proxy answers in Anthropic's format, which has no equivalent field, so the event is classified as control and becomes a ping, and the response headers are dropped.

That leaves anything sitting in front of the proxy — a rotating multi-account gateway, a quota readout — unable to see the limit it is about to hit. The first sign of a spent window is a 429.

Change

A new providers/codex/rate_limits.rs keeps the newest snapshot and stamps it onto every Codex /v1/messages response, under the header names Codex itself uses, so a client that already parses them needs no second format. Both transports feed it: the HTTP response head, and the codex.rate_limits event.

Only quota headers are forwarded. x-codex-turn-state is continuation state, and a large opaque blob to put on every response.

Codex sends the event ahead of the first generated output and the response head is built from that output, so a response normally carries the numbers of the request it answers. One that arrives before any telemetry does carries the previous snapshot, or none.

Which window is which is left to the client, because it varies: a ChatGPT Pro subscription reports its weekly limit as primary and meters no secondary window at all, so the -window-minutes header is what identifies a bucket, not the position.

Testing

• Six unit tests in the new module, covering both sources, the header filter, and the stamped response.
• cargo test — 1033 pass. cargo clippy --all-targets and cargo fmt --check clean.
• Checked against a live ChatGPT Pro subscription on both transports, streaming and buffered.

The HTTP API reference gains a paragraph describing the headers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01S3HCmE8ZPT1o59UCGaoEeV