Blog / Cost / FIG. 64
Jev Rate Limits: What's Known, and How to Build So They Don't Matter
Jev's rate limits live in TypeSafe's docs and change at launch speed. The architecture that makes any limit survivable: queues, caches, batches, backoff.
The numbers themselves: docs.typesafe.ai, full stop. Launch-period limits change without ceremony, third-party snapshots rot, and this site's standing policy is to never publish figures that expire. What doesn't expire is the architecture that makes whatever the limits are this month a non-event, and that's this page.
Four patterns, all detailed in the production guide, assembled here for the person who just hit a 429. Client-side queues with exponential backoff: your pipeline's send rate is a policy you control, not a hope; burst absorption belongs in your queue, not in retry storms that make throttling worse. Cache like identity is stable, because it is: exact-match first, semantic second, keys versioned with question text, and suddenly repeat inputs cost zero quota. Batch the offline: labeling runs, eval suites, and backfills are batch jobs with checkpoints, run off the live path at whatever pace limits allow, never a for-loop hammering production quota. Escalate on confidence, not on capacity: if throttling pushes you toward skipping verdicts, your fallback policy (queue-and-wait, degrade-to-rules, route-to-human) should decide what gives, deliberately, per pipeline, before the first outage decides for you.
One reframe that saves teams a support ticket: at reported per-verdict economics, most pipelines that hit limits are hitting them with waste, duplicate judgments, un-cached repeats, retry loops, questions asked per-query that should be materialized as columns. Audit for those before asking for a raise; the limit was usually protecting you from your own bug.
Frequently asked questions
What are Jev's current rate limits?
Whatever the official docs say today; we deliberately don't publish expiring numbers. The architecture above holds at any figure.
I keep getting throttled. First move?
Check for retry storms and un-cached duplicates (the usual culprits), add backoff and a queue, move batch work off the live path, then and only then pursue higher tiers via TypeSafe.
Do limits make Jev unfit for real-time products?
The game builds sustaining ~10 decisions/second suggest generous ceilings in practice, but real-time products should still design the degrade path; frame budgets deserve fallbacks regardless of vendor.
Numbers throughout are as reported by the build authors, not verified by shipwithjev. Code-shaped examples are pseudocode; the official docs live at docs.typesafe.ai.