Coding with AI
Set cost and abuse limits for an AI feature
Control model usage with authentication, input/output caps, rate limits, budgets and degraded behaviour.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Enforce limits on the server: authenticate callers, cap request and response size, rate-limit per user and tenant, set spend alerts and hard budgets, and define what the product does when the provider is slow or unavailable. Client-side limits are user experience, not enforcement.
What this means in plain English
AI requests can vary greatly in cost. Limit input size, output size, tool calls and total running time on the server. Add per-user allowances and a global budget so one account, bug or repeated loop cannot spend everything.
Decide what users see when the provider is slow, unavailable or the budget is reached. Client-side warnings improve the experience, but server-side rules provide the actual protection.
What stops one user or loop consuming the budget?
| Per request | Input, output, tool and timeout bounds |
|---|---|
| Per identity | Rate and daily/monthly allowance |
| Global | Spend alert, hard stop and incident override |
A simple example
A coding feature allows an agent to call tools repeatedly. A bug makes it loop. The server caps total steps and time, records the failed run and stops billing instead of trusting the browser to cancel it.
What to do, step by step
1. Model worst-case cost per accepted request.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on per request: input, output, tool and timeout bounds. Write the result down so you can compare it later.
2. Choose identity-aware quotas.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Log usage without sensitive prompt leakage.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test timeout, budget exhaustion and provider failure.
Finish by checking the result against global: spend alert, hard stop and incident override. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Estimate the most expensive allowed request, not only the average demo. Multiply it by realistic daily use and set alerts before the hard limit.
Common mistakes and how to avoid them
Rate-limiting only by shared IP.
This gives a misleading or unsafe result because it leaves out per request. A better approach is to model worst-case cost per accepted request, then check the result before making the change permanent.
Allowing unbounded agent loops.
This gives a misleading or unsafe result because it leaves out per identity. A better approach is to choose identity-aware quotas, then check the result before making the change permanent.
Retrying billable failures without idempotency.
This gives a misleading or unsafe result because it leaves out global. A better approach is to log usage without sensitive prompt leakage, then check the result before making the change permanent.
Words explained
- prompt
- The request and context given to an AI system.
- rate limit
- A rule that limits how many requests somebody can make in a period of time.
Quick checklist
- Model worst-case cost per accepted request.
- Choose identity-aware quotas.
- Log usage without sensitive prompt leakage.
- Test timeout, budget exhaustion and provider failure.
Common questions
What is the simple answer?
Enforce limits on the server: authenticate callers, cap request and response size, rate-limit per user and tenant, set spend alerts and hard budgets, and define what the product does when the provider is slow or unavailable. Client-side limits are user experience, not enforcement.
What should I check first?
Start with per request: input, output, tool and timeout bounds. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Model worst-case cost per accepted request. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Rate-limiting only by shared IP. Avoiding that one mistake makes the rest of the comparison much more trustworthy.