Perishable vs Portkey AI Gateway
Portkey is a feature-rich AI gateway aimed at server-to-server reliability and observability across many providers. Perishable is a smaller, narrower tool focused on one job: not leaking your API key from the browser. Different problems, sometimes deployed together.
| Dimension | Perishable | Portkey |
|---|---|---|
| Primary job Different starting points, often complementary. | Stop client-side AI calls from leaking the upstream key. | Unified gateway with routing, caching, retries, and observability across many LLM providers. |
| Deployment shape | Self-hosted Node process. `npx perishable-proxy` or embedded via `PerishableServer`. | Hosted cloud service; also open-source and self-hostable per Portkey docs. |
| Client-side bot protection | Built-in: fingerprinting + entropy collection in the browser SDK, enforced by the proxy. | Not the primary focus; the gateway is positioned for server-to-server traffic. |
| Short-lived client tokens | Yes — JWT sessions bound to client fingerprint, with `expiryBuffer` for transparent refresh. | Not the headline feature in the public gateway docs; auth model is gateway-centric. |
| Provider compatibility | Anything that speaks the OpenAI API shape: OpenAI, Anthropic (via base URL), OpenRouter, Ollama. | Broad, native multi-provider with routing, fallback, canary testing across many models. |
| Caching, semantic caching | Out of scope. | Yes — simple and semantic caching, with cost-saving framing. |
| Observability | Process-local logs. Out of scope for the proxy itself; pair with your existing stack. | First-class: dashboards, request logs, cost analytics. |
| License | MIT. | Open-source core with hosted commercial offering. |
| Best fit | Client-side AI shippers who need a small, owned process between the browser and the API. | Teams running production server-side AI workloads who need routing, caching, fallback, and dashboards. |
When Portkey is the better fit
If you are running server-to-server AI workloads — your backend calls OpenAI, Anthropic, and a self-hosted model and you want unified observability, automatic fallback, semantic caching, and a single API surface across providers — Portkey is doing what it was designed to do and Perishable is not even competing.
Specifically, reach for Portkey (or a similar gateway) if you want:
- A dashboard that shows you spend by team, by model, by route.
- Conditional routing or canary tests between providers.
- Semantic cache hits across paraphrased prompts.
- Fallbacks that automatically switch from one provider to another on failure.
Perishable does none of those things. It would be wrong to claim otherwise.
When Perishable is the better fit
If your problem is the narrower one — “I have a browser, iOS, or Electron app, I want to call OpenAI, I do not want my key in the bundle, and I do not want to add a hosted SaaS to my dependency tree” — Perishable is the smaller, more focused tool. It runs as a Node process you own, holds the upstream key in server-side env, and issues fingerprint-bound short-lived JWTs to clients.
Specifically, reach for Perishable if you want:
- A drop-in proxy you can run yourself with one command.
- Browser fingerprinting + entropy collection built in.
- Short-lived JWT sessions, refresh on a buffer, all in the client SDK.
- MIT, no SaaS account, no per-seat licensing, traffic stays in your infra.
They are not mutually exclusive
A reasonable production topology runs Perishable as the browser-facing edge (handling fingerprint, entropy, JWT, rate limit) and Portkey (or another gateway) behind it for routing, caching, and dashboards. The two layers do different things.
Perishable’s OPENAI_BASE_URL can be pointed at a Portkey endpoint
instead of OpenAI directly. From the browser’s perspective, nothing
changes. From your infra’s perspective, you get the safety layer
Perishable provides and the gateway features Portkey provides, each
doing what it is good at.
This comparison is grounded in each project's public docs as of 2026-05-30. If something has moved, open an issue.