Bug: GPT-5.3-Codex-Spark usage incorrectly drains regular Codex limits

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:

1. regular Codex bucket: limit_id=codex
2. 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.9 in relevant session metadata
• Date observed: 2026-05-17