n4n.ai vs Portkey: gateway pricing and fee structure

Most teams evaluating LLM gateways hit the same spreadsheet: provider token cost is only half the story. When you line up n4n.ai vs Portkey pricing, the divergence is in how each layer bills for routing, fallback, and observability rather than in the raw model weights. Both sit in front of OpenAI, Anthropic, and open-source endpoints, but their fee structures reflect different product philosophies.

Capabilities

Portkey ships as a full control plane for LLM traffic. You get virtual keys that abstract provider credentials, request/response logging, prompt versioning, and guardrails. Its gateway supports load balancing across multiple providers, automatic retries with exponential backoff, and semantic caching keyed on prompt hashes. The feature set targets platform teams who want one pane of glass for every model call, with the ability to revert a bad prompt deploy without code changes.

A thin OpenRouter-class gateway focuses on request pass-through with smart routing. It exposes a single OpenAI-compatible endpoint that fronts 240+ models, applies automatic fallback when a provider returns 429 or 5xx, and honors client routing directives such as preferred region or provider allowlist. It forwards provider cache-control hints so that upstream prompt caching works as if you called the provider directly. There is no prompt registry or built-in eval suite—those are your responsibility.

The capability gap matters for pricing because each added feature is either bundled into a subscription or metered separately. If you never query the prompt versioning API, you still pay for its existence in Portkey’s platform fee.

Price and Cost Model

Portkey publishes a free tier with monthly request caps and paid plans that unlock higher limits and advanced observability. The economic model blends a recurring platform fee (per seat or per organization) with pass-through provider token costs. In practice, you pay the provider’s published rate for tokens plus Portkey’s platform cost. For high-volume traffic, enterprise contracts negotiate custom markup or fixed platform fees. Logging retention and guardrail executions may count against separate quotas.

The alternative gateway model exposes per-token usage metering with an OpenAI-compatible endpoint, so the billed amount tracks provider consumption closely. There is no separate feature tax for fallback or routing—those are part of the request path. Engineers who want to predict spend can sum provider token prices and treat gateway overhead as negligible. The trade-off is that you must build your own request logging if you need it.

When analyzing the two side by side, the key variable is whether you need the extra control plane. If you only need reliable routing and fallback, a metered pass-through keeps the line items simple. If you need audit logs and prompt management, Portkey’s bundled fee may be cheaper than building those yourself.

Latency and Throughput

Both gateways add a proxy hop. Portkey’s additional processing—cache lookups, logging, guardrail checks—can add single-digit milliseconds to p50 latency under light load, and more under heavy transform workloads. Its architecture scales horizontally, but the extra middleware is on the critical path. If you enable response sampling for evals, tail latency can climb when the analytics backend throttles.

A minimal gateway strips the request to provider-forwarding with fallback logic. The overhead is primarily TLS termination and a routing decision, often under 2 ms region-local. Throughput is bounded by the upstream provider, not the gateway, assuming the gateway avoids buffering responses. For streaming tokens, both support SSE pass-through. The thin gateway typically does not inspect streamed chunks; Portkey may sample them for logging, which can affect tail latency if the logging backend backs up.

Region selection also plays a role. Portkey lets you pin virtual keys to specific provider regions via dashboard config. A thin gateway honors client headers like x-route-prefer: us-east, keeping region logic in your code rather than a hosted UI.

Ergonomics

Portkey requires creating a virtual key and setting headers. The OpenAI SDK works with a custom base URL:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.portkey.ai/v1",
    api_key="pk-your-portkey-key",
    default_headers={
        "x-portkey-provider": "openai",
        "x-portkey-api-key": "sk-provider-key"
    }
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)

The same SDK pattern works against any OpenAI-compatible gateway. You swap the base URL and auth header. Routing directives are passed as headers or JSON body extensions. For example, a client can ask the gateway to prefer a specific provider region:

{
  "model": "claude-3-5-sonnet",
  "messages": [{"role": "user", "content": "hi"}],
  "route": {"prefer": "anthropic-us-east"}
}

In TypeScript, the call is equally terse:

import OpenAI from "openai";
const client = new OpenAI({
  baseURL: "https://api.portkey.ai/v1",
  apiKey: "pk-your-portkey-key",
  defaultHeaders: { "x-portkey-provider": "openai" }
});

Portkey documents these extensions; thin gateways often honor a similar shape but with their own header names. The cognitive load is low if you already use the OpenAI SDK.

Ecosystem

Portkey integrates with LangChain, LlamaIndex, and has a Terraform provider for virtual key management. Its dashboard exports metrics to Prometheus and supports webhooks for anomaly alerts. The community maintains SDKs for Node, Python, and Go. This is a managed ecosystem: you adopt their conventions.

The alternative gateway model leans on the existing OpenAI ecosystem. Because it is OpenAI-compatible, every tool that speaks the OpenAI API works unchanged—Vercel AI SDK, LangChain’s ChatOpenAI, or curl. There is no proprietary dashboard; you build observability from provider responses and usage fields. This reduces lock-in but shifts operational burden to your side. Model aliases follow the provider naming or a gateway-specific slug; you can address 240+ models without learning a new abstraction.

Limits

Portkey enforces per-tier rate limits on requests per minute and total monthly requests. Virtual keys can have individual quotas. Exceeding limits returns 429 with a retry-after hint. Enterprise tiers raise these caps and may offer burst allowances.

Thin gateways typically forward provider rate limits and add their own connection caps. Automatic fallback means a 429 from one provider triggers a retry on another model or provider if you configured fallback groups. You still hit the underlying provider’s daily token caps. A misconfigured fallback storm can amplify traffic, so client-side circuit breakers remain wise.

Comparison Table

Which to Choose

Choose Portkey if you are a platform team standardizing LLM access across many developers and need built-in observability, prompt versioning, and policy enforcement. The bundled fee is justified when the alternative is building those systems. For regulated industries, the audit trail alone offsets the markup. If you want to hand non-engineers a prompt editor, it is the faster path.

Choose a thin metered gateway if your service is a single application or a small set of services that already own their LLM orchestration logic. You want one endpoint for 240+ models, automatic fallback on provider errors, and predictable per-token billing without a seat tax. This fits teams who treat the gateway as plumbing, not a control plane. Startups with one production workload and a tight AWS bill will appreciate the lack of recurring platform cost.

For cost-sensitive prototyping, the n4n.ai vs Portkey pricing decision tilts toward the metered pass-through because you avoid recurring fees until you explicitly need enterprise features. For scale with compliance, Portkey’s tiers consolidate spend into a manageable contract and give you a support line.

Pick based on whether the extra gateway features are load-bearing for your architecture or just nice to have. If the features are load-bearing, the fee is a discount on your own engineering time. If they are not, a pass-through gateway keeps your marginal cost equal to the provider’s.