sipi.bot limits
Spend limits for Groq agents
Groq serves Llama inference at the fastest latency tier available, which means an agent retry loop burns tokens faster in wall-clock time than on any other provider. Native rate limits cap requests per minute — they do not cap spend per decision. Here is how to bound a Groq agent before a loop runs away.
What Groq provides natively
Groq's native controls are requests-per-minute and tokens-per-minute rate limits tied to your plan tier. These throttle throughput; they do not evaluate whether a given transaction should be allowed. Because Groq is the fastest tier in the dataset, a retry loop hits the rate limit ceiling quickly but can still accumulate significant spend within a single minute window — exactly the scenario a velocity cap is built to catch.
Why that is not enough for autonomous agents
Autonomous agents need explicit spend limits because the alternatives — trusting the agent, the provider's monthly cap, or a human reviewer on every transaction — do not actually bound the risk. Provider caps are coarse and account-level. Human review does not scale. And agents have no native concept of a budget. A pre-spend firewall gives you a concrete, enforceable ceiling evaluated on every transaction in under 5ms.
The limits that matter for a Groq agent
| Limit type | What it catches | Example |
|---|---|---|
| Per-transaction cap | A single oversized call | Block any one model/tool spend over $5 |
| Daily total | Aggregate session burn | Max $50/day across all agent spend |
| Velocity cap | Retry & runaway loops | Max 30 Groq calls/minute |
| Category limit | Tool-call cost categories | Cap "long-context" calls at $10/day |
What happens when a limit is hit
When a transaction would exceed the limit, sipi.bot returns block with a reason code identifying which limit fired. The agent receives the decision as structured JSON and can choose an alternative path — retry with smaller scope, request human approval, or abandon the task. The blocked transaction is logged with the policy version, so you can always see exactly why it was denied.
Frequently asked questions
Does Groq block spend in real time?
No. The native controls described above are quotas, rate limits, IAM scopes, or monthly budgets. They throttle or alert; they do not evaluate an individual transaction against a spend policy and block it in milliseconds before the cost is incurred. That is the gap sipi.bot fills.
What limit value should I start with?
Start with the recommended default for your agent type, observe real traffic for a week, then tune. The right limit is the smallest value that does not interrupt legitimate work. If you are blocking more than 1% of transactions in steady state, the limit is probably too tight. Pair every dollar limit with a velocity cap (transactions per minute) — dollar limits catch the single large transaction, velocity caps catch the loop.
How does sipi.bot enforce this for a Groq agent?
Your agent calls evaluate_spend before any transaction (the model call, tool call, or provisioning action). sipi.bot checks it against your per-transaction caps, daily totals, velocity limits, merchant allowlists, and category rules, then returns approve, block, or flag — in under 5ms. The Groq request only proceeds if the decision is approve.