Open-weight or frontier: how to decide

The question is not which is better

Framed as open versus closed, the argument is unwinnable and mostly aesthetic. Framed as a procurement decision it has a structure, and the structure is that these two options fail in different ways rather than at different quality levels.

A closed frontier model can be deprecated, repriced or restricted, and you have no recourse because you never held the weights. An open-weight model can be behind on a capability you need, and no amount of price advantage fixes that. Those are the two real risks, and which one you can absorb is a fact about your product, not about the models.

We sell one side of this and it would be silly to pretend otherwise. What follows is written to be usable by someone who reads it and goes elsewhere, because the alternative -- a framework engineered to produce one answer -- is recognisable in about two paragraphs and discredits everything around it.

Four questions, in order

Answer them in this order, because the first one can end the decision and the others cannot.

One: does an open-weight model clear your capability floor? Not whether it is as good, but whether it is good enough for the specific task at the specific quality bar you have written down. If you have not written it down, that is the work to do before comparing anything, and an eval suite is how you do it. If nothing open clears the bar, the rest of this page is irrelevant and you should buy the closed model.

Two: what does leaving cost? With open weights the exit is that you can run the same weights somewhere else, including yourself. With a closed model there is no exit; there is only a migration to a different closed model, with a full re-evaluation and a prompt rewrite. Price that migration once and it usually changes how much a per-token discount is worth to you.

Three: what does the licence oblige you to do? This is the question people skip and then discover during a launch review. Of our 24 catalogued models, 18 are plain Apache 2.0 or MIT with essentially no obligations, two are a modified MIT with an attribution condition above a scale threshold, and four carry bespoke community licences with attribution, naming, acceptable-use or territorial conditions. That distribution is the actual state of the open-weight landscape, not a marketing summary of it.

Four: how much would a unilateral decision hurt? If the model you build on is repriced 40% upward or deprecated with three months' notice, what happens to your product? If the answer is nothing much, closed is fine. If the answer is that your unit economics stop working, that is a structural argument for weights you could in principle run yourself, independent of what anything costs today.

Seven cases where a closed frontier model is the right answer

Each of these is a real reason to go elsewhere, and in every row the elsewhere is named. None of them is something we can approximate today.

What we refuse to sell, and what that refusal costs you

There is no gpt-4o here, no claude-*, no gemini-*, at any price. That is a licensing position rather than a catalogue gap: third-party resale of closed-weight model access routinely violates the origin provider's terms, and a gateway advertising Sora or Veo is either misrepresenting what it serves or serving it in breach of somebody's terms.

The refusal list is code rather than prose -- five entries, each with its reason, rendered verbatim on the site. Naming the specific models is more convincing than a compliance paragraph, and it is checkable in a way a paragraph is not.

The cost of that position falls on you in one concrete place: fallback chains break loudly. If your error handler drops to a closed model when the primary fails, that fallback now returns 404 with code model_not_found rather than silently working. Loud is the right failure -- the alternative is a fallback path that looks healthy in staging and is never exercised until an incident -- but it is a real edit to make during a migration rather than a footnote.

Availability is part of the decision, and ours is limited

The catalogue describes 24 models. Seven are callable today: five text models, one image model and one embedding model. The other 17 have no configured upstream, including every video model, and they are marked as such on the model pages and in the models endpoint rather than left to fail at the moment of use.

That is a genuine limitation and it belongs in a decision framework rather than in a footnote. If your shortlist includes Llama 4 Maverick, Qwen3 Max, Mistral Large 3 or GPT-OSS 120B, they are catalogued here at a published rate and they are not servable here today. A provider with a broader live catalogue -- Novita with 200+ models, SiliconFlow with 200+, Replicate with thousands -- is the better answer for anyone who needs breadth now.

Check the models endpoint before you build against any specific model. It is unauthenticated, CORS-open and returns the current lineup, which makes it the honest answer rather than a page someone updates when they remember.

# What is actually callable, right now. No key required.
curl -s https://router.xark.io/api/v1/models | jq -r '.data[] | .id'

# Gate a deployment on the licence rather than on a memo.
curl -s https://router.xark.io/api/v1/models \
  | jq -r '.data[] | select(.license == "Apache 2.0" or .license == "MIT") | .id'

What open weights buy that a price cut cannot

Three properties, and only the third is about money.

The exit exists. The same weights run on another provider, on your own GPUs, or on a laptop for the small ones. That is not a threat you make to a vendor; it is a constraint on how badly any single vendor's decision can hurt you, and it holds whether or not you ever use it.

The licence is a field, not a footnote. Every model record carries its licence as structured data, so the models endpoint returns it and a build step can gate on it. That is the difference between a compliance page and a compliance control -- a procurement reviewer asking which of these are Apache 2.0 should answer it in one query rather than one meeting.

And the pricing is checkable. Our rate is published next to the model publisher's own official rate on every row, which is only possible because the publisher publishes one. A closed model has no second number to check against, so its price is whatever it is announced to be.

The money, stated precisely

Across the seven models callable today the reduction against each publisher's official rate runs from 36% to 42%, blended one-to-three in favour of output because real workloads write far more than they read. The claim is that specific one -- below the model publisher's official rate, with no fee on top -- and not that this is the cheapest inference available.

It is not the cheapest, and the comparison pages on this site say so model by model. DeepInfra is frequently the lowest published rate on open text models and runs its own GPU fleet at real scale. SiliconFlow's published rates on GLM and Kimi models are genuinely aggressive. Novita prices small models at the market floor. If per-token rate is the only axis you care about, check those three against this table before you decide.

A worked decision

A team building a support-ticket classifier. Capability floor: correctly route 95% of tickets into twelve categories, measured on 1,000 labelled examples. That bar is written down, which already puts them ahead of most.

They run the eval. If an open model clears 95%, question one is settled and the remaining questions are about exit, licence and pricing risk -- all of which favour open weights for a high-volume classification workload where the per-token rate compounds. If nothing open clears it, they buy the closed model and stop reading, because a cheaper wrong answer is not cheaper.

Now the second half, which is the part usually skipped. Classification is one-shot rather than conversational, so there is no repeated prefix and prompt caching is irrelevant to them. The bill is almost entirely input, because the ticket is long and the answer is one word -- which means DeepSeek V4 Flash at $0.09 per million input tokens is a far better fit than a model chosen for its reasoning. And the licence question is trivial: it is MIT.

The general lesson is that the open-versus-closed decision and the which-model decision are different decisions, and doing them in that order saves a lot of re-work. Most teams do the second one first, on vibes, and then argue about the first one.

The honest summary

Buy the closed frontier model when your capability floor requires it, when a compliance questionnaire gates the deployment, when you need failover or fine-tuning or a signed SLA, or when latency is the product. Those are real requirements and they are not ones we meet.

Buy open weights when the capability floor is cleared, when the exit is worth something to you, when the licence review has to terminate, and when the workload is large enough that a 36% to 42% reduction against the publisher's own rate is a number that matters.

And check availability before either. Seven of our 24 catalogued models are callable today, which is the most important caveat on this page and the one most easily verified: the models endpoint answers it without a key.