sipi.bot integration
sipi.bot + OpenAI API
Integrate sipi.bot with the OpenAI API. Wrap the OpenAI SDK with a 5ms policy check that caps per-request token cost, daily spend ceilings, and function-call transaction limits.
Four ways an OpenAI bill grows
Token pricing is only the first of them, and on an agent workload it is rarely the one that surprises you.
- Context accumulation. Every turn of a tool-calling loop re-sends the conversation so far. Cost climbs faster than turn count.
- Sampling multipliers. Asking for several completions multiplies output tokens by the number you asked for. It is one parameter and it is easy to leave turned up after an experiment.
- Retry storms. A rate limit or a timeout triggers a retry; a retry that also fails triggers another. Naive backoff turns one failure into a burst of billed attempts.
- Server-side conversation state. When the provider keeps the thread for you, the context still grows — you just stop seeing it grow in your own code.
Each of these produces a different signature, which is why one rule type is not enough to cover them.
Putting the check in front of the SDK
Wrap the completion call. Price the worst case from your token ceiling, submit it, and respect the decision.
import requests
from openai import OpenAI
client = OpenAI()
def guarded_completion(**kw):
d = requests.post(
"https://sipi.bot/v1/transactions/evaluate",
headers={"Authorization": f"Bearer {SIPI_KEY}"},
json={"amount": estimate_usd(**kw), "merchant": "openai",
"category": "llm", "description": kw["model"]},
timeout=5,
).json()
if d["decision"] == "BLOCKED":
raise RuntimeError(d["reason"])
if d["decision"] == "FLAGGED":
await_human_approval(d["transaction_id"])
return client.chat.completions.create(**kw)Note that FLAGGED is not a failure. It is the decision that lets you
keep a tight ceiling without killing legitimate expensive work — the agent pauses,
a human looks, the task continues.
Matching rules to failure modes
| Rule type | What it does on this integration |
|---|---|
velocity | The retry-storm control. A burst of attempts in a short window is a shape that per-call limits cannot see. |
daily_total | The backstop for context accumulation, where every individual call is defensible and the total is not. |
per_transaction | Catches an oversized request — a long context, a raised token ceiling, or a sampling multiplier left turned up. |
category_limit | Separates model spend from the other things an OpenAI-based agent buys, so one budget cannot quietly eat the other. |
Batch work deserves a different policy
An asynchronous batch job is legitimately large and legitimately slow. Under a policy tuned for interactive use it looks exactly like a runaway. Give batch work its own agent identity and its own ceiling rather than loosening the interactive policy until the batch fits through it — that is how a temporary exception becomes a permanent hole.
The same reasoning applies to evaluation runs. They are bursty, expensive and expected. Separate identity, separate budget, no exceptions carved into the policy that guards production.
Limits worth knowing
- The firewall prices what you tell it, not what OpenAI later charges. Submit the real usage figures afterwards so the daily total reflects reality.
- It cannot see tokens spent through a different key, a different SDK, or a teammate's script.
- It does not deduplicate a retried request. If you retry, either reuse the decision or record the retry deliberately — do not let the same logical call consume budget twice by accident.
Common questions
Isn't a spend cap in the provider dashboard enough?
A provider cap is account-wide and it acts after the fact — it tells you the month is over, not that this call should not happen. It also cannot distinguish your runaway agent from your production traffic. Use both: the dashboard cap is a backstop, the pre-call check is the control.
Does it work with streaming?
Yes, because the check runs before the stream opens. Once tokens are flowing you cannot un-bill them, so the decision has to happen first.