5× more headroom on billed renders — 10,000 renders/hour
The per-caller rate limit on /api/v1/md, /api/v1/canvas and /api/v1/render goes from 2,000 to 10,000 renders per hour, because the bookkeeping behind each render no longer runs on the request.
Billed renders now have five times the headroom: POST /api/v1/md, POST /api/v1/canvas and POST /api/v1/render accept up to 10,000 renders per hour per caller (or per payer wallet on x402), up from 2,000. Nothing changes about the request — same endpoints, same bodies, same credits at 1 credit per 10 pages.
The old ceiling was never about the render itself. Every successful render also wrote an artifact — two R2 objects plus a database row so the PDF shows up in your render history — and a usage row for your account's audit trail, and both were waited on before your PDF came back. At high volume that made our own single-writer database, not Cloudflare, the thing a heavy caller would queue behind.
Those writes still happen, exactly as before — the artifact id is generated up front, so X-Artifact-Id is still returned — they just finish after your response has been sent. They are best-effort, as they always were internally: if one of those post-response writes fails, the id you were handed will not resolve. A GET /api/v1/artifacts/:id/pdf that 404s for a fresh X-Artifact-Id means the capture failed, not that the artifact aged out. The one write that stays on the request path is the credit deduction, deliberately: a render that bills must not be able to lose the bill.
The arithmetic behind the number, stated plainly: at 10,000/hour one caller sustains about 2.8 renders/second, and a render now costs two database writes on the request path — the API key's last-used stamp and the credit deduction — instead of four, because the artifact row and the usage row moved off it. That is roughly 5.6 writes/second against roughly 2.2 writes/second at the old 2,000/hour: two-and-a-half times the write load for five times the quota. Total statement volume does rise with the quota (roughly 31 statements/second against 7), but reads are not what a single-writer database serialises. We could not measure a latency win locally — the committed benchmark's p95 moves more between runs of the same build than the bookkeeping does — so this ceiling is a deliberate capacity argument, not a claim that renders got faster.
/api/v1/preview is unchanged at 200/hour. It is free and unmetered by credits, so its rate limit is the only control on it.