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, in-process in its TypeScript SDK, not at a gateway. Portkey also ships an MCP Gateway with per-tool access control (GA Jan 2026) |
| 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 deterministic incident replay and the signed record.
Source: Portkey's public documentation, https://portkey.ai/docs, read 15 September 2026. Products change: report an error to legal@runback.dev and we will correct it. Names and trade marks belong to their owners; Runback is not affiliated with, endorsed or sponsored by any of them.
No signup. Walk the scripted failing demo run step by step and see what the model was given.