BigHugger
There's already a model for that. Usually there is already a dataset, a paper that describes it, a repo that implements it, an MCP server that wraps it and a skill that teaches an agent to use it. The problem was never that the thing does not exist. The problem is that finding it means reading ten catalogues that do not agree with each other, and the facts that decide the choice are not written down anywhere at all.
BigHugger is one index over all of those catalogues, with the deciding facts already computed. It is built for the case where the reader is an agent.
Why we built it
An agent picking a model does not browse. It asks a question and needs one answer it can act on, with enough reasoning attached to know whether to trust it. The catalogues were built for a person with a browser and an afternoon: a search box, a list, and a page per item that restates its own readme. Put an agent in front of that and it either guesses from the first page of results or burns its context reading fifty of them.
What an agent needs is what a good colleague gives. Not a list, a recommendation. Not a link, the reasoning. Not a claim, the source. And when the answer is "use this one", not a name but something that runs.
So the index is built the other way round. Every entity carries the facts that were expensive to work out and are never on its own page: what licence a derivative can actually grant, whether a benchmark number was corroborated by anyone independent, which paper a model implements, which servers wrap the same API, and whether the thing will fit on the machine you have. Those facts are computed once, across the whole index, and every answer rests on them.
Why not go to the catalogues yourself
You can. Hugging Face has the models and datasets. The package registries have the libraries. skills.sh has the skills, the MCP registry has the servers, arXiv has the papers and GitHub has the code. Every one of them has a search box and an API, and every one of them is good at the thing it holds. The trouble starts the moment the question spans more than one of them, which is every real question.
"A small speech-to-text model that runs on a phone, with the server that wraps it and a licence I can ship under" is one question. Answering it from the catalogues is six searches, in six vocabularies, with six ideas of what a name is. Nothing in the model catalogue knows which server wraps that model. Nothing in the server registry knows that the model's licence forbids what its readme promises. Nothing anywhere knows whether the benchmark number in the model card was ever reproduced by someone who did not publish the model. You would find those facts by opening each page, reading it, and holding the whole thing in your head. An agent doing the same holds it in its context window, and pays for every page.
The catalogues also only know what they were told. A model card says what its author chose to say, in the order they chose, and says nothing about what the thing is for or what it beats. A skill is a README and a directory. A server lists its tools in prose that has to be read to be used. Each is a primary source and none of them is an answer.
BigHugger reads all of them, every night, into one vocabulary, and does the reading once so that nobody has to do it per question. The facts that decide a choice are computed across the whole index rather than looked up on a page: which entities implement which paper, which wrap the same API, what a licence actually permits downstream, what will run where. That is not a copy of the catalogues. It is the work you would have done after opening them, done in advance, and given back as one answer with the sources attached so you can check it against the catalogues whenever you like.
How it is supposed to help
A question in your own words gets one recommendation. Ask reads the question the way a colleague would. "Small enough for an iPhone" is a constraint on the device, not a subject to search for. "Speech to text" does not come back as text to speech. The answer names one thing, says why, and cites the rows it stands on.
Search is retrieval with no model in the loop. When you already know what you want and need the rows, Search returns them ranked, across every kind of entity at once, with the same query vocabulary Ask uses. A preference reorders results and never removes them, so a narrow query still shows you what it passed over.
An answer can be packed as something that runs. A Workbook is the recommendation made concrete: a notebook, a pinned environment, the exact model file, an MCP server and a SKILL.md, with nothing in it the index did not claim.
Every statement is a claim you can check. The pages in these docs are generated from the behaviours the API is tested against. If a sentence here says the API does something, there is a scenario behind it that runs.
Capabilities
- Ask — Ask a question in the words you would use with a colleague and get one recommendation back, with the reasoning behind it and the sources it rests on.
- How queries are read — Search reads a query before it looks anything up, so a phrase like "small enough for an iPhone" is understood as a constraint on the device rather than as a subject to search for, and "speech to text" does not come back as "text to speech".
- Search — Retrieval across the whole index, with no model in the loop.
- Workbooks — Any answer, packed as something that runs: a notebook, a pinned environment, the exact model file, an MCP server and a SKILL.md.
How a question moves through it
Every call takes the same path. The question is read for intent before anything is looked up. Retrieval runs over the whole index and returns candidates. Ask reranks those against the question and writes an answer on top of them; Search stops at the ranked rows. A Workbook is built only from what the answer cited.
graph LR
q("Your question")
i("Read for intent")
r("Retrieve candidates")
s["Ranked rows"]
k("Rerank against the question")
a["Recommendation, reasoning, sources"]
w["Workbook that runs"]
q --> i --> r
r -->|Search| s
r -->|Ask| k --> a
a -.->|optional| w
classDef step fill:#fffdf2,stroke:#eeb900,stroke-width:1px,color:#14161a
classDef out fill:#eef2ff,stroke:#1d4ed8,stroke-width:1px,color:#1d4ed8
class q,i,r,k step
class s,a,w outBehind the index, the corpora are refreshed nightly and the deciding facts are recomputed with them, so an answer given today is given over today's catalogues.