The useful question about AI models is not "what models exist". It is "who serves this model, and what do they charge". Those are different questions, and only one of them has a good answer on the open web.
models.dev is an open, community maintained database of models, their capabilities and their prices. MIT licensed, keyless, and published as plain JSON. I just pulled the whole thing into nichedb.dev as a collection you can read by API, CLI or MCP: nichedb.dev/c/models.
Why a row is an offering, not a model
models.dev publishes the same database two ways, and the difference decides the shape of everything downstream.
api.json?type=all is keyed by provider. Each entry is a provider, carrying the models that provider serves, at that provider's prices.
catalog.json?type=all carries those same providers plus a second half: the lab catalogue, one entry per model as its maker published it, keyed lab/slug.
The same model reaches you from many providers at as many prices. So the unit worth storing is the offering, the pair of provider and model, not the model on its own. That is what the bulk of the collection is: 8,179 offerings across 223 providers.
The lab catalogue is the other half, 428 models, and it is the only half with a page of its own on the site. A provider's offering has no URL but the provider's own documentation.
What each row carries
For an offering: the price per million tokens in, out, cache read and cache write. The context and output limits. Input and output modalities. Whether it reasons, calls tools, returns structured output, takes attachments, honours temperature or ships open weights. Plus the provider itself, its documentation, its npm package and the environment variables it expects.
For a provider: the size of its catalogue, how many of those models are free, and when the catalogue last changed.
Capabilities are stored as tags, so a feed can be "everything that calls tools" without the query language needing to know what a model is. There are seven feeds: prices, open weights, free, tool calling, reasoning, the lab catalogue, and the providers.
Two things that would have quietly broken it
A published price of zero is a fact, not a missing value. 638 of the 8,179 offerings genuinely cost nothing. The reflexive idiom for a nullable number is cost.input || null, and that one line would have erased every free model in the database, because zero is falsy. Free has to mean a published zero in and out. A separate 424 offerings publish no price at all, and those are not free, they are unknown. Collapsing those two states is how a pricing dataset starts lying.
A provider has no date of its own. Every row in the collection sorts by a date, and a provider is not published on a day. If you leave that null, 223 rows sink to the bottom of the collection forever. Each provider borrows the newest date in its own catalogue instead, which is a real fact about it: the last time anything it serves changed.
There is a third one worth naming for anyone else reading this API. Per model page URLs on models.dev are keyed by lab, not by provider. Anything else redirects to the root, so a provider's model id cannot be turned into a page by string surgery. Only the catalogue half gets real pages.
Reading it
The collection is free and needs no key, like the rest of nichedb.
curl 'https://nichedb.dev/api/v1/items?collection=models&tags=free&limit=5'
curl 'https://nichedb.dev/api/v1/items?collection=models&kind=provider&limit=5'
Or npm i -g @profullstack/nichedb and read it from the CLI, or point an agent at the MCP endpoint.
Both sources refresh daily. The upstream is a build artefact of a git repository rather than a live feed, so daily is as fresh as the data gets.
Top comments (0)