Goal usage accounting appears severely incorrect: 15h task reported 27h and consumed excessive quota/credits
A Codex goal run appears to have severely incorrect usage accounting. The actual wall-clock time from the goal being sent to the completed result was only about 15 hours and 10 minutes (Monday 12:19 AM to Monday 3:29 PM), but the goal result reported timeUsedSeconds=98120, which equals 27 hours 15 minutes 20 seconds, an overcount of about 12 hours 5 minutes 20 seconds. The same goal result also reported tokensUsed=27756335. Because the reported elapsed time is obviously wrong, I have serious reason to suspect that the token/usage accounting for this run may also be wrong, and that I may have been charged significantly more quota/credits than the task actually consumed. This was a 15-hour goal run on my 20x Pro plan. The first roughly one hour used Fast, then I steered the task and switched it to Standard for the remainder. Despite that, this single task consumed roughly 70% or more of my weekly limit: I started with about 25% weekly limit remaining, it was fully exhausted, then Codex automatically deducted about 1100 credits, then after I reset the weekly limit the same task continued and consumed another roughly 30% of the weekly limit before finishing. This is not a minor UI discrepancy; it directly affects paid quota/credit consumption. Please investigate whether goal runtime, token usage, weekly-limit usage, and credit deduction are being counted correctly for long-running goals, and restore/refund any incorrectly consumed weekly limit or credits if the accounting is wrong. Feedback ID: 019eca26-18b8-7442-a042-cd22d29d2984.
3 Comments
I also encountered a situation similar to this.
I'm not sure if the Pro 20x quotas have been universally reduced, but today I used the goal command and consumed 40% of my weekly limit in just 7 hours. The logs show it was 600M tokens, implying that the weekly limit is now only around 1.5B tokens, compared to 3B tokens last week. Those resets are jokes.
A goal-level usage receipt would make this much easier to audit. The fields I would expect are:
goal_id, wall-clock start/end, active model time, waiting/background/retry time, model legs, child task ids, token buckets, credit/quota bucket, and terminal accounting source.The key is separating elapsed time from billable work. If a 15h visible run reports 27h, the receipt should show whether that came from retries, resumed background work, overlapping child tasks, or a server-side reconciliation bug.
Generated with ax - https://github.com/Necmttn/ax