I keep seeing this in agent-written PRs.
The API started returning 429. Clients were getting throttled. The agent “fixed” it. Traffic flows again. Then you open the diff and the bug is still there. The real change is an open firehose: rate limit raised to something huge, the middleware deleted, Redis/token-bucket stubbed out, or the check wrapped in if false. Green because nothing gets rejected anymore.
You did not ask for unlimited traffic. You asked why legitimate clients were hitting the ceiling — bad key reuse, a missing cache, a retry storm, or a limit that was too tight for the real burst pattern.
The 60-second check I run now
When an agent PR claims to fix 429, throttling, “too many requests”, or rate-limit errors:
- Diff the “fix.” Did it keep a real limit (and maybe raise it with a reason), or did it delete / disable / stub the limiter?
- Ask what still fails under a burst from one IP or one API key. If the PR cannot name a failure mode that still rejects abuse, bounce it.
- If the only change is remove/disable/raise-to-infinity — especially with no load or abuse note — I reject it until the real cause is owned or the temporary bump is scoped, documented, and has an expiry.
This is one of the stops on a short bar I use before I merge agent PRs. Free one-pager if you want the rest: https://chopragunji.gumroad.com/l/zpnmdn
If you'd rather someone else do a hard pass on one scary AI PR, I still have founding slots at $49 (normally $99): https://chopragunji.gumroad.com/l/byoyi/FOUNDING
Have you merged an agent “rate limit fix” that was really just turn it off?
Top comments (0)