The Model Library: How We Pick What We Serve

A model library is not a list; it is a set of promises. Every model we serve is a promise that the weights are the real weights, the price is the real price, and the model will be there tomorrow. A catalog that serves everything is promising everything — and the everything-catalogs are where the surprises live.

Ours is deliberately small: a curated set of models we believe earn their place, with the context windows and per-token rates published next to each one. The curation is the product, not the limitation.

This post is the reasoning behind the shelves: how we pick, why we decline, and what the library is for. It is the platform version of the vendor-checklist post — the same questions, answered about ourselves.

Four filters, in order. The weights must be real and obtainable — a model we cannot serve faithfully is not a candidate. The model must earn its place on quality: it has to be good at something our customers do, not merely new. The economics must work: the model has to be servable at a price that is honest for us and useful for you — the GLM post walked through one such pricing decision in public. And the model must have a future: a catalog entry is a commitment, and we do not commit to models whose maintainers have already moved on.

Notice what is not on the list: hype, leaderboard position, and completeness for its own sake. The library is not trying to be the biggest; it is trying to be the most trustworthy.

And the filters are applied continuously, not once. A model that stops earning its place leaves the shelves — the versioning post covers how we handle the lifecycle of what we serve.

Because serving is a promise, and promises have costs. Every model in the catalog needs capacity, monitoring, documentation, and a pricing decision — and every model is a surface where something can go wrong. A catalog of everything is a catalog where everything is someone's second priority.

There is also a customer cost: choice overload is real, and a library of hundreds of near-identical models offloads the evaluation burden onto the buyer. The eval post's whole argument is that choosing a model is work; a curated catalog does some of that work for you.

And the honesty cost: a catalog that serves everything serves models it cannot vouch for. We would rather say "we do not serve that" than serve it badly.

The most important promise in the library is the simplest: the model you call is the model you think you are calling. The open-model ecosystem has a quiet problem with lookalikes — fine-tunes and merges that borrow a name and differ in the weights — and a catalog's job is to be unambiguous about provenance.

The library states the family, the version, and the context window for every entry, and the ids are the ones the ecosystem actually uses. The GLM post showed what dated, specific pricing looks like; the same specificity applies to identity.

And when the weights change — a new version, a deprecation — the change is announced, not slipped in. The versioning post is the lifecycle; this is the promise the lifecycle protects.

The price next to each model is the price, with the same disciplines the price-list post demands of everyone: per-token, input and output separate, dated, and linked to the source. No blended averages that describe no actual purchase, no promotional rates wearing a list-price costume.

Where our price sits below the provider's list — the GLM post is the public example — the mechanism is stated, not implied. The price-list post's test applies to us too: a low price is only trustworthy if the mechanism that produces it can be named.

And the library is where the calculator reads from. The pricing calculator and the model library are the same data, which means the number you plan with is the number you are billed — the property that makes the calculator worth using.

When you need a model we do not serve, and the need is real — a specific model your pipeline depends on, a niche fine-tune, a research release. A curated catalog is a filter, and filters have false negatives. The honest answer in that case is the dedicated path: your own endpoint serving your own weights, which is exactly what the serving-modes post describes.

It is also the wrong answer if you want the thrill of the new. A curated catalog moves deliberately, and deliberate is slow compared to the firehose. If your evaluation process is "try whatever released this week", the library will feel small.

For everyone else — the teams choosing a model to build on, not a model to admire — the curation is the point. The library is the answer to "what should we actually use", and that question deserves a considered answer.