Insane usage burn rate swing on Pro 20x, potential bug

There is a useful official Support update from another usage thread that helps define the next diagnostic package, although it still does not explain the accounting.

In 1394437/4, @OpenAI_Support says Codex usage can vary depending on the model, context, task and tools, and asks affected users to provide the approximate upgrade time, model, relevant task/session IDs and usage screenshots:

That is not a reconciliation of the sharp workload-vs-allowance change reported here. In particular, it does not tell us the normalized accounting unit, when usage is posted, or whether a later adjustment occurred.

The same closed thread also contains one user saying their usage was corrected back to 81%. That shows adjustments can occur, but it does not establish why the original deduction happened.

The cleanest next specimen would therefore be one bounded task with:

  • native 5h + weekly allowance snapshot immediately before;
  • exact model / effort / Fast or priority-routing state;
  • task/session ID and start/end timestamps;
  • corresponding request/token/workload log;
  • allowance snapshot immediately after;
  • another snapshot several minutes later to catch delayed reconciliation;
  • any later refund/adjustment.

That would let us distinguish “this task was weighted differently” from “the meter posted late” from “the accounting was corrected later.” Until then I would still avoid treating the visible percentage bar as a literal token meter or calling the observed ratio a billing multiplier.