sipi.bot vs Portkey
sipi.bot vs Portkey
An honest comparison of the two products in this list that both use the word guardrails. Portkey is an AI gateway with request-time guardrails — prompt conditioning, response validation, routing. sipi.bot is a pre-spend firewall — it governs whether your autonomous agent is allowed to spend money at all. Closest cousin, different core job.
Quick comparison
| Dimension | Portkey | sipi.bot |
|---|---|---|
| What it is | AI gateway with request-time guardrails | Pre-spend firewall for autonomous AI agents |
| Core job | Route LLM calls + guard prompts and responses | Approve / block / flag spend before money moves |
| What it guards | What the LLM says (prompt injection, PII, toxicity) | What the agent spends (dollars, merchants, transactions) |
| Decision timing | Request-time (on the LLM call) | Pre-spend (<5ms, before any transaction) |
| Per-transaction dollar caps | No (token/request focused) | Yes (native) |
| Velocity / runaway-loop kill | No | Yes |
| Merchant allowlist | No | Yes |
| Human approval queue for spend | No | Yes (FLAG path) |
| Prompt guardrails (injection, PII, output filtering) | Yes (core feature) | No (not the job) |
| Multi-provider routing | Yes | No (composes with Portkey / LiteLLM) |
| Pricing | Free / Pro / Enterprise | $99/$499/mo, OSS core free |
What Portkey does well
Portkey is a serious AI gateway. If you are running production LLM workloads and need prompt-level safety — stopping prompt injection, redacting PII, filtering toxic outputs, enforcing response format — Portkey is built for it. Its strengths:
- Request-time guardrails — condition prompts and filter responses before they reach the user.
- Prompt injection defense — detect and block adversarial prompts.
- PII redaction — strip sensitive data from prompts and responses.
- Multi-provider routing — gateway across OpenAI, Anthropic, Google, and others.
- Response caching and fallback — reliability and cost optimization on LLM calls.
- Observability — request logs, latency, and prompt analytics.
Where sipi.bot wins
Portkey guards the LLM call. sipi.bot guards the wallet. The gap matters when your agent is autonomous and can trigger real payments — a prompt guardrail does not stop a runaway retry loop from draining your card, and a response filter does not block an unknown merchant. sipi.bot's strengths:
- Pre-spend enforcement — every transaction evaluated and returned APPROVED, BLOCKED, or FLAGGED before it fires.
- Per-transaction dollar caps — cap each spend, not just total tokens.
- Velocity limits — kill runaway retry loops on the second repeat.
- Merchant allowlist — block unknown vendors by default.
- Category limits — cap compute differently from advertising, advertising differently from data enrichment.
- Human-in-the-loop approval queue — large or ambiguous spend is FLAGGED for a human before it completes.
- Tamper-evident audit log — every spend decision, immutable, compliance-grade.
- Native MCP surface — Claude Code, Cursor, Hermes call it directly.
Where Portkey falls short for agent spend control
Portkey is an LLM gateway, not a payment governance layer:
- Token-centric, not transaction-centric. Portkey thinks in prompts and tokens. It does not have a concept of "this transaction at this merchant for this dollar amount."
- No merchant allowlist. Portkey cannot prevent your agent from spending at an unapproved vendor.
- No velocity protection. Portkey's guardrails run per-request, not as a spend-velocity detector across transactions.
- No human approval queue for spend. There is no "flag this transaction and ask a human" path.
- Budget controls are reactive. Portkey's budget features trigger after a threshold, not pre-spend.
When to pick Portkey vs sipi.bot
Pick Portkey if…
- Your problem is prompt safety — injection, PII, toxicity, response format.
- You need multi-provider LLM routing with guardrails on the calls.
- Your agent does not trigger real payments, only LLM calls.
Pick sipi.bot if…
- Your autonomous agent can spend money (API, compute, tools, real payments).
- You need per-transaction, per-merchant, or velocity guardrails on spend.
- You need a human approval queue for large or ambiguous transactions.
- You need a compliance-grade audit trail of spend decisions.
Run both if…
If your agent both talks to users and spends money, you want Portkey guarding the prompt and sipi.bot guarding the wallet:
# LLM call goes through Portkey for prompt safety
response = portkey.chat.completions.create(...)
# any spend intent goes through sipi.bot first
decision = sipibot.evaluate(amount=6200, merchant="gpu-vendor", category="compute")
if decision != "APPROVED":
block_agent_action(reason=decision.reason)Pricing comparison
| Portkey | sipi.bot | |
|---|---|---|
| Free / OSS | Free tier | Yes (MIT core, self-host) |
| Entry paid | Pro plan | $99/mo Team |
| Business | Enterprise | $499/mo Business |
| Metering | Per-request | Flat, unlimited evaluations |
Our honest verdict
Portkey is the right tool for prompt-level guardrails at the LLM gateway layer. sipi.bot is the right tool for payment-level guardrails at the spend layer. If your autonomous agent can spend money, Portkey will not stop a runaway wallet — sipi.bot will. Run both if you need both.
Frequently asked questions
Is Portkey the same as sipi.bot?
They overlap on the word "guardrails" but solve different problems. Portkey guards what the LLM says (prompts, responses). sipi.bot guards what the agent spends (dollars, merchants, transactions).
Does Portkey have spend limits?
Portkey has budget controls that trigger after a threshold is crossed, as part of its gateway. These are reactive. sipi.bot enforces limits pre-spend.
Which should I use for autonomous agent spend control?
If your agent can trigger real payments, sipi.bot is purpose-built for that. Portkey is purpose-built for LLM gateway concerns.