Resellers: say whose model you are selling

Name the maker, the model and the version

A seller of someone else's model should name it the way its maker does: the maker, the model family, the size and the exact version, written as one string a buyer could search for. A model sold by several sellers was made by at most one of them, and when each renames it a little, one model looks like several on a comparison table, and a buyer comparing sellers cannot line them up.

The fix costs nothing. Keep your own short name for the API if you need it, and print the maker's full name beside it on the pricing page.

The same goes for a fine-tune of an open model. Name the base model and its version, then say what you changed and who did it, so a buyer can tell a tuned build from the original sold under a new name.

How one model becomes two listings

The ways it happens are small. A size written as 8B on one page and 8 billion on another. An instruct suffix dropped. A version date left off, so a buyer cannot tell whether the row is the model released in spring or its revision in autumn. A seller's own prefix added to the front, so the name sorts away from everyone else selling it.

Each of these leaves a buyer with two rows that might be one model or two. The careful buyer opens both pages to check. The hurried one assumes they differ, compares only the row whose name they recognise, and the seller whose name they did not recognise is not in the comparison at all.

A naming line that works

One pattern reads cleanly: the maker's name, then the family and size exactly as the maker writes them, then the suffix, then the version or release date, then in brackets anything you changed, such as the precision served. Your API identifier goes in its own column. A buyer can copy the first string into a search box and the second into their code.

Keep the string identical everywhere you use it: pricing page, model card, changelog and documentation. A model called one thing on the pricing page and another in the API reference is two names to match, and buyers will not assume they are the same.

If you serve more than one build of a model, such as a full-precision and a quantised one, give each its own row with its own name. Folding them into one row with a note makes the cheaper build look like the only one, or the dearer build look overpriced.

Why the version matters as much as the name

Model makers revise models and keep the family name. A pair of sellers offering the same family at different revisions are selling different things, and a buyer who has tested one revision wants that one. A row without a version is a row the buyer cannot trust for anything except a rough price.

The build also decides memory, and memory decides cost. A 30 billion parameter model in 16-bit needs about 60 GB for its weights alone, before the key-value cache, which grows with context and batch size. In 8-bit it needs about 30 GB. A seller serving a quantised build is selling a different trade-off, and the name should say so.

Licences can also differ by version. A buyer's lawyers check the licence of the exact release, and a row without a version sends them to the maker's site to guess which one you serve.

Say whether the row will move to a newer revision on its own. A buyer who pinned a version expects the row to stay put.

What we do with names

We match a seller's model to other sellers of the same model so they appear together on the token price table. A clear maker, family, size and version makes that match certain. An ambiguous name can end up on a row of its own, which costs the seller left out of the comparison.

If we have matched you to the wrong model, or failed to match you to the right one, a claimed listing can dispute the value with evidence. Your own pricing page naming the model exactly is the evidence a reviewer can check most easily.

Matching is also why a renamed model hurts the seller more than the buyer. The buyer still finds the model at other sellers. The seller whose name did not match is the one missing from the row the buyer reads.

Credit the maker in plain words

A line such as "this model is made by its developer and served by us" tells a buyer which questions to ask whom. Questions about the model's behaviour, licence and training go to the maker. Questions about rates, limits, context served and uptime go to the seller.

Being plain about who made the model costs a seller nothing and saves the buyer an email. It also keeps a seller clear of a quieter risk: a page that reads as if the seller made the model invites questions about training data and licence that only the maker can answer. The models layer lists the makers; the inference API category lists who serves them.

Linking to the maker's own model card from your row is the quickest way to say all of this. It shows the buyer exactly which release you serve and sends questions about the model to the people who can answer them.