The Model Library: How We Pick What We Serve

A model library is more than a list: it is a stack of promises. Every model served 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 believed to earn their place, context windows and per-token rates published beside each. The curation is the product, not the limitation.

This post is the reasoning behind the shelves: how models are picked, why the rest are declined, and what the library is for — the platform version of the vendor-checklist post, the same questions answered about ourselves.

Four filters, applied in order. The weights must be real and obtainable — a model that cannot be served faithfully is not a candidate. The model must earn its place on quality: good at something customers actually do, not merely new. The economics must work: servable at a price honest for the platform and useful for the buyer — 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 commitments are not made to models whose maintainers have already moved on.

Notice what is not on the list: hype, leaderboard position, 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 apply continuously, not once. A model that stops earning its place leaves the shelves — the versioning post covers the lifecycle of what is served.

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

There is a customer cost too: choice overload is real, and a library of hundreds of near-identical models offloads the evaluation burden onto the buyer. The eval post argues 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. Better to say “we do not serve that” than to serve it badly.

The library’s most important promise is its simplest: the model called is the model thought to be called. The open-model ecosystem has a quiet lookalike problem — fine-tunes and merges borrowing a name and differing 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; identity gets the same specificity.

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 beside each model is the price, under the same disciplines the price-list post demands of everyone: per-token, input and output separate, dated, linked to the source. No blended averages describing no actual purchase, no promotional rates wearing a list-price costume.

Where a 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 here too: a low price is only trustworthy if the mechanism producing it can be named.

And the library is where the calculator reads from. The calculator and the model library share one set of data, which means the number planned with is the number billed — the property that makes the calculator worth using.

When a model not served is genuinely needed — a specific model the 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, exactly what the serving-modes post describes.

It is also wrong if the thrill of the new is the point. A curated catalog moves deliberately, and deliberate is slow next to the firehose. An evaluation process of “try whatever released this week” will find the library small.

For everyone else — teams choosing a model to build on, not 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.