Prove the batch fits before you start it

Some free tiers have a strange, exploitable shape: a painfully low rate ceiling paired with a huge monthly token budget (Mistral's free Experiment tier, as of 2026-06: about 2 requests/minute but around a billion tokens/month). Useless for anything live; ideal for a patient overnight grind. The failure mode is starting the job unsized and finding it stalled, or 12% done, in the morning. Your job is the arithmetic, up front.

Steps

1. Count the backlog: how many items, and a realistic est_tokens_per_item (input + output; when unsure, run 3 samples and measure rather than guessing).
2. Look up the tier's actual limits (the rate ceiling in requests/minute and any monthly token budget) from the provider's current docs, not from memory or this file.
3. Compute two numbers and show both:
   • Budget fit: items x tokens/item vs. the monthly budget. Over budget means shrink the job or split it across months.
   • ETA: items / (rpm x 60) hours at the ceiling. This tells the user whether "overnight" is 8 hours or 3 days; both are fine, but only if known in advance.
4. Run the proof below; it fails on a job that doesn't fit its budget.
5. Only then queue it, with a runner that actually paces to the rate limit (bursting past it gets throttled or banned, which destroys the ETA you just computed).

Prove it