A narrower catalogue, served direct, with no platform fee

Start with where they are better

If you need broad access to closed-source frontier models — GPT, Claude, Gemini — alongside open ones, all through a single router with automatic provider fallback, OpenRouter is genuinely the better fit. That is not what we are built for, and a router with 500 models and multi-provider redundancy solves a real problem that our 22-model catalog does not. If your architecture depends on failing over between providers when one degrades, choose them.

That paragraph is the first thing on this page rather than a concession buried at the bottom, because a comparison table that favours the author in every row is recognisable as marketing before the second row and the reader discounts the whole thing. If you need closed frontier models, or multi-provider failover on a single model id, the rest of this page will not change your mind and should not.

What follows is the narrower case: the specific circumstances in which routing open-weight traffic directly is better than routing it through a general-purpose router, and the specific numbers that make it so.

Where the difference shows up

Two structural differences move money. The first is the fee on credit purchases, which does not appear on a per-model pricing table and is therefore easy to leave out of a comparison. The second is cached input, which is surfaced uniformly here as its own column and varies by upstream elsewhere.

On the rate card itself, every model below is priced 36–42% below what its own publisher charges. GLM-5.2 runs $0.82/M input and $2.55/M output against the publisher's $1.40/M and $4.40/M, with cached input at $0.16/M.

This table is maintained in the same file the comparison pages read from, so it cannot drift from what we say elsewhere. Where a row favours them, it says so.

Price your open-weight traffic

The comparison worth running is not vendor against vendor in the abstract; it is the portion of your traffic that already runs on an open-weight model, priced both ways. Enter that volume and the calculator prices it across every model we serve.

Where we hold a verified third-party rate for a model, it appears in the result alongside the publisher's rate, so the comparison is against a real number rather than a characterisation of one.

Moving one route rather than everything

There is no requirement to consolidate. Both endpoints are OpenAI-compatible, so running open-weight traffic here and everything else where it is now costs one extra client instance.

1. 1

   Split the traffic by model, not by vendor

   Point the open-weight calls at this base URL and leave the closed-model calls where they are. This is usually the correct end state rather than a migration step, because the two categories have genuinely different requirements.

2. 2

   Map the ids

   Ids here are namespaced by publisher — z-ai/glm-5.2, moonshotai/kimi-k3 — and the bare model name resolves too. 7 of 24 catalogued models are callable today and the table above says which, so the mapping is checkable before any code is written.

3. 3

   Compare the invoice, not the rate card

   Run both for a billing cycle and compare the totals, including anything added at the credit-purchase step. A per-model rate table is not an invoice, and the difference between them is exactly the thing this comparison is about.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://router.xark.io/api/v1"   # ← the only line that changes
)

response = client.chat.completions.create(
    model="z-ai/glm-5.2",
    messages=[{"role": "user", "content": "Hello"}]
)

Nothing has to be consolidated for this to be worth doing. A split by model category is a stable architecture, not a halfway state.

Where this is the better fit

If you are specifically working with open-weight models and want the lowest total cost with fully published pricing — no platform fee on top, cached input visible before you commit, and video models treated as a real category rather than something we do not carry — that is exactly what we built this for.

No platform fee

The per-model rate is the whole price. Nothing is added at the credit-purchase step, which is the line item most often missing from a provider comparison because it does not appear on a per-model pricing table.

Cached input as a published column

Every model's cached rate is on the pricing table rather than varying by upstream. On a repeated-prefix workload that column is the bill: the discount moves from 36–42% to 65–68% on 400M input tokens a month with a 60% repeated prefix, and 8M output.

The publisher's rate on every row

Ours and theirs, side by side, so the claim is verifiable against a public page rather than accepted. We are not claiming to be the lowest price available anywhere; we are claiming to be below the publisher's own, which is a claim that can be checked.

Direct rather than routed

Requests go to our own inference rather than through a routing hop to a third-party upstream. The trade-off is the honest one in the table above: no multi-provider failover on a single model id.

The trade-offs, stated plainly

A narrower catalogue is a real cost and pretending otherwise would make the rest of this page worth less. Three things you give up, in the order they are likely to matter.

Catalogue breadth

7 models callable of 24 catalogued, all open-weight. A router carrying hundreds of models across many providers solves a discovery problem this does not.

Provider redundancy

One provider per model. If your architecture depends on failing over between upstreams when one degrades, that is a genuine reason to choose a router instead, and it is listed as a row they win.

Closed frontier models

Not offered, and not coming. No licence exists that would permit reselling them, which is the same reason the price difference on open weights is possible at all.

Comparison questions

Answered against the same competitor file the comparison pages use, so nothing here can disagree with what we say elsewhere.