Prune vs Portkey — when to use each
Both sit in front of your model calls. The difference is what happens by default before the request leaves your infrastructure.
Quick answer
Portkey is an AI gateway built around virtual keys, routing, and an observability/guardrails ecosystem you wire up per project. Prune is a managed gateway where PII tokenization, spend caps, and injection auditing are Shield defaults on every key — plus unique-path cost control on traffic that never repeats, and a signed receipt per call.
Side-by-side
| Dimension | Portkey | Prune |
|---|---|---|
| Guardrails | Configurable plugin pipeline (before/after hooks) | Default-on Vault Guard — PII + injection on every key |
| PII handling | Depends on guardrail provider wired in | Built-in detect / redact / reversible tokenize |
| Spend caps | Budgets + alerts | Hard stop — Spend caps enforced in under 10ms, before the provider call |
| Caching | Simple + semantic cache | Provider-native prefix cache broker (Anthropic cache_control, OpenAI prompt_cache_key) + tenant-scoped semantic cache |
| Proof | Logs / traces dashboard | prune_metadata on every response, Ed25519-signed — verify at /verify |
Guardrails: plugin pipeline vs default-on enforcement
Portkey's guardrails run as a configured pipeline — you choose and wire in the checks you want per project. That's flexible, but it means safety is opt-in per integration, and a new API key someone forgets to configure ships with none of it.
Prune's Vault Guard is a floor, not an add-on: PII tokenization and injection auditing apply to every key by default, with X-Prune-PII-Mode and X-Prune-Injection letting you strengthen (never silently weaken) the policy per request.
Spend control: budgets and alerts vs a hard stop
Soft spend warnings tell you after the money is already committed to the provider call. Prune enforces spend caps before the upstream request — a 429 with X-Prune-Shield-Code: spend_cap, checked in under 10ms, so a runaway loop or leaked key cannot blow through budget between the alert firing and a human reacting.
Caching: general-purpose vs provider-native cache brokering
A proxy-side cache trim can't reach the discount depth of a provider's own prompt cache (often 50–90% on cached input). Prune Prefix brokers Anthropic's ephemeral cache_control and OpenAI's prompt_cache_key directly, then reconciles provider-side and Prune-side savings into one receipt field (total_effective_savings_usd) without double-counting.
When Portkey is the right choice
- You want to hand-pick guardrail vendors per project
- Your team already standardizes on Portkey's virtual key model
- Observability/tracing across many providers is the main need
When Prune is the right choice
- You want security defaults that don't depend on per-project setup
- You need a hard spend stop, not a budget alert
- Unique-path savings matter — most of your traffic never repeats (≥25% median cost reduction on unique (non-cache) traffic in the published benchmark suite)
- Finance/security wants a signed, verifiable receipt, not a dashboard export