Portkey0 Mixed

Operator Insights

What are teams learning from building on Portkey and running it in production?

8 accounts: 2 failures, incidents or rollbacks, 2 left it or turned it down, 3 adopted it and 1 reported by others

Failures, incidents and rollbacks2

Yupei ChenAuthor of the GitHub issue (GitHub profile names Wise Rock)Wise Rock
Claude Code signed in through Anthropic OAuth and SSO on a Team plan, pointed at Portkey's hosted API with a Portkey key header, set up as Portkey's Claude Code OAuth docs describe.
GitHub (Portkey-AI/gateway), published Apr 10, 2026Read the issue (opens GitHub (Portkey-AI/gateway) in a new tab)
Observation
Claude Code at Wise Rock, signed in through Anthropic OAuth on a Team plan, failed authentication mid-session behind Portkey's hosted API until the Portkey base URL was removed.
Takeaway
If your coding-agent seats sign in with a subscription, run a full working session through the gateway before rollout, and keep a way to bypass it.
What happened
On April 10, 2026 the author reported that mid-session Claude Code starts returning auth errors requiring a new login, while /login and claude auth status show the session still signed in and every API request is rejected. Restarting the session did not help, and only unsetting ANTHROPIC_BASE_URL resolved it. After reading the gateway source, the author concluded that OAuth tokens are never forwarded correctly. The issue was open when GILD stored it on November 1, 2026.
- Public practitioner write-up (GitHub issue)
- No metrics reported
Deployment details
Claude Code signed in through Anthropic OAuth and SSO on a Team plan, pointed at Portkey's hosted API with a Portkey key header, set up as Portkey's Claude Code OAuth docs describe.
- Public practitioner write-up (GitHub issue)
- No metrics reported
Team
Wise Rock
Workload
Claude Code on Anthropic OAuth (Team plan) through Portkey
Product version
Portkey hosted API (api.portkey.ai)

Nilesh DarjiMar 28, 2026GitHub (Portkey-AI/gateway)Tool calls and file inputs failed for a Heizen founding engineer when the OpenAI Responses API went through Portkey's hosted API to Azure OpenAI and Bedrock, while the same call worked against the provider directly.
Nilesh DarjiFounding Engineer, self-described on his own siteHeizen
LangChain's ChatOpenAI on the Responses API, pointed at Portkey's hosted API for GPT-5.4 on Azure OpenAI and for Bedrock. The issue does not name the Heizen product involved.
GitHub (Portkey-AI/gateway), published Mar 28, 2026Read the issue (opens GitHub (Portkey-AI/gateway) in a new tab)
Observation
Tool calls and file inputs failed for a Heizen founding engineer when the OpenAI Responses API went through Portkey's hosted API to Azure OpenAI and Bedrock, while the same call worked against the provider directly.
Takeaway
If your agent framework defaults to the Responses API, test tool calls and file inputs through the gateway for every provider you route to before moving traffic.
What happened
On March 28, 2026 the engineer reported that tool calls fail with the Responses API through Portkey and work when calling the provider directly. Bedrock returned errors for empty message content and for more tool results than tool calls, Azure OpenAI returned ModelNotFound for a model that exists, and file inputs failed on both. On September 10, 2026 another user wrote that they were having to find workarounds and fight frameworks to avoid the errors. The issue was open when GILD stored it on November 1, 2026.
Public practitioner write-up (GitHub issue)
No metrics reported
Deployment details
LangChain's ChatOpenAI on the Responses API, pointed at Portkey's hosted API for GPT-5.4 on Azure OpenAI and for Bedrock. The issue does not name the Heizen product involved.
Public practitioner write-up (GitHub issue)
No metrics reported
Team
Heizen engineering, by the author's profile and site
Workload
LangChain calls with tool calls and file inputs on the Responses API
Product version
Portkey hosted API (api.portkey.ai/v1)
Model
GPT-5.4 on Azure OpenAI

Left it or turned it down2

Rajkumar (rajkumargaramie)Author of the migration pull request (GitHub profile names Medical Informatics Engineering)Medical Informatics Engineering
The reference server behind Medical Informatics Engineering's Ozwell API, which used Portkey to route requests to OpenAI, Anthropic and self-hosted Ollama and to normalize provider request and response formats.
GitHub (mieweb/ozwellai-api), published Oct 2, 2026Read the issue (opens GitHub (mieweb/ozwellai-api) in a new tab)
Observation
Medical Informatics Engineering moved off the Portkey gateway for chat in its Ozwell API, calling OpenAI, Anthropic and Ollama directly, while embeddings and audio still used the gateway when that change merged.
Takeaway
A gateway used mainly for routing and format translation can be replaced one traffic type at a time. Keep a setting that sends traffic back through the gateway until each type passes its tests.
What happened
An issue opened on August 10, 2026 set the goal of replacing the Portkey gateway dependency and connecting providers directly. The first slice, merged into the dev branch on October 6, 2026, sends chat straight to OpenAI, Anthropic and Ollama through the team's internal harness-core library and keeps a setting to roll back to the gateway. Embeddings and audio still used the gateway at merge, with Portkey's config and docs to be removed once they move. The issue and pull request give no reason for leaving.
- Public engineering write-up (the team's GitHub issue and merged pull request)
- No reason for leaving stated
- No metrics reported
Deployment details
The reference server behind Medical Informatics Engineering's Ozwell API, which used Portkey to route requests to OpenAI, Anthropic and self-hosted Ollama and to normalize provider request and response formats.
- Public engineering write-up (the team's GitHub issue and merged pull request)
- No reason for leaving stated
- No metrics reported
Team
Medical Informatics Engineering, Ozwell API
Duration
Issue opened Aug 10, 2026, chat change merged Oct 6, 2026
Workload
Chat, embeddings and audio transcription in the Ozwell reference server

meffmaddJul 1, 2025Hacker NewsA TU Vienna team rejected LiteLLM, Portkey and Kong because each locked SSO, organization management, observability or self-hosting behind enterprise plans, and built its own gateway.
meffmaddMember of a TU Vienna team serving an OpenAI-compatible API to researchersTU Wien
A small team at TU Vienna providing an OpenAI-compatible API to university researchers.
Hacker News, published Jul 1, 2025Read the post (opens Hacker News in a new tab)
Observation
A TU Vienna team rejected LiteLLM, Portkey and Kong because each locked SSO, organization management, observability or self-hosting behind enterprise plans, and built its own gateway.
Takeaway
List the controls you need before a gateway trial and price the plan that includes them; on Portkey, budgets, SSO and audit logs sit on Enterprise.
What happened
The team looked at LiteLLM, Portkey and Kong for its researchers' API and found that every one put a feature it needed, such as SSO, organization management, observability or self-hosting, behind an enterprise plan. It rejected all three and built Aqueduct, its own open-source gateway (Hacker News, Jul 1, 2025).
“Every AI gateway we looked at (LiteLLM, Portkey, Kong, etc.) locked critical features like SSO, organization management, observability, or self-hosting behind enterprise plans.”
meffmadd
Public practitioner write-up (Hacker News post)
No metrics reported
Deployment details
A small team at TU Vienna providing an OpenAI-compatible API to university researchers.
Public practitioner write-up (Hacker News post)
No metrics reported
Team
A small TU Vienna team
Workload
An OpenAI-compatible API for university researchers

Adopted it3

Louis ChoquelPipelex team memberPipelex
Pipelex, an open-source pipeline framework with a hosted plane whose model calls go through a Portkey gateway.
GitHub (Pipelex/pipelex), published Aug 18, 2026Read the design (opens GitHub (Pipelex/pipelex) in a new tab)
Observation
Pipelex routes its hosted runs through a Portkey gateway and designed a separate gateway key for each run, bound per request under its Temporal workflows.
Takeaway
When one gateway key serves every run, plan per-request keys early and test what the client actually sends against what the code appears to pass.
What happened
Pipelex's hosted runs call models through a Portkey gateway with one gateway key cached in the SDK client. To give each hosted run its own key, the team surveyed where every SDK it ships binds the API key, verified overrides against pinned versions, and narrowed the design to the gateway path under its Temporal plugin. It also found a trap in the Portkey client, where passing headers to post() would pass review while still sending the boot key.
- Public engineering write-up (a design document in Pipelex's repository)
Deployment details
Pipelex, an open-source pipeline framework with a hosted plane whose model calls go through a Portkey gateway.
- Public engineering write-up (a design document in Pipelex's repository)
Team
Pipelex engineering
Workload
Hosted Pipelex runs under Temporal workflows

punkpeyeJul 18, 2026GitHub (Portkey-AI/gateway)Glama's founder points Portkey users to Lightport, a fork of Portkey's open-source gateway that Glama says it actively maintains.
punkpeyeFounder at Glama by his GitHub profile, maintainer of the Lightport forkGlama
Glama, which maintains the competing Lightport fork, so its pointer to the fork comes from an interested party.
GitHub (Portkey-AI/gateway), published Jul 18, 2026Read the issue (opens GitHub (Portkey-AI/gateway) in a new tab)
Observation
Glama's founder points Portkey users to Lightport, a fork of Portkey's open-source gateway that Glama says it actively maintains.
Takeaway
If you self-host Portkey's open-source gateway, track its commit activity and keep a maintained fork in view before you depend on it.
What happened
On July 18, 2026, Glama's founder posted in Portkey's repository for anyone looking for an actively maintained fork. He states that Lightport started as a fork of Portkey, that Glama has since fixed numerous bugs, added integration tests for every provider and kept maintaining it, and that it stripped guardrails, fallbacks, automatic retries and load balancing.
“…in case anyone is looking for an actively maintained fork of Portkey…”
punkpeye
Public practitioner write-up (GitHub issue)
No metrics reported
Deployment details
Glama, which maintains the competing Lightport fork, so its pointer to the fork comes from an interested party.
Public practitioner write-up (GitHub issue)
No metrics reported
Team
Glama
Workload
Maintaining the Lightport fork
Product version
Lightport, a fork of Portkey AI Gateway
Akashkhurana HiranaJun 27, 2026PeerSpotPorch calls Gemini, OpenAI, Claude, and its own fine-tuned models through Portkey, with model keys kept in a vault and guardrails that stop personal data reaching the models.
Akashkhurana HiranaSenior Software Engineer 2Porch
Porch, running AI applications on several model makers and its own fine-tuned models.
PeerSpot, published Jun 27, 2026Read the review (opens PeerSpot in a new tab)
Observation
Porch calls Gemini, OpenAI, Claude, and its own fine-tuned models through Portkey, with model keys kept in a vault and guardrails that stop personal data reaching the models.
Takeaway
Keep model keys out of developers' hands by putting the gateway between them and every model, and test guardrails on real personal data patterns.
What happened
Porch uses Portkey as its LLM gateway to watch how its models behave. Engineers call Portkey, while model API keys stay in a vault only Portkey can read, and guardrails check inputs so a user's personal information is not sent to a model. The engineer calls Portkey foundational to the team's AI stack and asks for fuller documentation, end-to-end reference architectures, and built-in evaluation for prompt testing and regression analysis.
Public practitioner write-up (a named engineer's PeerSpot review)
Deployment details
Porch, running AI applications on several model makers and its own fine-tuned models.
Public practitioner write-up (a named engineer's PeerSpot review)
Team
Porch engineering
Workload
AI applications on Gemini, OpenAI, and Claude models and custom fine-tuned models
Model
Gemini, OpenAI, and Claude models; custom fine-tuned models

Reported by others1

ToolzzJul 23, 2025GitHub (Portkey-AI/gateway)A caching change on Portkey cloud turned one platform's simple cache into a semantic one and took its whole platform down until Portkey reverted it.
Leonardo MarcianoCTO, as his GitHub profile describes himselfToolzz
A platform running its model traffic through Portkey's hosted cloud with simple caching configured.
GitHub (Portkey-AI/gateway), published Jul 23, 2025Read the issue (opens GitHub (Portkey-AI/gateway) in a new tab)
Observation
A caching change on Portkey cloud turned one platform's simple cache into a semantic one and took its whole platform down until Portkey reverted it.
Takeaway
A hosted gateway's change reaches every app behind it at once, so cache settings need a canary check and alerts on hit rate and errors.
What happened
On July 23, 2025 a change Portkey made while fixing caching issues made one platform's simple cache behave as a semantic cache, so similar requests matched each other and the cache hit rate approached 100%. Its CTO reported a platform-wide outage affecting all its customers while they were using the system. Portkey's team replied that it had introduced a bug that caused cache collisions and had fully reverted it by 03:23 UTC that day.
“This caused a complete platform failure while all customers were actively using the system.”
Leonardo Marciano
Public engineering write-up (the CTO's GitHub issue)
Vendor reply in the same issue
Deployment details
A platform running its model traffic through Portkey's hosted cloud with simple caching configured.
Public engineering write-up (the CTO's GitHub issue)
Vendor reply in the same issue
Team
A platform on Portkey cloud, reported by its self-described CTO
Duration
Until Portkey's revert at 03:23 UTC on July 23, 2025
Workload
A production platform on Portkey cloud
Product version
Portkey cloud as of July 23, 2025
Measurement
Cache hit rate near 100%; outage across all customers

Failures, incidents and rollbacks2

Claude Code at Wise Rock, signed in through Anthropic OAuth on a Team plan, failed authentication mid-session behind Portkey's hosted API until the Portkey base URL was removed.

Tool calls and file inputs failed for a Heizen founding engineer when the OpenAI Responses API went through Portkey's hosted API to Azure OpenAI and Bedrock, while the same call worked against the provider directly.

Left it or turned it down2

Medical Informatics Engineering moved off the Portkey gateway for chat in its Ozwell API, calling OpenAI, Anthropic and Ollama directly, while embeddings and audio still used the gateway when that change merged.

A TU Vienna team rejected LiteLLM, Portkey and Kong because each locked SSO, organization management, observability or self-hosting behind enterprise plans, and built its own gateway.

Adopted it3

Pipelex routes its hosted runs through a Portkey gateway and designed a separate gateway key for each run, bound per request under its Temporal workflows.

Glama's founder points Portkey users to Lightport, a fork of Portkey's open-source gateway that Glama says it actively maintains.

Porch calls Gemini, OpenAI, Claude, and its own fine-tuned models through Portkey, with model keys kept in a vault and guardrails that stop personal data reaching the models.

Reported by others1

A caching change on Portkey cloud turned one platform's simple cache into a semantic one and took its whole platform down until Portkey reverted it.