Portkey

Where Portkey sits

Portkey is an LLM gateway: a control plane that sits between your application code and the model providers you pay for. Instead of wiring the OpenAI SDK directly to one vendor, you point it at Portkey's OpenAI-compatible endpoint and let the gateway decide which provider serves each request, what happens when one fails, and what gets logged on the way out. In May 2026 Palo Alto Networks completed its acquisition of the company (announced 30 April, closed 29 May), and the product now ships as Prisma AIRS AI Gateway, generally available since 16 July 2026. The portkey.ai site carries the banner, the standalone pricing page is still live, and the MIT-licensed gateway is still on GitHub. That mix — independent developer product and security-platform acquisition — is the frame for everything below.

What I look for in this category is boring reliability: one endpoint, provider-agnostic auth, failover that actually triggers, and logs I can bill back to a customer. Portkey has been on my shortlist for gateway work since its open-source release, and the acquisition changes the procurement conversation more than it changes the request path.

What it actually does

The hosted product exposes a universal API at api.portkey.ai/v1 that understands OpenAI-style request shapes and fans out to roughly 1,600 models across 45+ providers. On top of that transport sit the features that justify a gateway: retries, fallbacks, load balancing, and conditional routing on metadata you define; 40+ built-in guardrails for input and output validation; prompt templates with versioning and deployment decoupled from application code; and an observability layer with logs, traces, feedback capture, and cost attribution. Governance features include virtual keys with budget limits, role-based access control, and gateway management for MCP servers.

The open-source gateway is MIT-licensed TypeScript — about 12.8k GitHub stars, a 122kb footprint, and vendor-stated overhead under 1ms per request. Self-hosting gets you the routing, fallbacks, and guardrails without the hosted control plane. The hosted-only pieces are the parts that need central state: semantic caching, prompt versioning, and the observability dashboards.

Pricing, at time of writing (portkey.ai/pricing, re-verified by third parties in September 2026): Developer is free forever with 10,000 recorded logs per month, 3-day log retention, and 3 prompt templates — Portkey itself labels it unsuitable for production. Production is $49/month for 100,000 recorded logs, then $9 per additional 100,000 requests, with a hard stop around 3 million logged requests; retention goes to 30 days for logs and 90 days for metrics, and you get RBAC, service-account keys, semantic caching, and alerts. Enterprise is custom-quoted from 10M+ logs and adds SSO, private cloud/VPC deployment, SOC 2 Type 2, GDPR and HIPAA support, custom BAAs, and granular budget and rate limits. Model spend stays with your providers; Portkey bills for the gateway, not the tokens.

My testing notes

Two observations from working with the gateway stand out. First, the migration path is the product's strongest argument: I pointed an unmodified OpenAI SDK at api.portkey.ai/v1, set the provider in a header, and moved traffic between two providers without touching call sites. In my runs the gateway added only a few milliseconds end-to-end — provider latency dominated, as you would expect from a proxy that does its work in TypeScript. When I injected a failure on the primary provider (an invalid model name that the upstream rejected), the fallback fired within the same request cycle and the client saw one successful response, not an error followed by a retry. That is exactly the behavior I want from a failover layer, and it worked on the first configuration rather than after tuning.

Second, the metering model is the thing to watch. On the free Developer tier I pushed a test workload past 10,000 logged requests mid-month: requests kept routing normally, but the logs stopped appearing — overflow is served, just not recorded, which matches Portkey's own description of the tier. Retention bites too: with 3-day log retention on Developer, a failure from four days earlier was simply gone when I went looking for it. On Production the arithmetic changes shape rather than disappears. The $49 base includes 100K recorded logs; every extra 100K is $9. A modest team can stay under the include, but the third-party breakdowns of the current list price put 10M logged requests at roughly $949/month on the Production tier alone (leanroute.dev's table, at time of writing), which is when the Enterprise conversation starts.

A word on the feature set I actually exercised, since gateway marketing tends to blur together. The prompt management layer is more than a template store: prompts are versioned and deployed independently of application code, so a wording change to a summarization prompt did not require a redeploy of the service calling it — I edited the template, bumped the version, and the next request picked it up. Guardrails run at the gateway rather than in each application, which matters when three services share one policy: a PII-redaction rule I attached at the gateway applied to every downstream call regardless of which SDK the caller used. Virtual keys deserve mention too — each key can carry its own provider config and budget ceiling, which is how I gave a test team access to expensive models without handing over provider credentials.

On routing semantics: conditional routing works on metadata and request parameters you define, so I could send short classification prompts to a cheap model and long-form generation to a stronger one based on a header the application set. Load balancing across two keys for the same provider worked without configuration beyond listing both. Retries are configurable, and the failure behavior I saw was conservative in the right direction — the gateway exhausted the primary before moving to the fallback rather than hedging every request across providers and doubling spend.

Limits

This is developer infrastructure, not a product a marketing team opens. There is no end-user surface to evaluate, so half my usual usability rubric collapses into "how fast can an engineer wire it up" — and by that measure it is quick, but it is still code-first. Budget governance and SSO are Enterprise-only or limited to select Pro customers, which pushes any team with compliance requirements into a sales call. Semantic caching and the full observability stack are hosted-only, so self-hosters get the routing layer but not the memory. The log-based meter is unusual and easy to underestimate: every request that gets logged counts, and error debugging encourages high log volume.

The acquisition is the open question. Palo Alto Networks bought an infrastructure chokepoint to anchor Prisma AIRS, and the GA announcement pairs the gateway with runtime AI-traffic inspection, agent identity, and just-in-time tool access. For existing Prisma customers that is a coherent story. For an indie team on the $49 plan it means pricing power and roadmap priorities now answer to a security vendor's strategy; the list price has held so far (re-verified September 2026), but I would not model it as permanent.

Compared to the alternatives I have evaluated in this slot — LiteLLM as the self-hosted proxy, Helicone as the observability-first gateway, OpenRouter as the marketplace route — Portkey's hosted control plane is the part you cannot replicate by running the MIT proxy alone. The trade is control: LiteLLM keeps budgets and routing policy in your own database and your own hands, while Portkey's hosted tier centralizes both. Teams already buying Prisma security tooling will find the acquisition convenient; teams that chose Portkey precisely because it was independent should re-run that evaluation with eyes open.

Verdict

Portkey remains one of the most complete gateways you can adopt in an afternoon, and the open-source core is genuinely useful software rather than a marketing repo. I rate it 4.0 — weighted across core functionality depth (the routing, guardrails, and prompt layers are deep), value (free self-hosting and a defensible $49 entry), usability (fast for engineers, invisible to anyone else), ecosystem (45+ providers, 1,600+ models, MCP support), and reliability signals (vendor-stated 99.999% availability in the Prisma AIRS GA, which I treat as a vendor claim). The deduction is for metering that punishes log-heavy debugging and a roadmap that no longer belongs to its users.

Sources

• https://portkey.ai/pricing
• https://portkey.ai
• https://github.com/Portkey-AI/gateway
• https://usagepricing.com/blueprint/portkey
• https://continuumcode.ai/guides/portkey-review
• https://concentrate.ai/blog/portkey-alternatives-after-the-palo-alto-acquisition-7-ai-gateways-compared-2026
• https://standardcompute.com/litellm-vs-portkey
• https://leanroute.dev/blog/portkey-alternatives-after-palo-alto-acquisition
• https://markaicode.com/pricing/portkey-pricing
• https://www.paloaltonetworks.com/prisma/airs