Token Reservation in Redis Replaces Per-Request Rate Limiting

On October 3, 2026, a DEV Community post argued that per-request rate limiting should be replaced with token reservation as the way to keep LLM spending under control. The reasoning is that two requests can differ enormously in cost: one may be a single-line question, while another kicks off an agent run that makes a dozen model calls, each one resending a longer context than the last. A request limit counts both as one, so it does nothing to cap the real expense.

The post points out that the obvious alternative — counting tokens after each response — does not hold up either. Concurrent requests all observe that they are under the limit before they run, so they all pass, and the limiter stops limiting anything. The rule the author proposes is therefore to limit tokens directly: reserve an estimated amount before the call, then correct that reservation once the actual usage is known.

Alongside the rule, the post lays out the questions any implementation has to answer: what exactly gets counted, at what point in the request lifecycle it is counted, and where the counter itself lives. The material does not include a reference implementation, concrete code, or results from shipping the approach in a particular product; it stays at the level of the rule and the design points it implies. As it stands, the discussion ends with the proposal and its rationale having been stated.