Portkey is an AI gateway — unified routing across providers, with caching, fallbacks, guardrails, and observability on the request path. It's built for production reliability at the request layer, not for reconstructing or re-executing what an agent decided across a multi-step run.
| Capability | Portkey | Runback | Note |
|---|---|---|---|
| Multi-provider request routing, caching, fallbacks | ✓ | ✗ | Portkey speciality — not Runback's scope |
| Guardrails on requests/responses | ✓ | partial | Runback enforces policy on tool calls, not the gateway layer |
| Read and search traces | ✓ | ✓ | |
| Multi-step tool-call capture and causal links | partial | ✓ | Real parent-child span tracing when the app instruments it — captures sequencing, but not enough state to replay a step |
| Re-execute any step from captured inputs | ✗ | ✓ | Without the full tool-call chain, there's no captured state to replay a specific step against |
| CI release gate | ✗ | ✓ | |
| Signed, tamper-evident audit export | ✗ | ✓ | Gateway request logs are operational telemetry — no hash chain, no signature, nothing independently verifiable |
| Regulatory mappings (EU AI Act · CPS 230 · NIST) | ✗ | ✓ |
It's built for production reliability at the request layer, not for reconstructing or re-executing what an agent decided across a multi-step run. Most teams use both — Portkey for what it's already good at, Runback for the incident replay, CI gate, and signed record it doesn't do.
Compiled from Portkey's public documentation at https://portkey.ai/docs, read on 15 September 2026. Products change; if a row is out of date or wrong, tell us at legal@runback.dev and we will correct it. All product names and trade marks are the property of their respective owners. Runback is not affiliated with, endorsed by, or sponsored by any of them.
No signup. Walk a failing production run step by step and see what the model saw.