Rate limiting and budget controls in Agentic AI - Model Metrics & Evaluation

Metrics & Evaluation - Rate limiting and budget controls

Which metric matters for Rate limiting and budget controls and WHY

In rate limiting and budget controls, the key metrics are throughput (how many requests or actions happen per time unit), latency (how fast each request is handled), and error rate (how many requests are blocked or fail due to limits). These metrics matter because they show if the system is working smoothly without overloading or overspending.

For example, if throughput is too low, users may feel slow service. If error rate is high, many requests are blocked, which can frustrate users. Budget controls ensure spending stays within limits, so cost efficiency is also important.

Confusion matrix or equivalent visualization

Rate limiting does not use a confusion matrix like classification. Instead, we can show a simple table of request outcomes:

    | Outcome           | Count |
    |-------------------|-------|
    | Allowed requests   | 950   |
    | Blocked requests   | 50    |
    | Total requests     | 1000  |
    

This shows how many requests passed or were blocked by the rate limiter.

Precision vs Recall tradeoff with concrete examples

In rate limiting, the tradeoff is between strictness and user experience. If limits are too strict (high blocking), many good requests are blocked (false positives), hurting users.

If limits are too loose, the system may overload or exceed budget (false negatives), causing slowdowns or extra costs.

Example: A video streaming service sets a limit of 1000 requests per minute. If set too low, many users get blocked (high error rate). If too high, servers get overloaded and cost rises.

What "good" vs "bad" metric values look like for this use case

Good:

• Allowed requests close to total requests (e.g., 95% or more)
• Low error rate (blocked requests under 5%)
• Latency within acceptable limits (e.g., under 200 ms)
• Budget usage within planned limits

Bad:

• High blocked requests (over 20%) causing user frustration
• Latency spikes due to overload
• Budget overspending due to poor control
• System crashes or slowdowns from too many requests

Metrics pitfalls

• Ignoring user impact: Focusing only on budget can block too many users.
• Overfitting limits: Setting limits based on short-term spikes can cause unnecessary blocking.
• Data leakage: Not accounting for all request sources can mislead metrics.
• Accuracy paradox: High allowed requests but poor user experience due to latency or errors.

Self-check question

Your system allows 98% of requests but blocks 2%. However, users report slow responses and occasional crashes. Is your rate limiting good? Why or why not?

Answer: Not necessarily good. Even with 98% allowed requests, slow responses and crashes show the system is overloaded or limits are not well balanced. You need to check latency and error rates, not just allowed percentage.

Key Result

Key metrics for rate limiting are throughput, latency, error rate, and budget usage to balance user experience and cost.

Practice

1. What is the main purpose of rate limiting in an AI system?

easy

A. To control how often users can make requests

B. To increase the speed of AI responses

C. To improve the accuracy of AI predictions

D. To store more user data for training

Solution

1. Step 1: Understand rate limiting concept

   Rate limiting is about controlling the number of requests a user can make in a time period.

2. Step 2: Identify the main purpose

   This control helps prevent overload and keeps the system fair for all users.

3. Final Answer:

   To control how often users can make requests -> Option A

4. Quick Check:

   Rate limiting = control request frequency [OK]

Hint: Rate limiting means limiting request frequency [OK]

Common Mistakes:

• Confusing rate limiting with improving AI accuracy
• Thinking rate limiting increases speed
• Mixing rate limiting with data storage

2. Which of the following is the correct way to set a budget control in an AI usage system?

easy

A. budget = max(1000)

B. limit_budget = 'max 1000 dollars'

C. setBudget(1000 dollars)

D. budget_limit = 1000 # sets max money allowed

Solution

1. Step 1: Identify correct syntax for budget control

   Setting a budget limit usually involves assigning a numeric value to a variable representing money allowed.

2. Step 2: Check each option

   budget_limit = 1000 # sets max money allowed uses a clear assignment with a comment, which is correct syntax. Others use invalid syntax or unclear expressions.

3. Final Answer:

   budget_limit = 1000 # sets max money allowed -> Option D

4. Quick Check:

   Assign numeric budget limit = correct [OK]

Hint: Budget control is a numeric variable assignment [OK]

Common Mistakes:

• Using strings instead of numbers for budget
• Calling undefined functions like setBudget
• Using incorrect syntax like max(1000)

3. Given this code snippet controlling requests per minute:

requests = [1,1,1,1,1,1]
limit = 5
allowed = sum(requests[:limit])
print(allowed)

What will be the printed output?

medium

A. 1

B. 6

C. 5

D. Error

Solution

1. Step 1: Understand the code slicing and summing

   The code sums the first 5 elements of the list requests, each element is 1.

2. Step 2: Calculate the sum of first 5 elements

   Sum = 1+1+1+1+1 = 5

3. Final Answer:

   5 -> Option C

4. Quick Check:

   Sum first 5 ones = 5 [OK]

Hint: Sum first 5 elements of ones list = 5 [OK]

Common Mistakes:

• Summing all 6 elements instead of 5
• Confusing slicing syntax
• Expecting an error due to slicing

4. Find the error in this rate limiting code snippet:

max_requests = 10
requests_made = 0
if requests_made > max_requests:
    print("Limit reached")
else:
    requests_made += 1
    print("Request allowed")

medium

A. No error, code is correct

B. The condition should be >= instead of >

C. The print statements are reversed

D. requests_made should start at 1

Solution

1. Step 1: Analyze the condition for rate limiting

   The code blocks requests if requests_made is greater than max_requests, but it should block when equal too.

2. Step 2: Correct the condition

   Change > to >= to include the max_requests limit properly.

3. Final Answer:

   The condition should be >= instead of > -> Option B

4. Quick Check:

   Use >= to block at limit [OK]

Hint: Use >= to block requests at limit [OK]

Common Mistakes:

• Using > misses blocking at exact limit
• Starting requests_made at 1 is unnecessary
• Swapping print messages confuses logic

5. You want to limit AI usage to 1000 requests per day and a budget of $500. Which approach correctly combines rate limiting and budget control?

hard

A. Set daily_limit = 1000 and budget_limit = 500; check both before allowing requests

B. Set daily_limit = 1000; budget_limit is not needed if rate limiting is set

C. Only set budget_limit = 500; rate limiting is handled automatically

D. Set budget_limit = 1000 and daily_limit = 500; swap values for safety

Solution

1. Step 1: Understand the need for both controls

   Rate limiting controls request count; budget controls money spent. Both must be checked.

2. Step 2: Evaluate options for combining controls

   Set daily_limit = 1000 and budget_limit = 500; check both before allowing requests correctly sets both limits and checks them before allowing requests. Others ignore one control or swap values incorrectly.

3. Final Answer:

   Set daily_limit = 1000 and budget_limit = 500; check both before allowing requests -> Option A

4. Quick Check:

   Use both limits together for control [OK]

Hint: Always check both request count and budget before allowing [OK]

Common Mistakes:

• Ignoring budget when rate limiting is set
• Assuming budget controls requests automatically
• Swapping limit values causing confusion