route-switch vs. Portkey
Portkey is an AI gateway with strong observability, guardrails, and a prompt library. Route-Switch is a Go gateway whose distinguishing feature is closed-loop MIPROv2 prompt optimization. The overlap is real; the focus is different.
| Dimension | route-switch | Portkey |
|---|---|---|
| Deployment model | Self-hosted Go binary. SQLite per-prompt, DuckDB for analytics, both local files. | Hosted SaaS, with self-hosted option available for enterprise customers. |
| Model coverage | Providers wired through gollm: OpenAI, Anthropic, Google, Ollama, Cohere, Mistral, and others. | Broad multi-provider support across many LLM and embedding APIs through a unified gateway. |
| API surface | OpenAI-compatible /v1/chat/completions; metadata field for template/combination targeting. | OpenAI-compatible and provider-native endpoints; configurable virtual keys; rich request metadata. |
| Routing logic Portkey's routing is more declarative; route-switch's is strategy-based on captured performance. | round_robin / weighted / performance_based across registered combinations; threshold-based fallback when success rate drops. | Configurable routing via 'configs': fallbacks, load balancing, conditional routing on request attributes. |
| Observability If you want pre-built dashboards out of the box, Portkey is the stronger story. | DuckDB store with per-prompt and global aggregates: success rate, latency, cost. Surfaced through /status, /v1/prompts/{id}/stats, /v1/system/analytics. | First-class observability product: traces, logs, dashboards, alerting, cost breakdowns. This is a primary feature. |
| Prompt management | Local registry via CLI: template register / list / export. Templates are YAML manifests on disk. | Hosted prompt library with versioning, partials, and a UI for editing. |
| Automatic prompt optimization | MIPROv2 + goptuna; scores candidates by replaying captured dataset rows; runs in background on a configurable interval. | Not the primary focus. Prompt iteration tools exist; closed-loop optimization against captured traffic is not the headline feature. |
| Guardrails / safety If guardrails are a hard requirement, Portkey or a dedicated guardrails layer in front of route-switch is the right shape. | Not in scope. No PII redaction, no content moderation, no schema validation. | First-class guardrails: PII detection, content moderation, JSON schema validation, custom checks. |
| Caching | Per-prompt SQLite dataset captures every call but is not a response cache; identical requests are not deduplicated. | Built-in response caching (simple and semantic) is a feature. |
| License | MIT. | Open-source gateway core (MIT); managed product is commercial. |
| Best fit | Teams who want the optimizer in the same binary as the router and care about per-prompt closed-loop improvement more than observability polish. | Teams who want a polished AI gateway with strong observability and guardrails as the primary value proposition. |
Where they overlap
Both projects are gateways. Both speak OpenAI-compatible. Both let you front multiple providers behind one endpoint with fallback and load balancing. Both record per-call data for later analysis. Both are a sensible answer to the question “where do I put my LLM cross-cutting concerns?”
Where they diverge
Portkey is structured as an observability-first AI gateway. The strongest pieces of the product are the dashboards, the request log, the guardrails layer, the prompt library UI, and the caching. Routing is one feature among several; prompt optimization is not the headline feature.
Route-Switch is structured as an optimization-first gateway. The strongest piece of the product is the closed loop: every call writes to a per-prompt SQLite dataset, the MIPROv2 optimizer replays that dataset to score candidate prompts, and the winner ships to the registry. The analytics store, the load balancer, and the OpenAI-compatible endpoint are in service of that loop. Observability is present but is not the primary artefact.
When to pick which
Pick Portkey when observability and guardrails are the top-of-list problems. If you need PII redaction at the gateway, prebuilt spend dashboards, a UI for managing prompts across non-engineers, and semantic response caching, that’s the product you want.
Pick Route-Switch when the top-of-list problem is “our prompts drift and nobody re-evaluates them.” The integrated MIPROv2 loop is the thing route-switch is built around, and it lives in the same process as the gateway by design, not as a separate optimization tool. If you also want the operational footprint of a single Go binary and local-only state files, that’s a win you get for free.
These aren’t substitutes so much as different bets about which problem deserves the most engineering. Either bet can be the right one depending on what hurts most this quarter.