At what levels should rate limiting be applied? How do you determine specific limit values for each level?
Rate limiting needs to be simultaneously designed at three levels, forming layered protection:
LLM API call level (prevent Token cost explosion): Limit maximum LLM calls per Agent task cycle (typically 5-15; exceeding this indicates possible infinite loop); limit LLM calls per hour (based on your LLM API plan and budget); limit maximum Token count per single call (abnormally long input Prompts also need limits to prevent unexpected Context costs).
Tool call level (prevent external API excessive requests):
Set rate limits on each tool function, e.g., get_aave_apy maximum 10 calls per minute (exceeding indicates anomalous retries); rate limits on write tools (on-chain operations) are stricter — e.g., withdraw_from_protocol maximum 3 times per hour.
On-chain operations level (most important, directly affects fund security): Maximum daily transaction count (e.g., 10 on-chain transactions per day); maximum daily Gas consumption (in ETH or USD); maximum daily operation amount (e.g., USDC moved daily not exceeding 30% of total position); maximum single operation amount (absolute amount limit per transaction).
Rate limit value setting method: Run on testnet for 48-72 hours, record peak values for each metric under normal operations, set production rate limits at 1.5-2× peaks (leaving some room for normal fluctuations but not allowing anomalously large exceedances).
How should circuit breaker trigger conditions be designed? What should the Agent do after triggering a circuit breaker?
Circuit breaker trigger condition design must cover four types of anomalous scenarios:
Type 1: Cost circuit breakers (protect budget)
Type 2: Security circuit breakers (detect attack signals)
Type 3: Tool failure circuit breakers (prevent continuing operations during service outages)
Type 4: Market anomaly circuit breakers (prevent execution under extreme market conditions)
Agent behavior after circuit breaker triggers: Automatically stop all new tool calls; log complete circuit breaker records (trigger reason, trigger time, current state); send P0 alert via Telegram (with circuit breaker reason); await human confirmation (no auto-recovery). Note: circuit breaking isn't 'shutdown' but 'pause and wait for confirmation' — Agent state (current positions, last task progress) should be completely preserved, allowing continuation from the pause point after human confirmation rather than restarting.
How is rate limiting implemented in Python code? Are there ready-made libraries available?
There are several ways to implement Agent rate limiting in Python, from simplest to most complete:
Method 1: Using the ratelimit library (simplest, suitable for function-level rate limiting)
from ratelimit import limits, sleep_and_retry → @sleep_and_retry → @limits(calls=10, period=60) → def get_aave_apy(): ...
This limits get_aave_apy to at most 10 calls per 60 seconds; calls beyond the limit automatically wait rather than error. The sleep_and_retry decorator makes rate-limited calls automatically wait until the next window rather than throwing exceptions.
Method 2: Redis + sliding window counter (suitable for distributed scenarios) If your Agent runs on multiple instances (multiple Sub-agents sharing rate limits), use Redis to maintain a global rate counter: before each call, increment counter in Redis with expiry set to the rate window; if counter has reached limit, wait and retry. This lets multiple Sub-agents' call counts share a global limit, avoiding the case where individual Sub-agent behavior is normal but combined total exceeds limits.
Method 3: PostgreSQL counter table (best for Onchain Agent persistent rate limiting)
Maintain an agent_rate_counters table in PostgreSQL recording today's execution count for each operation type. Before each execution, query (does today's Gas consumption exceed budget? Does today's on-chain transaction count hit the limit?); after query passes, execute and update counts. This keeps rate limits effective after Agent restarts (Redis may reset after restarts; PostgreSQL is persistent), especially suitable for 'daily operation limit' type rate limits.
Circuit breaker Python implementation:
Use the pybreaker library (open source, dedicated Circuit Breaker implementation) or manually maintain a circuit_state variable (CLOSED/OPEN/HALF-OPEN), checking circuit_state before each tool call and rejecting all operations when in OPEN state.
A complete rate limiting + circuit breaker design example
Below is a rate limiting and circuit breaker design for a DeFi yield optimization Agent (Python pseudocode style):
# Rate limit configuration
RATE_LIMITS = {
'llm_calls_per_cycle': 10, # max 10 LLM calls per task cycle
'apy_queries_per_min': 5, # max 5 APY queries per minute
'write_ops_per_hour': 3, # max 3 on-chain writes per hour
'daily_gas_budget_usd': 20, # daily Gas budget $20
'daily_tx_count': 8 # max 8 on-chain transactions per day
}
# Circuit breaker trigger conditions
CIRCUIT_BREAKERS = {
'gas_exceeded_200pct': True, # daily Gas exceeds 200% → immediate break
'blocked_3x_30min': True, # 3 BLOCKED within 30 minutes → immediate break
'tvl_drop_20pct_1hr': True, # protocol TVL drops 20% in 1 hour → break
'tool_fail_5x': True # critical tool fails 5× consecutively → break
}
# Pre-execution check flow before each tool call (code-level enforcement, not dependent on LLM)
def pre_execute_check(operation_type: str) -> bool:
check_rate_limit(operation_type) # rate limiting
check_circuit_breaker() # circuit breaker state
check_daily_budget() # daily budget
return True # execute only after passing all checks
Key of this design: pre_execute_check() executes at the outermost layer of tool call functions, cannot be bypassed by LLM Thought reasoning — even if the LLM hallucinates or is attacked by Prompt Injection, the code-level rate limiting and circuit breaker checks remain effective.
Stricter rate limits (lower ceilings) → safer Agent (smaller impact range when anomalous), but during Gas fee troughs or high-yield opportunity windows, the Agent may miss optimal execution timing by reaching rate ceilings (reduced strategy efficiency). More lenient rate limits (higher ceilings) → higher strategy execution efficiency, but larger potential impact when anomalous. Recommendation: strict in early production (protect principal); after confirming stable Agent behavior, moderately loosen based on actual data. Circuit breaker trigger thresholds work the same way: too sensitive (frequent false triggers) causes Agent to frequently pause, affecting strategy efficiency; too insensitive (threshold too high) loses protective effect. Recalibrate once monthly based on operational data.