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

[rikbrown]

Rebased onto current main — still the same two commits, content unchanged.

Flagging an overlap so it isn't discovered at merge time: #149 also surfaces the Codex rate-limit snapshot to the client, as a typed codex_rate_limits field on the terminal message_delta usage. This PR does it as x-codex-* response headers. Same data, different channel, and the two don't conflict textually — #149 is in reducer.rs/live_stream.rs, this is a separate module plus its call sites.

The reasoning/thinking tokens half of #149 is orthogonal to this and useful on its own; nothing here competes with it.

On the rate-limit half, the one property headers have that the usage field doesn't: they arrive before the body, so a caller can read the meter without parsing the stream to completion. That matters if you're pooling subscriptions and want to route on quota before committing a turn, or if you're forwarding responses without buffering them. The usage field is the better fit if the consumer is already reading usage anyway and wants it in one place. They can also coexist — the header path doesn't preclude the field.

Happy to defer if you'd rather have one mechanism: I can close this, or rework it to read from whatever #149 lands as. Just say which you prefer rather than carrying both by accident.