How free monthly render credits are applied cheapest-first
See how each billing cycle's free render credits are calculated and spent across renders and AI enhancements, and what changes on the per-seat scheme.
Every billing cycle each org receives free render credits computed from its licenses: license user count × prorated usage ratio × the configured free-credits-per-license amount. These free credits are applied automatically before anything is charged, and they are applied cheapest-first: all billable items in the cycle — renders and AI enhancements (0.2 credits each) combined — are sorted by credit cost ascending, and free credits absorb them in that order; the item at the boundary receives a partial percentage discount. The charged amount for the cycle is max(0, total used credits − total free credits). Unused free credits do not roll over to the next cycle (the only carry-over is into a grace-period settlement, where unused complimentary credits from unpaid bills offset grace usage). So if a client asks why a cheap render shows a 100% discount while an expensive one is fully charged, that is the cheapest-first allocation, not an error. Free credits are recomputed from live license data, so adding licenses mid-cycle increases the pool pro rata.
Organisations that have moved to the newer per-seat scheme work differently: each seat carries its own monthly allowance, and every user's renders and AI enhancements are charged against their own seat's allowance only — there is no pooling of unused allowance between seats, and the cheapest-first ordering does not apply. Seats on a licence bought mid-cycle receive a pro-rated allowance.
When a render or AI enhancement is blocked with the error RENDER_OVERAGE_CAP_EXCEEDED, the org has a render overage cap configured and this job's chargeable portion would push the cycle's paid render credits past the cap. The check runs before firing a render and before every AI enhancement (enhance, create-and-enhance, re-enhance). Important nuances: renders fully covered by remaining free credits still go through, and 0-credit HD renders are never blocked, because the cap only counts credits that would actually be charged. Which free credits apply depends on the org's billing mode: on the newer per-seat scheme each user draws on their own seat's monthly allowance (prorated for a seat taken mid-cycle), while on the older scheme the org shares one free-credit pool. What to do: an org user with catalog manager, project manager, or accounts manager role can raise or remove the cap (self-service store setting; unsetting it means unlimited), or the client can wait for the next billing cycle, when charged usage resets to zero. On the per-seat scheme, a user who has exhausted their own seat allowance can also be moved to a seat with credits left, or given a seat if they have none. Confirm with the client whether the cap was deliberately set as a budget control before advising them to remove it — many orgs set it precisely to stop surprise overage bills.