Portkey Pricing: Deployment and Cost Normalization

Portkey pricing has four buying paths: a free Developer tier, a $49 monthly Production tier, custom Enterprise pricing and an open-source gateway that the customer can host. The plans meter recorded logs and retention. Model token charges sit with the provider. A fair comparison normalizes subscription, overages, provider spend, deployment labor and evidence requirements in separate workbook columns.

TL;DR

• Developer is free with 10,000 recorded logs per month and short retention; Portkey labels it unsuitable for production workloads.
• Production is $49 per month with 100,000 recorded logs and published overage pricing.
• Enterprise adds custom volume, retention, deployment, governance and support terms through a quote.
• The open-source gateway removes a SaaS subscription line, but hosting, upgrades, telemetry and support still need owners.
• Portkey gateway records and DeepInspect policy decisions cover different evidence jobs.

Portkey pricing uses recorded logs as a key meter

The Portkey pricing page lists Developer as free forever with 10,000 recorded logs per month. It says requests continue after that allowance, while logs beyond the limit are not recorded. Published retention is three days for logs and 30 days for metrics. The page explicitly describes Developer as suitable for prototyping, testing and enterprise proofs of concept, and unsuitable for production workloads.

Production is listed at $49 per month. It includes 100,000 recorded logs per month, followed by $9 for each additional 100,000 up to the public ceiling shown on the page. Log retention is 30 days and metric retention is 90 days. The plan also lists alerts, LLM and partner guardrails, unlimited prompt templates, role-based access control, service-account API keys, production support, and simple plus semantic caching.

Enterprise uses custom pricing for higher-volume and private deployments. Its card describes more than 10 million recorded logs per month, custom retention, custom guardrail hooks, SSO, granular budgets and rate limits, private cloud deployment, VPC hosting, data-lake export, data isolation, dedicated onboarding and priority support. Those are quote inputs, not a public total.

Normalize price and deployment in one workbook

Create a row for every billable or operated component. The workbook should include public value, contracted value, billing unit, forecast, owner, source and acceptance test. Use these cost lines:

• Subscription: Developer, Production or Enterprise, including term and renewal basis.
• Recorded logs: included allowance, expected volume, overage band and behavior after the limit.
• Retention: logs and metrics kept as separate fields, with archive and deletion rules.
• Model-provider spend: tokens, embeddings and provider services outside the Portkey subtotal.
• Deployment: managed SaaS, private cloud, VPC or customer-hosted open source.
• Operations: upgrades, state, backups, monitoring, incident response and on-call ownership.
• Support and compliance: onboarding, response targets, assurance scope, BAA terms and data residency.

Keep each subscription, usage and retention meter visible in its own row. I want the workbook to resemble an operating ledger, not a glossy feature grid. One grey cell marked "custom" should trigger a buyer question, not disappear inside a blended annual number.

Run the same workload forecast through low, expected and peak cases. Count requests that need durable logs separately from requests where logging is intentionally disabled. A plan that allows traffic to continue after the recording allowance can create an evidence gap without causing an application outage. That behavior belongs in the risk register and the acceptance test.

Open source changes the cost owner

Portkey's AI Gateway documentation describes a universal API, cache, fallbacks, conditional routing, retries, circuit breaking, load balancing, canary testing, timeouts, budget limits, rate limits and custom hosts. The page also says the gateway is open source, can run locally and can be self-hosted before connecting to Portkey.

Open source changes the invoice shape. It does not remove hosting, upgrades, observability storage, secrets, backup, scaling or incident response. Put those costs under the team that will operate them. Record the gateway version, deployment image, configuration owner and recovery test. Then force a provider timeout and verify retry, fallback and circuit-breaker behavior against the chosen config.

The AI gateway guide places these functions in category context. Portkey is a strong candidate when the platform team wants provider abstraction and reliability controls with connected telemetry. A customer-operated route can also satisfy deployment constraints that make a shared SaaS path unsuitable, provided the team accepts the operating responsibility.

Observability needs its own normalization tab

Portkey's observability documentation says the platform records multimodal requests and responses, supports tracing through a request lifecycle, provides analytics across more than 21 metrics, and adds filters, custom metadata, feedback and provider-key budget limits. These are operational records used to inspect cost, latency, errors and application behavior.

The workbook should name which fields are stored, which are masked, who can access them and how they leave the platform. Export a known trace and compare its request ID, timestamps, model destination, retries, cost fields, metadata and response. Confirm that privacy settings and retention produce the same result in the contracted deployment. The LLM observability guide helps separate useful traces from evidence required for a policy decision.

Do not infer that a request trace proves authorization. For one authenticated HTTP call, test the caller identity, delegated role, prompt classification, policy version, decision and integrity evidence. Change one attribute and confirm that the policy result changes. That is a different acceptance test from tracing a fallback or calculating provider cost.

Compare Portkey and DeepInspect by control surface

Portkey's cited pages cover routing, reliability controls, recorded logs, traces, budgets, metadata, deployment and plan entitlements. DeepInspect covers authenticated user or agent-to-LLM HTTP requests deliberately routed through its stateless proxy. It evaluates identity, route, destination, prompt data and policy before forwarding allowed traffic, then produces a per-decision record.

Pass a stable correlation identifier across the two layers and specify which one owns retries, timeouts, rate limits and denial responses. A policy denial should never be retried as if it were a transient provider error. A gateway fallback should retain the policy decision and the final model destination. The AI policy enforcement guide describes that request-level job.

Direct SaaS sessions, browser activity, local execution and MCP tool authorization remain outside DeepInspect unless the relevant model request traverses the proxy. Portkey's gateway documentation includes remote MCP connectivity, but that adjacent feature does not place every tool action inside DeepInspect's model-request boundary.

DeepInspect

DeepInspect adds identity-bound policy evaluation to authenticated HTTP model calls that traverse its proxy. A correlated deployment can retain Portkey's gateway route, retries and observability while DeepInspect records the authorization decision that governed the call.

Direct SaaS AI, browser traffic, local execution and tool permissions stay outside DeepInspect unless the model request crosses the inspected route. Book a technical deep dive at deepinspect.ai.