Python client for ThrottleKit — distributed rate limiting via gRPC or direct Redis.
Project description
throttlekit (Python)
Beyond rate limiting — from Python. Govern rate, concurrency, and cost, provably. This is ThrottleKit's Python client, and it re-implements nothing: every decision comes from the one Node core and its two engines — GALE (provable distributed leasing, a fleet-size-independent overshoot bound machine-checked in TLA⁺) and TALE (token-budget escrow — meter what your LLM spends as it streams) — bit-identical to the Node oracle, through either of two pluggable backends:
| Backend | Path | Decision computed in | Use it when |
|---|---|---|---|
ServiceBackend |
gRPC → throttlekit-server |
the service (= the core) | you want the full surface (check/check_many/peek/forecast) and to never touch the raw wire |
RedisBackend |
vendored Lua → the same Redis a Node fleet uses | Lua-in-Redis (the core's own script) | you already run Redis and want one hop, no extra service — check only |
Each door has an asyncio twin — AsyncServiceBackend and AsyncRedisBackend — and there are
batteries-included FastAPI / Starlette / Django / Flask integrations under throttlekit.contrib
(see below).
Status: experimental (alpha). The contract (
throttlekit.proto, the golden vectors, and the extracted Lua) is vendored and checksum-pinned from the frozenthrottlekit1.0 core; this client tracks it. The raw Lua wire is not a frozen contract yet (it shipsfrozen: false), so theRedisBackendis explicitly experimental and may change with the core's scripts.
🌐 throttlekit.in · 📖 Full guide: the wiki — Getting Started · The axes · Conformance & development.
The one invariant
The whole ThrottleKit design rests on it: exactly one thing computes a Decision — the Node core,
directly or as Lua-in-Redis. Neither backend re-implements an algorithm, so there is no second rate
limiter to keep in sync and no float-determinism risk. The RedisBackend marshals ARGV, runs the
core's vendored script, and decodes the reply; the decision is produced server-side, in Lua.
Why reach for it (it's not a thin client)
You're not reaching a re-implemented toy — you're reaching the one core whose distributed behavior is proven. Every decision this client returns carries the guarantees the Node core is built on:
- A machine-checked (TLA⁺), fleet-size-independent overshoot bound — window-coupled two-tier leasing admits ≤ the limit no matter how many instances. Most rate limiters can't state a bound at all.
- GALE (provable distributed leasing) and TALE (token-budget escrow for LLM gateways) ship as real
features — and they're reachable from Python: leased two-tier
check, the LLM cost axis viadebit, weighted-fair escrow, and unified rate × concurrency × cost viaadmit. - Bit-identical decisions: the
RedisBackendreplays the core's full golden vectors through real Redis and matches the Node oracle field-for-field — so a Python and a Node client on one limit never drift.
A Python service gets the same proven core a Node fleet does, not a second rate limiter to keep in sync. The guarantees — how they work — are what make this worth reaching for from any language.
Install
Installed as throttlekit-py, imported as throttlekit (PyPI's throttlekit is an unrelated
project):
pip install throttlekit-py # the gRPC ServiceBackend
pip install "throttlekit-py[redis]" # + a redis client for the direct RedisBackend
Use — the service door
from throttlekit import ServiceBackend
with ServiceBackend("localhost:50051") as rl:
d = rl.check("api", api_key)
if not d.allowed:
... # 429 — retry after d.retry_after_ms
check / check_many / peek / forecast return frozen Decision / Forecast dataclasses;
debit(policy, key, tokens) meters a windowed token budget (the cost axis — debit the actual tokens a
stream produces, e.g. for an LLM gateway). A denial is a normal Decision (allowed is False), never an
exception; gRPC faults map to PolicyNotFoundError / OperationNotSupportedError / ServiceUnavailableError.
admit(policy, key) reaches the concurrency axis (and unified rate × concurrency): it holds an
in-flight slot for the duration of the work and returns an Admission context manager that releases it on
exit — dropped=True if the block raised, so the adaptive limit contracts on an overload. The server
reclaims an abandoned slot if a client crashes; for a hold longer than the lease TTL, pass heartbeat=True
to renew it from a background thread.
with rl.admit("checkout", user_id) as adm: # holds a concurrency slot
if not adm.allowed:
return 429 # adm.binding_axis says which axis bound it
do_work() # released on exit (dropped=True if this raises)
Use — the direct Redis door
Configure a strategy and point it at the Redis your fleet shares. check is the whole surface (it is
the contract-vectored, Lua-computed decision); peek / forecast deliberately stay on the service
door, where the core — not a re-derived client port — computes them.
import redis
from throttlekit import RedisBackend, Gcra
client = redis.Redis.from_url("redis://localhost:6379")
api = RedisBackend(client, Gcra(limit=100, period_ms=60_000, burst=20), prefix="prod")
d = api.check(api_key) # now defaults to the Redis server clock (skew-free across a fleet)
if not d.allowed:
... # 429 — retry after d.retry_after_ms
Strategies: Gcra, TokenBucket, FixedWindow, SlidingWindow, SlidingWindowLog. The prefix
joins as f"{prefix}:{key}" — the same key scheme the core uses, so a Python and a Node client on
one limit address the same Redis key. The backend is client-agnostic: pass any object with evalsha /
eval (redis-py satisfies it structurally), exactly as the Node RedisStore does.
Use — async (asyncio)
Both doors have asyncio twins with the identical surface and the same one-oracle guarantee (they
await the transport; they never re-derive a decision). Neither is imported by import throttlekit
— they load lazily, so the synchronous client stays free of grpc.aio / redis.asyncio.
from throttlekit import AsyncServiceBackend
async with AsyncServiceBackend("localhost:50051") as rl:
d = await rl.check("api", api_key)
if not d.allowed:
... # 429 — retry after d.retry_after_ms
adm = await rl.admit("checkout", user_id) # the concurrency axis
async with adm:
if not adm.allowed:
return 429
await do_work() # released on exit (dropped=True if this raises)
import redis.asyncio as redis
from throttlekit import AsyncRedisBackend, Gcra
client = redis.Redis.from_url("redis://localhost:6379")
api = AsyncRedisBackend(client, Gcra(limit=100, period_ms=60_000, burst=20), prefix="prod")
d = await api.check(api_key)
Framework integrations (throttlekit.contrib)
Batteries-included adapters for the common Python web stacks. Install the matching extra and import the
one you use (nothing here is pulled in by import throttlekit):
pip install "throttlekit-py[fastapi]" # or [starlette] / [django] / [flask] / [all]
bind_policy(backend, "api") turns a service backend into a uniform key → Decision checker (a
RedisBackend.check bound method already is one). A denial returns 429 with Retry-After /
RateLimit-* headers (choose IETF or legacy X-RateLimit-* with style=); the admitted path stamps the
same RateLimit-* headers on the response (for the FastAPI dependency, when your endpoint returns its
own Response object FastAPI keeps it verbatim — reach for ThrottleKitMiddleware if you need
unconditional stamping there). Adapters fail open by default if the backend is unreachable
(on_unavailable="allow") and key on the raw connecting peer (never a forgeable X-Forwarded-For).
# FastAPI — a per-route dependency (or app.add_middleware(ThrottleKitMiddleware, ...) for global limiting)
from fastapi import FastAPI, Depends
from throttlekit import ServiceBackend, bind_policy
from throttlekit.contrib.fastapi import RateLimit
app, backend = FastAPI(), ServiceBackend("localhost:50051")
@app.get("/items", dependencies=[Depends(RateLimit(bind_policy(backend, "api")))])
async def items(): ...
# Flask — an extension + @tk.limit() decorator
from throttlekit.contrib.flask import ThrottleKit
tk = ThrottleKit(app, checker=bind_policy(backend, "api"))
@app.get("/")
@tk.limit()
def index(): ...
# Django — a view decorator (+ ThrottleKitMiddleware to render denials as 429)
from throttlekit.contrib.django import rate_limit
@rate_limit(bind_policy(backend, "api"))
def my_view(request): ...
Prefer to wire it yourself? Use the framework-agnostic @rate_limit decorator on any sync or async
function, and decision_headers(decision) to render the headers.
How this stays in lock-step with the core
scripts/sync_contract.py vendors, with checksums, from the core repo:
contract/— the dev/test artifacts:throttlekit.proto(→ gRPC stubs) andgolden-vectors.json.src/throttlekit/_scripts/— the runtime Lua theRedisBackendexecutes (shipped in the wheel), with the core'smanifest.json(which carries each script's sha256).
tests/test_contract.py is the drift-gate (the vendored bytes must match their checksums and the
pinned contractVersion). But the real proof is behavioral:
tests/test_redis_backend.pyreplays every rate-limit golden vector — the full, time-parametrized timeline — through the Python client → vendored Lua → real Redis, and asserts every reply field equals the Node oracle bit-for-bit. (Because the direct path puts an explicitnowin ARGV, it can do the rigorous time-parametrized replay the cross-process service door can't.)tests/test_service_backend.pystarts a realthrottlekit-serverand asserts the clock-independent behavior over gRPC.
Beyond unit conformance, a cross-repo battle test in the core repo drives every axis through both
backends against a real Redis-backed 3-server fleet — distributed cap exactness, the windowCoupled
overshoot bound, crash-reclaim, heartbeat, and one-oracle/two-door state sharing:
research/polyglot/battle-test.
Develop
pip install -e .[dev]
python scripts/sync_contract.py # vendor proto + vectors + Lua from ../GreenfeildProject (the core)
python scripts/gen_proto.py # generate the gRPC stubs from the vendored proto
pytest # unit + contract; the Redis/service tests skip if their backend is absent
ruff check . && mypy # lint + types
The RedisBackend conformance needs a reachable Redis: it uses THROTTLEKIT_REDIS_URL or the project
default redis://localhost:6380, and skips cleanly when neither is up.
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file throttlekit_py-0.4.0.tar.gz.
File metadata
- Download URL: throttlekit_py-0.4.0.tar.gz
- Upload date:
- Size: 56.9 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.1.0 CPython/3.13.12
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
4e64541f41f4dc2a9cc1fcc1944a13981b52cf42b2fbec9907e6ab372af1c9ea
|
|
| MD5 |
fc1a34000059b30431534cce67ba39f3
|
|
| BLAKE2b-256 |
4e0400e59473e5ea281f14c3474b6d979d74d681675051536a89c886f4f22e78
|
File details
Details for the file throttlekit_py-0.4.0-py3-none-any.whl.
File metadata
- Download URL: throttlekit_py-0.4.0-py3-none-any.whl
- Upload date:
- Size: 49.6 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.1.0 CPython/3.13.12
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
cba9d7af9785f5b9d9c60222984a862f476c1a499b2c119f00b3e4d139869bdb
|
|
| MD5 |
81af7b7622363ecfac181d6cb44bc04b
|
|
| BLAKE2b-256 |
507d1afe7c4a23762ee83b7d24b543bd11cd8bc1afdeb77bc660c5e9f2f54ca3
|