Kimi K3 through EvoLink vs OpenRouter

The thirty-second decision

1. Only Kimi models, forever? Go direct to Moonshot (https://api.moonshot.ai/v1). No intermediary, one fewer account. The API guide covers it.
2. K3 alongside GPT, Claude, Gemini? You want a gateway — one key, one balance, model switching as a string change. That's EvoLink or OpenRouter, and the rest of this page is the measured comparison.
3. Already on one of them? Stay unless a row below changes your mind. Switching costs one base_url, one model string — and one field rename, which is the part that bites. See why.

Price: same list rate — different at funding time

Both charge Moonshot's official list rates for kimi-k3 — we read EvoLink's from its docs and OpenRouter's from its models API on 2026-07-18, and cross-checked OpenRouter's per-call usage.cost arithmetic against its list price on our own calls. The difference is what a dollar of yours turns into as credits:

OpenRouter is explicit that it passes provider pricing through without markup — the fee sits at the payment step instead: "5.5% ($0.80 minimum)" by card, "5%" by crypto, per its FAQ (read 2026-07-18; bringing your own provider key costs 5% past 1M requests/month). So the per-token tables match, but every million tokens you buy through OpenRouter by card effectively costs ~5.5% more. EvoLink adds no surcharge on top-ups, and runs periodic bonus-credit promotions on recharges — when one is live, the effective rate tilts further the same direction.

Same list price, then: identical numbers on the invoice line, not in your bank account. The rest of this page compares behaviour.

The reasoning field is named differently — a portability tax, not a landmine

K3 always thinks, and returns its thinking alongside the answer. Moonshot's native field for that is message.reasoning_content — which is what EvoLink passes through unchanged. OpenRouter renames it to its own cross-provider convention:

Let's be precise about when this costs you, because for a fresh integration it usually doesn't: you (or your AI assistant) write against whichever gateway's docs you picked, read the right field name, done. The rename bites in exactly three situations:

• Switching gateways later. The pitch on both sides is "moving is one base_url line" — and for the answer text that's true. Your reasoning handling (thinking display, spinner-until-content logic, reasoning-token diagnostics) reads a field that no longer exists, gets None, and degrades with no error to catch. That is the part the one-line story leaves out.
• Reusing Moonshot-ecosystem code on OpenRouter. Official docs, tutorials, SDK examples, and open-source snippets for Kimi models read reasoning_content. On EvoLink they run unchanged; on OpenRouter that one field comes back empty.
• One codepath, both providers. Fallback routing or A/B across gateways has to read both names on every response.

The dual-path fix is one line:

def get_reasoning(delta):
    # Moonshot / EvoLink use reasoning_content; OpenRouter renames it to reasoning
    return getattr(delta, "reasoning_content", None) or getattr(delta, "reasoning", None)

The rename cuts both ways — code written for OpenRouter's reasoning goes equally blind on Moonshot or EvoLink. The practical asymmetry is about ecosystems, not correctness: EvoLink's shape is Moonshot's shape, so the larger body of Kimi-native code and documentation works there unchanged.

Caching: identical mechanics through both

We sent a fresh ~4.5k-token prefix twice through each gateway. Both hit, and both granted the same 256-token blocks we measured against Moonshot directly — the strongest evidence that both are passing your prompt through to the same cache:

OpenRouter's usage.cost receipts put dollar figures on the same effect: the cold call billed $0.0145, the warm one $0.0026. The 10× cache discount is real through either gateway — and as everywhere on K3, it saves money, not time.

Reliability: what 73 calls showed

Across the day's full suite — latency, caching, long-context, tools, reasoning probes; deliberate error-probes excluded — one transport failure occurred, and it was not on EvoLink's side:

Be honest about the sample: one failure in thirteen runs is not a failure rate, it is an anecdote. What is worth keeping from it is the shape of the failure — the call didn't fail fast, it held the connection for 143 seconds and then died. If you call K3 through any aggregator, set your own client timeout rather than inheriting the gateway's patience, and retry on it.

Latency: two windows, no stable winner

The design controls for time-of-day: each round sends the same prompt to both gateways back-to-back, order alternating — so every round is a head-to-head pair, immune to the hour's load drifting between measurements. We ran two such windows about 90 minutes apart on 2026-07-18: 19 completed pairs.

Window 1 alone reads like an OpenRouter win: 7 of 9 rounds, a 7.4s median edge. Then window 2, same protocol, 90 minutes later: dead even — 5 of 10 rounds each, medians 1.1s apart, this time leaning EvoLink. Combined, OpenRouter took 12 of 19 pairs; a sign test on that split gives p ≈ 0.36 — the kind of edge you get from flipping a fair coin 19 times. Meanwhile individual rounds inside a single window ranged from ~2.6s to ~38s on both routes, and both routes have posted the same fast floor. That is what "dominated by Moonshot-side load, not the gateway hop" looks like in numbers: the swing within either gateway is an order of magnitude larger than any gap between them.

So we won't call a latency winner in either direction — not because the numbers are close in one window (they weren't), but because the ranking failed to survive 90 minutes. If a stable gap emerges across more windows, this section gets a verdict and a date stamp.

Where each one wins

Pick EvoLink when K3 is a first-class citizen in your stack. The case, each point measured above or on its page:

• Moonshot-native responses. reasoning_content, kimi-k3 echo, byte-shape identical to the official docs — code moves between Moonshot direct and EvoLink with only a base_url change, no field renames. Measured.
• Zero transport failures in our suite — 60 calls today without one — vs the one hung-then-dead upstream timeout we saw on OpenRouter's side. Small samples, honestly labelled, but ours.
• A dedicated production endpoint plus a fallback (direct.evolink.ai / api.evolink.ai) — both timed on the latency page.
• Your dollar buys more tokens. Same list rate, but no top-up surcharge (OpenRouter's is 5–5.5%, per its FAQ), plus 10 free credits at signup — no Chinese phone number, no card — and periodic bonus-credit promotions on recharges. GPT, Claude, Gemini, and dozens of mainstream models on the same key.

Pick OpenRouter when its ecosystem is the point — you're already invested in its normalized cross-provider shape, or you want its very long tail of niche models, or you want usage.cost stamping dollars on every response (genuinely convenient; EvoLink has no equivalent field and we'd like one). Its K3 is the real thing at the real price: same cache, single Moonshot upstream, no re-serving.

FAQ

Is Kimi K3 on OpenRouter the same model as on EvoLink?

Yes. OpenRouter lists a single upstream for moonshotai/kimi-k3 — Moonshot AI itself — and our cache test showed both gateways hitting the same 256-token-block cache with matching counts. Same model, same price, different response field names.

Why is my reasoning display empty after switching gateways?

Because the thinking field is named reasoning_content on Moonshot and EvoLink but reasoning on OpenRouter. Code reading one name gets None on the other — with no error. Read both names; snippet above.

Is Kimi K3 cheaper on EvoLink or OpenRouter?

The list rate is identical — $3.00 input, $0.30 cached input, $15.00 output per 1M tokens, verified 2026-07-18 against both — but OpenRouter charges 5.5% (card, $0.80 minimum) or 5% (crypto) when you buy the credits, per its FAQ, while EvoLink top-ups carry no surcharge. Funding by card, the same tokens effectively cost ~5.5% more through OpenRouter.

Which is faster for Kimi K3?

Neither, stably. In paired same-prompt rounds (19 pairs across two windows, 2026-07-18), OpenRouter won window 1 clearly (7 of 9, median 7.4s faster) and window 2 was even (5 of 10, medians 1.1s apart, leaning EvoLink). Combined 12 of 19 gives a sign-test p ≈ 0.36 — indistinguishable from a coin flip. The swing within either route dwarfs the gap between them, because K3's latency is dominated by model-side reasoning and load, not the gateway hop.