Illustrative example. This is not a recorded run. It shows what each stage produces for a realistic sample problem, so you can see the flow without spending tokens. A real recorded run is in the repo under examples/rate-limiter-run.
Add rate limiting to our public REST API. About 50k users, a two person team, Node and Postgres. It must never lock out paying customers.
Probability is how likely a typical expert would suggest it. At least a third must be long shots (under 20%), so the field isn't eight versions of the obvious answer.
T3 failed by 5 of 8. A test most builds fail gets reviewed against the brief. Verdict: valid, kept. B and C fail a HARD test and are out.
Plan-tiered quotas, enforced by a Redis token bucket per API key, with soft limits for paid plans. Paid keys get warning headers at 80% and a 24 hour grace period before any 429. Free keys are hard-limited.
Cache the three hot read endpoints first. This removes about 60% of load before any limiting runs.
graft from GRedis token bucket per API key, sized by plan.
graft from ACostly endpoints spend 5 tokens instead of 1.
graft from HSoft limits for paid plans: X-RateLimit-Remaining header, an email at 80%, grace before 429.
champion EEmergency load shedding for the free tier only, when p95 latency passes 800 ms.
graft from FIf Redis goes down, every request fails the limit check and paying customers get 429s.
Fixed: fail open for paid keys, fail closed for free keys, alert on Redis errors.
5 spec tests pass, plus 3 regression tests added from upheld attacks and the deciding distinguishing input.
8 / 8 passing
tokens than a full arena-skill run, and about 4× fewer than its quick mode, for a standard Tournament Forge run.
| Feature | Tournament Forge | arena-skill | llm-council | agent-review-panel |
|---|
✓ yes · ✗ no · ~ partly · ? not stated in the project's README (it may still do it)