Repository navigation
Bug: GPT-5.3-Codex-Spark usage incorrectly drains regular Codex limits #23150
Description
Bug
GPT-5.3-Codex-Spark usage is being counted against regular Codex usage. This is unexpected and bad. Spark should not reduce regular Codex remaining capacity.
This is not just a UI wording concern. Local telemetry shows the same Spark call recorded against both buckets:
- regular Codex bucket:
limit_id=codex - Spark-specific bucket:
limit_id=codex_bengalfox,limit_name=GPT-5.3-Codex-Spark
Evidence
Local telemetry file:
~/.codex/sessions/2026/05/16/rollout-2026-05-16T09-58-03-019e2fca-d71f-78d3-8f14-0d0326ec31c3.jsonl
Regular Codex row:
{
"timestamp": "2026-05-17T09:18:01.061Z",
"limit_id": "codex",
"limit_name": null,
"last_token_usage": {
"input_tokens": 210808,
"cached_input_tokens": 209792,
"output_tokens": 70,
"reasoning_output_tokens": 0,
"total_tokens": 210878
},
"total_token_usage": {
"total_tokens": 439784854
},
"primary_used_percent": 43,
"secondary_used_percent": 9
}Immediately adjacent Spark row for the same call:
{
"timestamp": "2026-05-17T09:18:01.062Z",
"limit_id": "codex_bengalfox",
"limit_name": "GPT-5.3-Codex-Spark",
"last_token_usage": {
"input_tokens": 210808,
"cached_input_tokens": 209792,
"output_tokens": 70,
"reasoning_output_tokens": 0,
"total_tokens": 210878
},
"total_token_usage": {
"total_tokens": 439784854
},
"primary_used_percent": 0,
"secondary_used_percent": 0
}The two rows have identical last_token_usage and identical cumulative total_token_usage. Only the limit bucket differs.
I checked local session logs for May 16-17, 2026. Pairing rows by same session id, same last_token_usage.total_tokens, same total_token_usage.total_tokens, and timestamp within 10 seconds found 4,564 Spark rows with matching regular codex rows.
Expected behavior
Spark usage should count against the Spark-specific bucket only. It should not drain regular Codex remaining capacity.
Actual behavior
Spark usage appears to drain regular Codex capacity too. Regular codex usage percentages move alongside Spark calls, even when the Spark-specific row is present.
Impact
This makes the Spark bucket misleading. Users can reasonably expect GPT-5.3-Codex-Spark usage to be isolated from regular Codex capacity. Instead, Spark work appears to consume regular remaining usage, which causes unexpected depletion and makes usage planning unreliable.
Please fix the rate-limit accounting so GPT-5.3-Codex-Spark does not count against regular Codex usage.
Environment
- Codex Desktop
cli_version:0.131.0-alpha.9in relevant session metadata- Date observed: 2026-05-17
Activity
[-]GPT-5.3-Codex-Spark usage appears to also count against regular Codex limits[/-][+]Bug: GPT-5.3-Codex-Spark usage incorrectly drains regular Codex limits[/+]Gerry9000 commentedon May 20, 2026
I pushed a client-side patch branch here: https://github.com/Gerry9000/codex/tree/fix/active-rate-limit-bucket
This addresses the verified client-side bucket-selection bug: the TUI now uses the current model's metered limit id for rate-limit warnings, switch prompts, status-line usage, and usage-limit prompt state instead of always using the legacy
codexbucket. That keeps exhausted/high usage in one bucket from driving UI/error behavior for models metered against another bucket.It does not hardcode Spark/codex_bengalfox; production behavior is driven by optional model metadata and falls back to
codexonly when no metered bucket metadata is available.Tests run:
cargo test -p codex-tui spark --testscargo test -p codex-protocol model_preset_preserves_availability_nuxcargo test -p codex-app-server model_list --testscargo test -p codex-api rate_limitcargo test -p codex-api models_client_hits_models_endpointgit diff --checketraut-openai commentedon May 20, 2026
I think this is explained by the fact that non-spark models are used for compaction.