# KeepRouter vs Portkey: managed model access or provider governance

> KeepRouter sells managed access to models in its public catalog through prepaid credit and KeepRouter keys. Portkey's current documentation says its former Virtual Keys flow has migrated to Model Catalog, where teams add provider credentials and manage organization-level budgets, rate limits, model allowlists, and access. KeepRouter fits teams that want the model purchasing layer managed; Portkey fits teams that want to govern provider relationships they control. [1](https://portkey.ai/docs/product/ai-gateway/virtual-keys) [2](https://portkey.ai/docs/product/ai-gateway) [3](https://keeprouter.com/api/openapi.json) [4](https://keeprouter.com/models)

_Last reviewed 2026-08-15 · [Editorial review](https://keeprouter.com/editorial-policy#editorial-team)_

## Short answer

KeepRouter and Portkey sit at different points in the operating stack. KeepRouter is a managed model-access and billing service: customers use KeepRouter credentials, select a model from the KeepRouter catalog, and spend prepaid KeepRouter credit. Portkey's current official Virtual Keys page says that Virtual Keys have migrated to its Model Catalog, which centralizes provider credentials, organization-level governance, budgets, rate limits, model allowlists, and provider-slug model selection.

Portkey's documentation also states that Portkey is now PRISMA AIRS AI Gateway. This page keeps the familiar Portkey name because that is the comparison query, while treating the current official documentation as authoritative.

## Decision table

| Decision | KeepRouter | Portkey / current Model Catalog |
|---|---|---|
| Primary job | Purchase and call models already offered in a managed public catalog | Connect and govern providers and models through an organization-managed catalog |
| Provider credentials | Customers do not need separate provider credentials for models purchased through KeepRouter | Current docs describe adding providers and storing provider credentials behind Portkey access controls |
| Customer key | A KeepRouter key can be scoped by model allowlist, spend limit, period, and expiry | One Portkey API key can access configured providers; current Model Catalog docs describe budgets, rate limits, and model access controls |
| Model naming | Use the public KeepRouter model ID and the endpoint shown on its model page | Current docs show provider-slug and model-name addressing under Model Catalog |
| Billing source of truth | KeepRouter's prepaid ledger and published customer catalog price | Provider billing and Portkey plan or feature terms must be checked in the current Portkey and provider documentation |
| Governance depth | Self-serve controls focus on a user's KeepRouter keys and usage | Better fit when organization-level provider credential sharing and fine-grained provider/model governance are requirements |

## When KeepRouter is the better fit

Choose KeepRouter when your team wants to avoid negotiating, funding, and rotating a separate account for each model provider, and the required models and endpoints are already in the [KeepRouter catalog](/models). The public catalog gives you a customer-facing model ID, modality, endpoint, and current price before signup. Self-serve keys can restrict model access and spend without turning provider onboarding into a platform project.

KeepRouter is not a substitute for a provider-governance control plane. It does not give customers Portkey's documented organization-level provider credential model, provider-slug addressing, or a claim of equivalent guardrail, routing, and observability features. Upstream details remain private.

## When Portkey is the better fit

Portkey's operating model is more suitable when your organization already owns provider relationships or must bring provider credentials into a governed catalog. Its current Virtual Keys migration page describes shared credentials, fine-grained budgets, rate limits, model allowlists, and access controls under Model Catalog. That is a different problem from buying access through KeepRouter's managed catalog.

Portkey is also the more natural evaluation when platform teams need organization-wide governance around many workspaces. Verify every required feature, deployment option, plan boundary, and new PRISMA AIRS naming detail in current official documentation; this page does not claim a plan, price, compliance status, or deployment mode.

## Migrate from Portkey to KeepRouter

1. Export the application-visible provider slugs, model names, base URLs, headers, budgets, rate limits, allowlists, and fallback or policy configuration that affect requests.
2. Identify which of those models and operations exist in KeepRouter's live catalog. A Portkey provider-slug model name is not a KeepRouter model ID.
3. Replace the Portkey key and gateway URL with a scoped KeepRouter key and the route listed on the selected model page.
4. Move any organization policy that KeepRouter does not expose into your application, secret manager, API gateway, or deployment controls rather than silently dropping it.
5. Re-test authentication, tools, streaming, errors, token usage, spend limits, and output quality before removing the Portkey path.

## Migrate from KeepRouter to Portkey

Create or connect the provider accounts that the target Portkey Model Catalog requires, add their credentials under the current Portkey workflow, define provider-slug model names and access policy, then replace KeepRouter IDs and authentication in the application. Recreate budget, rate-limit, and allowlist intent explicitly; KeepRouter's prepaid balance and private upstream routing do not migrate.

## Can the products be combined?

A layered architecture may be possible if the current Portkey product accepts a custom OpenAI-compatible provider endpoint with the authentication and routes your workload needs. Do not assume automatic support from this comparison. Confirm the current Portkey custom-provider contract, test KeepRouter's Chat Completions route first, and validate Responses, Messages, streaming, tool calls, headers, usage, and error propagation separately. In such a design, Portkey would be the application-facing governance layer while KeepRouter would remain the managed model-access and billing layer.

## Related paths

Read [Key and billing controls](/features/usage-based-billing), [API observability](/features/api-observability), [OpenAI compatibility](/features/openai-compatible-api), and the [security page](/security) before choosing a layered design.

Portkey facts on this page were reviewed on 15 August 2026 against its official Virtual Keys / Model Catalog migration page. Recheck the current PRISMA AIRS AI Gateway documentation before implementation.

## Frequently asked questions

### Does KeepRouter require my provider API keys?

Not for models purchased through KeepRouter's managed catalog. You authenticate with a KeepRouter key and spend KeepRouter credit.

### Are Portkey Virtual Keys still the current workflow?

Portkey's official page says Virtual Keys have migrated to Model Catalog. Review the current migration and Model Catalog documentation rather than implementing an older Virtual Keys tutorial unchanged.

### Does KeepRouter match Portkey's organization governance?

No parity is claimed. KeepRouter exposes self-serve account, key, usage, and spend controls; Portkey documents a broader provider-credential and organization-governance model.

### Can I put Portkey in front of KeepRouter?

Potentially, if Portkey's current custom-provider path supports the required KeepRouter endpoint and headers. Treat it as a tested integration project, not a documented guarantee from this page.

### Which product should a small team choose?

Choose by operating responsibility, not company size. KeepRouter reduces provider-account work; Portkey is relevant when provider credentials and organization policy must remain under your control.

## Sources reviewed

_Sources last reviewed 2026-08-15_

1. [Portkey Virtual Keys and Model Catalog migration](https://portkey.ai/docs/product/ai-gateway/virtual-keys)
2. [Portkey AI Gateway documentation](https://portkey.ai/docs/product/ai-gateway)
3. [KeepRouter OpenAPI](https://keeprouter.com/api/openapi.json)
4. [KeepRouter models and pricing](https://keeprouter.com/models)
5. [KeepRouter security and data handling](https://keeprouter.com/security)

## Related guides

- [Compare AI gateway operating models, not slogans](https://keeprouter.com/compare.md)
- [KeepRouter vs OpenRouter](https://keeprouter.com/compare/openrouter.md)
- [KeepRouter vs LiteLLM](https://keeprouter.com/compare/litellm.md)
- [Usage-based billing](https://keeprouter.com/features/usage-based-billing.md)
- [API observability](https://keeprouter.com/features/api-observability.md)
- [OpenAI-compatible API](https://keeprouter.com/features/openai-compatible-api.md)
- [security](https://keeprouter.com/security.md)

## Choose who should own provider governance

If you want managed model purchasing, verify the KeepRouter catalog and run a scoped request. If you need BYOK governance, evaluate Portkey's current Model Catalog first.

[Create a free key](https://keeprouter.com/login?returnTo=%2Fconsole%2Fkeys%3Fmodel%3Dfree) · [Live models and pricing](https://keeprouter.com/models.md)