See the queue time Pro saved you
On Pro the overview shows how long the same jobs would have waited behind the free plan's single slot this billing period, instead of carrying the wait from before you upgraded.
The Time in Queue cell summed the last 30 days for every plan. A workspace that upgraded in the morning still read an hour of queue from its free weeks, under a plan that had not queued a single job since. The number was right and said the wrong thing.
- Queue Time Saved on Pro. The third cell of the second metric row now says how long your jobs would have waited behind the free plan’s single slot, and did not. Beside it, how many jobs that is, for example
62 jobs skipped the queue. It covers your current billing period, the same window as the spend and job count beside it, so an upgrade starts from zero. - Measured, not estimated. When a job ends, its workspace’s finished jobs are replayed through one slot in the order you submitted them, each holding the slot from dispatch to the end of its run. The replay reads the stamps every job already carries, so the figure is a floor: it leaves out the dispatch hop a queued job also pays, and counts a job only when its saving passes the same 10-second floor Time in Queue uses.
- Free is unchanged. Time in Queue over the last 30 days, with the upgrade one click away. Plans are on the pricing page.
A job is folded in once it ends, so the cell catches up with a burst as its last job finishes. Jobs from before this release are folded from the start of the current billing period.
For code, GET /billing/state carries the figure as usage.slotWaitSavedMs and the job count as usage.slotWaitSavedJobs, both always 0 on the free plan. On Pro, usage.slotWaitMs and usage.slotWaitJobs now cover the billing period. The fields are additive, nothing else in the response changed.