Commit 536c949
fix(proxy/openai): propagate provider usage on the Responses WS->HTTP fallback (#2988)
## Description
When Codex uses the OpenAI Responses WebSocket endpoint through Headroom
and the upstream WebSocket is rejected, Headroom falls back to HTTPS
POST/SSE. On that fallback the dashboard reported zero or tiny input
tokens for a large request, and invalid savings:
```json
{ "input_tokens_original": 3, "input_tokens_optimized": 0,
"output_tokens": 246, "tokens_saved": 31052, "savings_percent": 33233.33 }
```
## Root cause
`_ws_http_fallback` (openai.py) relays the SSE `data:` events to the
client but never parses the terminal `response.completed` event for
usage. The non-fallback WS path accumulates
`_extract_responses_usage(event)` into the session totals on every
`response.completed` frame (openai.py ~8182); the fallback path did not.
So `ws_input_tokens_total` stayed at the small local count, and the
session-end RequestLog computed `optimized_tokens =
residual_input_tokens = 0`, leaving `tokens_saved >
input_tokens_original` and `savings_percent` far above 100%.
## Fix
`_ws_http_fallback` now parses each relayed `response.completed` line
with the existing `_extract_responses_usage` and returns the accumulated
`(input, output, cache_read, cache_write, uncached)` provider usage. The
caller folds it into the WS session totals, so the session-end outcome
uses the authoritative provider wire-token count -- bringing the
fallback to parity with the non-fallback WS path. SSE relay behaviour is
otherwise unchanged.
Fixes #2957
## Type of Change
- [x] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
- [ ] Performance improvement
- [ ] Code refactoring (no functional changes)
## Changes Made
- `headroom/proxy/handlers/openai.py` (`_ws_http_fallback`): accumulate
usage from `response.completed` SSE lines (both the main relay loop and
the buffer flush) and return the `(input, output, cache_read,
cache_write, uncached)` tuple from every exit path; the WS handler
caller adds it to `ws_input_tokens_total` / `ws_output_tokens_total` /
cache / uncached totals before the session-end RequestLog.
- `tests/test_ws_http_fallback.py`: the fallback returns the provider
usage from a `response.completed` event
(input/output/cache_read/uncached), and returns all-zeros when no
completed event arrives.
## Testing
- [x] Unit tests pass (`pytest`)
- [x] Linting passes (`ruff check`)
- [x] Type checking passes (`mypy`)
- [x] New tests added
### Test Output
```text
tests/test_ws_http_fallback.py 13 passed (11 existing + 2 new)
# uvx ruff@0.15.22 check -> All checks passed!
# uvx mypy@1.20.2 headroom/proxy/handlers/openai.py -> Success: no issues found in 1 source file
```
## Real Behavior Proof
- Environment: Windows 11, Python 3.12.11, project venv, pytest 9.1.1,
ruff 0.15.22 and mypy 1.20.2 via uvx.
- Exact command / steps: drove `_ws_http_fallback` with the existing
WS/stream mocks, feeding an SSE `response.completed` carrying
`usage.input_tokens=31055`, `output_tokens=246`,
`input_tokens_details.cached_tokens=20000`. The method now returns
`(31055, 246, 20000, ..., 11055)`; a stream with no completed event
returns all zeros. The existing 11 relay/routing/retry tests are
unchanged (they ignore the new return value).
- Observed result: the fallback surfaces the provider's real input
usage, so the WS session-end outcome records the actual input tokens
instead of 0, and savings percentages stay within a meaningful range.
- Not tested: a live Codex WS session that triggers the upstream-WS
rejection and HTTP fallback end to end (needs a real upstream refusing
the WS). The usage-propagation contract is verified at the fallback
boundary with the same mocks the existing fallback tests use.
## Runtime Rollout Safety
- Rollout-managed feature(s): none. The OpenAI Responses WS-to-HTTP
fallback is always-on transport behavior, not rollout-channel-gated.
- Minimum rollout channel: N/A (no rollout-managed behavior).
- Stable/default behavior changed: yes, as a bug fix. On the WS-to-HTTP
fallback the session-end outcome now records the provider's real
input/output/cache usage from `response.completed` instead of leaving
`ws_input_tokens_total` at 0 (which produced >100% savings). SSE relay
to the client is unchanged.
- Kill switch / disable path: N/A. This corrects accounting only; there
is no behavioral toggle and no user-facing surface beyond the recorded
outcome numbers.
- Unsafe override required: no.
- Qualification impact: fallback-path token accounting now matches the
non-fallback WS path and the HTTP Responses path (all three use
`_extract_responses_usage`); savings percentages return to a valid
range.
- Rollback path: revert this PR; the fallback returns to reporting zero
input usage on this path.
## Review Readiness
- [x] I have performed a self-review
- [x] This PR is ready for human review
## Checklist
- [x] My code follows the project's style guidelines
- [x] I have performed a self-review of my code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective
- [x] New and existing unit tests pass locally with my changes
- [x] I did **not** edit `CHANGELOG.md`: it is generated by
release-please from my Conventional Commit PR title
## Additional Notes
The fix reuses the already-present `_extract_responses_usage` (same
parser the non-fallback WS path and HTTP Responses path use), so
cache-read/write and uncached accounting stay consistent across all
three transports.
Co-authored-by: JD Davis <mxjerrett@gmail.com>1 parent a06a51e commit 536c949
2 files changed
Lines changed: 86 additions & 5 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
8602 | 8602 | | |
8603 | 8603 | | |
8604 | 8604 | | |
8605 | | - | |
| 8605 | + | |
| 8606 | + | |
| 8607 | + | |
| 8608 | + | |
| 8609 | + | |
| 8610 | + | |
| 8611 | + | |
8606 | 8612 | | |
8607 | 8613 | | |
| 8614 | + | |
| 8615 | + | |
| 8616 | + | |
| 8617 | + | |
| 8618 | + | |
| 8619 | + | |
| 8620 | + | |
| 8621 | + | |
8608 | 8622 | | |
8609 | 8623 | | |
8610 | 8624 | | |
| |||
8850 | 8864 | | |
8851 | 8865 | | |
8852 | 8866 | | |
8853 | | - | |
| 8867 | + | |
8854 | 8868 | | |
8855 | 8869 | | |
8856 | 8870 | | |
8857 | 8871 | | |
8858 | 8872 | | |
8859 | 8873 | | |
| 8874 | + | |
| 8875 | + | |
| 8876 | + | |
| 8877 | + | |
| 8878 | + | |
| 8879 | + | |
8860 | 8880 | | |
| 8881 | + | |
| 8882 | + | |
| 8883 | + | |
| 8884 | + | |
| 8885 | + | |
| 8886 | + | |
| 8887 | + | |
| 8888 | + | |
| 8889 | + | |
| 8890 | + | |
| 8891 | + | |
8861 | 8892 | | |
8862 | 8893 | | |
8863 | 8894 | | |
| |||
8963 | 8994 | | |
8964 | 8995 | | |
8965 | 8996 | | |
8966 | | - | |
| 8997 | + | |
8967 | 8998 | | |
8968 | 8999 | | |
8969 | 9000 | | |
| |||
8989 | 9020 | | |
8990 | 9021 | | |
8991 | 9022 | | |
| 9023 | + | |
8992 | 9024 | | |
8993 | 9025 | | |
8994 | 9026 | | |
8995 | | - | |
| 9027 | + | |
8996 | 9028 | | |
8997 | 9029 | | |
8998 | 9030 | | |
| |||
9001 | 9033 | | |
9002 | 9034 | | |
9003 | 9035 | | |
| 9036 | + | |
9004 | 9037 | | |
9005 | 9038 | | |
9006 | | - | |
| 9039 | + | |
9007 | 9040 | | |
9008 | 9041 | | |
9009 | 9042 | | |
| |||
9034 | 9067 | | |
9035 | 9068 | | |
9036 | 9069 | | |
| 9070 | + | |
9037 | 9071 | | |
9038 | 9072 | | |
9039 | 9073 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
310 | 310 | | |
311 | 311 | | |
312 | 312 | | |
| 313 | + | |
| 314 | + | |
| 315 | + | |
| 316 | + | |
| 317 | + | |
| 318 | + | |
| 319 | + | |
| 320 | + | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
| 324 | + | |
| 325 | + | |
| 326 | + | |
| 327 | + | |
| 328 | + | |
| 329 | + | |
| 330 | + | |
| 331 | + | |
| 332 | + | |
| 333 | + | |
| 334 | + | |
| 335 | + | |
| 336 | + | |
| 337 | + | |
| 338 | + | |
| 339 | + | |
| 340 | + | |
| 341 | + | |
| 342 | + | |
| 343 | + | |
| 344 | + | |
| 345 | + | |
| 346 | + | |
| 347 | + | |
| 348 | + | |
| 349 | + | |
| 350 | + | |
| 351 | + | |
| 352 | + | |
| 353 | + | |
| 354 | + | |
| 355 | + | |
| 356 | + | |
| 357 | + | |
| 358 | + | |
| 359 | + | |
313 | 360 | | |
314 | 361 | | |
315 | 362 | | |
| |||
0 commit comments