n4n vs Portkey: pricing models compared

Understanding n4n vs Portkey pricing is critical before you commit to a gateway for production LLM traffic. Both sit in front of model providers and normalize access through an OpenAI-compatible interface, but they bundle observability, routing, and billing in different ways that directly affect your marginal cost as request volume grows.

Capabilities

A gateway’s feature set determines how much logic you push to the edge versus your own code. Portkey ships virtual keys, prompt versioning, experiment grids, and a observability dashboard that logs every request. You can route by latency, cost, or fallback chains defined in its config.

n4n focuses on being a thin, high-coverage inference router. It exposes one OpenAI-compatible endpoint that addresses 240+ models, performs automatic fallback when a provider is rate-limited or degraded, and honors client routing directives. It also forwards provider cache-control hints so you don’t lose prompt caching discounts when switching backends.

The capability split is clear: Portkey is a control plane with management UI; n4n is a traffic plane with maximal model reach.

Price and Cost Model

This is where the n4n vs Portkey pricing question gets concrete. Portkey bills you in two layers: you pay the model provider directly (or via Portkey’s aggregated invoicing on some plans), and Portkey adds a platform fee. That fee is structured as a free tier (limited requests/month) then usage-based or seat-based pricing depending on the plan. You feel the gateway cost as a separate line item or a per-request surcharge.

n4n collapses the billing. It uses per-token usage metering against a single account balance. You do not receive separate provider invoices; the token count at each provider’s rate is aggregated into one meter. There is no per-request platform tax—cost scales with tokens processed, not with calls made.

If you fire 10 tiny requests that each use 1 token, Portkey’s per-request model may cost more relative to tokens than n4n’s per-token model. Conversely, if you send few massive documents, the delta narrows.

# Cost visibility differs in shape
# n4n: usage object reports token counts per provider model
resp = client.chat.completions.create(
    model="anthropic/claude-3.5-sonnet",
    messages=[{"role": "user", "content": "hi"}]
)
print(resp.usage.total_tokens)  # billed via n4n meter

# Portkey: you still see token usage, but platform fee applied elsewhere
# based on request count or plan

Latency and Throughput

Both gateways add single-digit millisecond overhead when deployed in the same region as your app. The real latency variable is fallback behavior. Portkey’s retry chains can introduce seconds if a primary provider is down and it sequentially tries backups. n4n’s automatic fallback triggers on rate-limit or degradation signals and swaps to a healthy provider mid-call, but you must design idempotency for partial streams.

Throughput is bounded by the underlying provider, not the gateway, once connection pooling is tuned. Neither imposes a hard throughput cap below provider limits on standard plans.

Ergonomics

Portkey requires you to manage virtual keys—one per provider credential—and pass them as headers or in config:

curl https://api.portkey.ai/v1/chat/completions \
  -H "x-portkey-api-key: $PK_KEY" \
  -H "x-portkey-virtual-key: $OPENAI_VK" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"hello"}]}'

n4n uses a single API key and routes by model alias in the request body. n4n.ai exposes the endpoint as a drop-in replacement for the OpenAI base URL:

curl https://api.n4n.ai/v1/chat/completions \
  -H "Authorization: Bearer $N4N_KEY" \
  -d '{"model":"openai/gpt-4o","messages":[{"role":"user","content":"hello"}]}'

For a team already using the OpenAI SDK, n4n is a one-line base_url change. Portkey needs header injection or its own SDK wrapper to fully use virtual keys and tracing.

Ecosystem

Portkey has a broader ecosystem of integrations: LangChain callbacks, Boltic workflows, and a template marketplace. Its community ships recipe repos for evaluation and guardrails.

n4n’s ecosystem is the model catalog itself—240+ models behind one contract—plus standard OpenAI-tooling compatibility. You get fallback and cache hint forwarding, but not a prompt CMS. If your stack is Python + OpenAI SDK + your own eval harness, that is enough.

Limits

Portkey’s free tier caps monthly requests; paid tiers raise that and add SSO. Model coverage depends on which virtual keys you provision—you are limited to providers you manually connect.

n4n’s limit is account-level token quota, not request count. Because it aggregates 240+ models, you are not blocked from a provider due to missing key setup; the gateway holds the credentials.

Head-to-Head Comparison

Which to Choose

Choose n4n if you want one contract, one token meter, and maximal model reach without wiring multiple provider accounts. Teams shipping a single OpenAI-compatible client and needing automatic fallback with cache hint preservation should default here. The n4n vs Portkey pricing gap favors n4n when request counts are high but token counts are low, or when you refuse to reconcile separate provider bills.

Choose Portkey if you need granular governance: per-team virtual keys, prompt versioning, and an observability layer that lives outside your code. Enterprises with negotiated provider discounts who want to keep direct provider relationships and pay a platform fee for control plane features will find the Portkey model natural.

For a seed-stage prototype, n4n’s per-token simplicity gets you to production in an afternoon. For a regulated workflow with audit trails and prompt change management, Portkey’s overhead buys compliance leverage.

Pick based on whether your pain is billing fragmentation or operational visibility—not on raw model access, since both reach the major labs.