n4n vs Portkey for OpenAI-compatible routing

When you need a single OpenAI-compatible endpoint to fan out across providers, the debate of n4n vs Portkey OpenAI-compatible routing comes down to how each gateway handles fallback, metering, and routing control. Both sit in front of model providers and speak the OpenAI chat protocol, but they make different tradeoffs in abstraction, observability, and operational transparency.

Capabilities

n4n provides one OpenAI-compatible endpoint that addresses 240+ models. It performs automatic fallback when a provider is rate-limited or degraded, and it honors client routing directives while forwarding provider cache-control hints. That means you can pin a request to a specific provider or let the gateway decide based on health. n4n.ai documents this as a protocol-first design: the gateway does not reshape requests beyond what the OpenAI schema allows.

Portkey offers a unified API with virtual keys, load balancing across providers, fallback chains, and a gateway-side caching layer. It also ships observability features: request logs, latency metrics, and prompt versioning. Where n4n stays close to the wire, Portkey builds a control plane with extra metadata and a web console.

Both accept the standard chat.completions.create call. The difference is what happens after the request leaves your process. With n4n you optionally attach a routing block; with Portkey you often pre-configure routes in the dashboard.

from openai import OpenAI

# n4n routing: one endpoint, optional route hint in body
n4n_client = OpenAI(
    base_url="https://api.n4n.ai/v1",
    api_key="sk-your-key"
)
resp = n4n_client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "ping"}],
    extra_body={"route": {"primary": "openai", "fallback": ["anthropic"]}}
)

# Portkey routing: virtual key in header, SDK handles fallback
portkey_client = OpenAI(
    base_url="https://api.portkey.ai/v1",
    api_key="pk-your-virtual-key"
)
resp = portkey_client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "ping"}]
)

Cost Model

n4n meters per token and forwards provider billing without a separate routing subscription. You pay the underlying model provider’s price; the gateway adds metering but no opaque markup beyond its own stated margin. This keeps cost predictable when you already have provider accounts and negotiate enterprise rates directly.

Portkey uses a platform model: a free tier with limited requests, then paid plans that charge either per request or a percentage of your LLM spend. For teams that want a single invoice and centralized budget controls, that can simplify accounting. For high-volume workloads, the percentage fee compounds and should be modeled against your provider bill.

Neither approach is universally cheaper. If you run $50k/month through models, a 0.5–1% platform fee is real money; if you want finance to see one line item, Portkey wins. n4n wins when you already have provider contracts and hate surprises.

Latency and Throughput

Latency in any gateway is dominated by the upstream model, not the proxy. n4n’s automatic fallback adds a health check and possible retry, which can improve tail latency when a provider degrades. Portkey’s load balancing similarly spreads load but introduces a control-plane hop for route resolution.

In practice, both add single-digit millisecond overhead on the request path when measured in-region. Throughput is bounded by provider quotas; gateways mitigate throttling via fallback rather than magically increasing capacity. Connection pooling and HTTP/2 support are table stakes—both do it.

A concrete pattern for reducing p99 with n4n: send a routing hint to prefer a primary provider but allow fallback.

{
  "model": "claude-3-5-sonnet",
  "messages": [{"role": "user", "content": "Summarize this"}],
  "route": {
    "primary": "anthropic",
    "fallback": ["aws-bedrock", "azure"]
  }
}

Portkey expresses similar intent via a route object in its SDK or a header like x-portkey-route. The semantics differ but the outcome is comparable.

Ergonomics

Ergonomics is where the philosophies diverge. n4n expects you to speak OpenAI protocol and optionally pass routing directives. There is no dashboard required to get a request through. You can be live in five lines of code with an existing OpenAI client.

Portkey asks you to create virtual keys and often adopt its SDK for full feature access. The tradeoff is richer metadata in return—but you now manage another credential layer and possibly a config file.

A curl example against n4n with a cache-control hint:

curl https://api.n4n.ai/v1/chat/completions \
  -H "Authorization: Bearer $N4N_KEY" \
  -H "X-Cache-Control: max-age=3600" \
  -d '{"model":"claude-3-5-sonnet","messages":[{"role":"user","content":"Hello"}]}'

Portkey would require a x-portkey-api-key and possibly a x-portkey-route header. If your codebase already uses the OpenAI client, both are drop-in. The difference is the surrounding tooling and whether you must touch a UI to rotate a key.

Ecosystem and Integrations

Portkey has invested in integrations: LangChain callbacks, a web app for prompt management, and analytics exports. If you want to treat LLM calls like managed services with dashboards, it fits. You can trace a request from a LangChain chain to a token breakdown without leaving their product.

n4n keeps the surface area small: one endpoint, standard protocol, routing headers. It does not ship a prompt IDE. That is deliberate—the goal is to be an inference gateway, not an LLMOps suite. For teams embedding LLM calls in existing microservices, the lack of mandatory UI is a feature. Any tool that speaks OpenAI works unchanged.

Limits and Constraints

Portkey’s free tier enforces rate limits and caps on monthly requests; enterprise plans lift them. n4n’s limits are those of the upstream providers, with the gateway stepping in only when a provider returns 429 or 5xx.

A hard limit to note: n4n forwards cache-control but does not guarantee cache hits across providers, since each provider implements caching differently. Portkey’s cache is gateway-side and works across providers but may serve stale completions if misconfigured. Both require you to understand provider quotas; neither eliminates them.

Head-to-Head Comparison

Which to Choose

Choose n4n if: You want a thin OpenAI-compatible routing layer that respects your existing provider accounts, gives you per-token metering, and gets out of the way. It fits teams who treat the gateway as plumbing and need automatic fallback without adopting a new control plane. If you already have negotiated Azure OpenAI or Anthropic rates, n4n forwards those without a markup layer.

Choose Portkey if: You need centralized observability, prompt versioning, and are comfortable with a platform fee. It suits orgs that want one pane of glass for all LLM traffic and are willing to manage virtual keys and route configs in a dashboard.

For latency-sensitive proxy workloads: Both add negligible overhead; pick based on fallback policy. n4n’s automatic degradation handling is simpler to configure—ship a header, not a dashboard.

For cost-auditing teams: n4n’s per-token pass-through avoids percentage fees; Portkey’s consolidated invoice may save finance overhead but costs a slice of spend.

The n4n vs Portkey OpenAI-compatible routing decision is less about features and more about how much stack you want above the protocol. If you want the wire, use n4n. If you want the dashboard, use Portkey.