Key facts
| What Portkey is | AI gateway and control plane over your provider keys |
| Features | Routing, caching, guardrails, observability and budgets |
| Delivery | Open-source gateway plus a hosted control plane |
| Not a model provider | You still pay each provider per token |
| Plugsky model | Managed API serving its own 30+ model catalogue |
| Plugsky pricing | Flat monthly self-serve plans; free plan with two models |
| Plugsky deployment | Cloud, VPC, on-prem or air-gapped |
| Status | Chat, streaming, JSON mode, function calling and embeddings live on Plugsky |
TL;DR
- Portkey governs traffic across providers; it does not serve models itself.
- Alternatives split into gateways, aggregators and managed APIs.
- Keep a gateway when guardrails and provider-level control are the product.
- Move to a managed API when you want models, billing and residency handled.
- Gateways and managed APIs can coexist behind one OpenAI-compatible interface.
How it works, step by step
- List which gateway features you actually use: routing, guardrails, caching or budgets.
- Decide whether you must keep provider keys and per-token provider spend.
- Shortlist alternatives: self-hosted gateway, aggregator, managed platform.
- Pilot one workload on the shortlisted option with identical prompts.
- Compare maintainability, data path and cost at your real volume.
- Document which layer owns routing, logging and guardrails after the switch.
Try it yourself
Open the Portkey API cost calculator →
What Portkey does and does not do
Portkey shines as a control plane. It centralises routing rules, caches repeated calls, applies guardrails, tracks spend and exposes observability across providers. For platform teams that already have provider relationships and want policy in one place, that is the right abstraction.
What it does not do is serve models. Requests still travel to provider APIs you contracted with, token spend still lands on those accounts, and the gateway becomes another production dependency to run or trust.
The alternatives compared
Self-hosted gateways such as LiteLLM cover the same routing and fallback territory with more control and more operations. Aggregators such as OpenRouter optimise for catalogue breadth, giving you many models without provider contracts, again per token. Managed platforms such as Plugsky remove the gateway layer entirely: one catalogue of 30+ models, one OpenAI-compatible endpoint, flat monthly self-serve plans and private deployment options.
The honest trade is governance depth. Gateway products offer guardrail and observability features that a model platform does not replicate. If those are compliance requirements, keep the gateway and put managed capacity behind it.
Moving or staying
Decide what the gateway is for. If it exists mainly to unify APIs, a managed endpoint removes the need for most of it. If it enforces policy, redacts sensitive data or produces audit evidence, it is doing work you would have to rebuild elsewhere.
A useful pattern is to keep the gateway where policy lives and let it route to Plugsky for primary workloads. That preserves one request path, keeps provider-specific exceptions contained, and lets the managed side handle capacity and pricing. Plan details are on the live pricing page.
Honest comparison
| Capability | Plugsky | Portkey | Self-hosted gateway |
|---|---|---|---|
| Serves models | Yes, its own 30+ catalogue | No, routes to providers | No, routes to providers |
| Provider keys | Not needed | Required | Required |
| Guardrails and caching | Not a gateway feature | Built in | Varies by project |
| Observability | Platform usage views | Cross-provider analytics | Whatever you instrument |
| Billing | Flat monthly self-serve plans | Provider spend plus gateway fees | Provider spend only |
| Operations | None | Hosted or self-hosted gateway | You run everything |
Frequently asked questions
What is the best Portkey alternative?
For self-hosted routing and fallbacks, LiteLLM is the closest alternative. For managed models with flat pricing and no gateway to run, Plugsky is the alternative. For catalogue breadth, an aggregator such as OpenRouter fits.
Does Plugsky replace Portkey's guardrails?
No. Guardrails, caching policies and cross-provider observability are gateway features. If you need them, keep a gateway layer and use Plugsky as an upstream provider.
Can I use Portkey with Plugsky together?
Yes. A gateway can route to an OpenAI-compatible managed endpoint, which keeps one policy layer while the managed platform handles serving and capacity.
Which option is cheaper?
A gateway adds fees or operations on top of provider token spend. A managed platform uses flat monthly plans. Compare at your real volume rather than on headline rates.
Do I need to give up provider keys with Plugsky?
Yes. Plugsky serves its own catalogue, so there are no provider keys to manage. That simplifies security but removes the ability to route to vendors outside the catalogue.
Is migration hard?
If your client is OpenAI-compatible, it is mostly base URL and model-name changes. The hard part is rebuilding any governance behaviour the gateway provided.
What if I only use the gateway for logging?
Then a managed platform with usage views may be enough. Audit whether the logs feed compliance processes before removing the gateway.