n4nAI

What you lose calling providers directly without a gateway

Calling providers directly without a gateway seems simpler but costs you fallback, unified billing, and cache control. Here's the head-to-head.

n4n Team4 min read915 words

Audio narration

Coming soon — every post will get a voice note here.

When you start shipping LLM features, calling providers directly without a gateway looks like the path of least resistance: a single API key, a curl call, done. But that choice quietly trades away fallback routing, centralized metering, and provider cache hints that become critical at scale.

Capabilities

Calling providers directly without a gateway ties you to one vendor’s schema and model catalog. You call api.openai.com for GPT, api.anthropic.com for Claude, each with different request shapes, streaming formats, and error codes. There is no automatic failover if a provider returns 429 or 503.

An inference gateway abstracts those differences behind a single OpenAI-compatible interface. For example, n4n.ai exposes one endpoint that addresses 240+ models and honors client routing directives, forwarding provider cache-control hints so you keep prompt caching discounts across backends.

# Direct: OpenAI only
import openai
client = openai.OpenAI(api_key="sk-...")
resp = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hi"}]
)

# Gateway: any provider, same shape
gw = openai.OpenAI(base_url="https://api.n4n.ai/v1", api_key="gw-...")
resp = gw.chat.completions.create(
    model="anthropic/claude-3.5-sonnet",
    messages=[{"role": "user", "content": "Hi"}]
)

The direct path gives you raw access to provider-specific features (like OpenAI’s structured outputs or Anthropic’s prompt caching headers) but you must code each integration. The gateway path standardizes the surface area, sometimes lagging on newest proprietary fields. If you need anthropic-beta headers today, a gateway may not expose them yet.

Streaming is another gap. Direct OpenAI streams SSE with choices[].delta. Direct Anthropic streams with content_block_delta. A gateway normalizes both to the OpenAI format, saving you a parser per vendor.

Price / Cost Model

When calling providers directly without a gateway, you get separate invoices from each provider, each with its own pricing tiers, free quotas, and currency. Tracking spend means aggregating CSV exports or building a metering pipeline yourself. At two providers that’s annoying; at four it’s a part-time job.

A gateway typically applies per-token usage metering on a single bill. You trade a possible marginal markup for eliminated bookkeeping. For a team running three providers, that consolidation is often worth more than the basis-point premium.

{
  "provider": "openai",
  "model": "gpt-4o",
  "prompt_tokens": 120,
  "completion_tokens": 30,
  "cost_usd": 0.0021
}

That JSON is what you’d emit from your own wrapper if you go direct; a gateway returns it natively in usage metadata. Hidden cost of direct: you also pay engineering time to handle billing surprises when a provider changes price mid-month.

Latency / Throughput

Direct calls have one network hop: your service to the provider edge. If the provider is healthy, that’s the lowest possible latency. But when a region degrades, your requests queue or fail. You own the timeout.

A gateway adds a proxy hop, but can route around degradation. If us-east-1 is saturated on Anthropic, the gateway can shift to eu-west or a secondary provider with equivalent model. The net latency under incident is lower; the p50 in steady state is a few milliseconds higher.

// Direct: you manage timeout + fallback
const ctrl = new AbortController();
setTimeout(() => ctrl.abort(), 8000);
try {
  return await openai.chat.completions.create({ model: "gpt-4o", signal: ctrl.signal, ... });
} catch (e) {
  if (e.name === "AbortError") return await anthropic.messages.create({ model: "claude-3-5", ... });
}

With a gateway, that abort and fallback lives server-side. You send one request with a routing header.

Ergonomics

Calling providers directly without a gateway means writing retry logic, backoff, and model-parameter translation for each SDK. You maintain a matrix of which models accept temperature=0 vs top_p only. Function-calling schemas differ: OpenAI uses tools, Anthropic uses tools with different shape.

// Direct: hand-rolled fallback
try {
  return await openai.chat.completions.create({ model: "gpt-4o", ... });
} catch (e) {
  if (e.status === 429) return await anthropic.messages.create({ model: "claude-3-5", ... });
}

A gateway moves that logic server-side. You send one request, set a routing header, and the gateway executes fallback. Your codebase shrinks. You also get a single place to inject logging, PII redaction, or prompt guards.

Ecosystem

Provider direct: you get first-class support in their SDK, latest cookbook examples, and native function-calling helpers. But you can’t reuse that code when you switch providers. Your eval harness becomes provider-coupled.

Gateway: OpenAI-compatible means the entire OpenAI toolchain (LangChain, LiteLLM, your own middleware) works unchanged. You can swap model="gpt-4o" for model="mistral/large" without touching calling code. Tooling like prompt validators or token counters that assume OpenAI shapes keep working.

Limits

Every provider enforces rate limits per key, per tier. Direct usage hits those walls hard during traffic spikes. You must implement multi-key rotation or negotiate enterprise limits.

A gateway may impose its own account-level limits, but internally balances across provider keys and regions. The practical ceiling rises. Note: a poorly configured gateway can become a single point of failure—choose one with transparent status and fallback. If you call providers directly without a gateway, you at least have the option to run provider A and B in parallel with your own health checks.

Head-to-Head Table

Dimension Calling providers directly without a gateway Using an inference gateway
Capabilities Single-vendor API, no cross-provider fallback Unified endpoint, automatic fallback, cache hints
Price/cost model Separate invoices, self-metered Per-token metering, single bill
Latency/throughput One hop, no balancing Extra hop, smart routing around incidents
Ergonomics Multiple SDKs, custom retry code One client, server-side fallback
Ecosystem Vendor-specific tooling OpenAI-compatible, 240+ models
Limits Hard per-provider rate caps Gateway balances keys, higher ceiling

Which To Choose

Prototype or hackathon: Call providers directly without a gateway. You’ll use one model, move fast, and avoid another dependency. The lost features don’t matter at 100 requests.

Single-provider production: If you are all-in on OpenAI and never plan to switch, direct calls keep latency minimal and give you earliest access to new parameters. Just build solid retry and metering.

Multi-model or multi-region production: Use a gateway. The moment you need Claude for reasoning and Llama for cheap classification, direct integration doubles your failure modes. A gateway’s fallback and unified billing pay for themselves.

Cost-sensitive at scale: The gateway’s per-token metering and cache-control forwarding (e.g., n4n.ai honors provider cache hints) can lower effective spend by recovering cached token discounts you’d otherwise lose when juggling providers manually.

Calling providers directly without a gateway is a fine starting point. The exit cost is low if you isolate the calls behind a thin client. Do that, and you keep the option to route through a gateway later without rewriting your app.

Tagsdirect-apillm-gatewayreliability

Written by

n4n Team

The team building n4n — a single OpenAI-compatible API in front of 240+ models, with automatic fallback, load balancing and pay-per-token metering.

More from n4n Team →

All n4n vs calling providers directly posts →