Downloading a model
Open a model page and press Download. The file saves under a name that identifies the model — all-MiniLM-L6-v2.safetensors rather than the model.safetensors that almost every repository calls its weights — so several models can live in one folder without colliding.
From a terminal, the same thing:
curl -L -O -J https://tinymodels.co/models/all-minilm-l6-v2/download
What actually happens when you ask for that URL: this hub answers with a redirect to the publisher's own copy, and your bytes come from them, not from us. Read why the files aren't hosted here before you decide that is a problem — it is also why the hub costs nothing to run.
Add ?info=1 to the download URL for a page rather than the file, which shows the expected digest, the byte count and where the bytes will come from.
Verifying a download
The weights arrive over the network from a third party. A digest is how you confirm that what landed on your disk is the artifact this catalogue describes, and not a truncated download, a proxy's error page, or something substituted in transit.
Every model page states its sha256 and says where that number came from. The same fact is available three ways:
- /models/<slug>/checksum — a page you can read
- /models/<slug>/checksum?format=txt — a sha256sum-compatible line
- /models/<slug>/checksum?format=json — the same fields as JSON
The digest also rides on the redirect as the x-checksum-sha256 response header, so you can read it before you commit to downloading anything:
curl -sI https://tinymodels.co/models/all-minilm-l6-v2/download | grep -i x-checksum-sha256 # x-checksum-sha256: 53aa51172d142c89d9012cce15ae4d6cc0ca6895895114379cacb4fab128d9db
Careful with that header: it is set on the 302, so a client that follows redirects never sees it. That is why the digest is also published in the catalogue and at the checksum endpoints, and why you should trust those rather than a header.
The mechanical way
Fetch the file, fetch the expected line, and let the tool compare them — no eyeballing a 64-character string:
SLUG=all-minilm-l6-v2 curl -L -o "$SLUG.safetensors" https://tinymodels.co/models/$SLUG/download curl -s https://tinymodels.co/models/$SLUG/checksum?format=txt -o "$SLUG.sha256" shasum -a 256 -c "$SLUG.sha256" # macOS sha256sum -c "$SLUG.sha256" # Linux # all-MiniLM-L6-v2.safetensors: OK
If the file saves under a different name than the checksum line expects, rename one to match, or pass the file explicitly: shasum -a 256 all-MiniLM-L6-v2.safetensors and compare against the model page.
What a matching digest proves
It proves the bytes you hold are the bytes the publisher published, unaltered. It does not prove the model is accurate, safe, well trained or honestly described. A malicious repository has a perfectly valid sha256. Verification tells you that you got what was advertised; it says nothing about whether the advertisement is any good.
Why the files aren't hosted here
This hub is a catalogue, not a mirror. It stores no model weights. Every entry points at the publisher's own repository, and the download URL forwards you there.
That is a deliberate position, and it has consequences worth knowing:
- The digest is the publisher's. For every entry here, the sha256 is the publisher's own record of that exact file — Hugging Face's LFS object id — not a number this site computed. If a publisher replaces a file, the entry here is stale until it is re-checked; bun run verify-seed in the repository does that re-check against the publisher's API.
- Availability is the publisher's, not ours. If a repository disappears, the entry here becomes a dead link. Nothing is cached, so there is no second copy to fall back on.
- Nothing here can be written to. There is no upload, no account and no write path of any kind. The catalogue changes only when the code in the repository changes.
- Licences are the publisher's. Each model page states the licence the publisher declares. Some are permissive (Apache-2.0, MIT); some are not — MCG-NJU/videomae-base-finetuned-kinetics is CC BY-NC 4.0, which is non-commercial. Check before you build on something.
What the benchmark numbers mean
The catalogue list carries one number per model, in one unit: milliseconds for one fixed input, named in the column label. One input per task type — a 64-token reply to a fixed prompt, a fixed 24-word sentence, one 640x480 photo, one clip of 16 frames — so a language model, an embedding model, a classifier, an object detector and a video model all end up with a number of the same kind.
Every row is measured by this hub, on the same machine, the same way: one warm-up run, then one timed run, with the toolchain that model's format implies (mlx-lm for MLX and bf16 safetensors on this hardware, llama.cpp for GGUF, transformers for everything else). The line under each figure names the input and the runtime, and the machine is named under the list. The harness is scripts/measure.py, and the results it produced are committed in seed/measured.json — refresh them with bun run measure.
These are state-of-one-laptop numbers, not a leaderboard. One run each, no batching, no quantisation tuning, no serving stack. They answer "how long does this model take on this shape of work on this machine", which is the question a catalogue of tiny models exists to answer. Treat a factor of two between two rows as noise.
Every other figure — accuracy, mAP, CIDEr, sentences per second, published tokens per second — stays on the model page, in its own units, with what it ran on and a link to wherever it was published. Those numbers are not comparable with each other and they are not in the list. Nothing here is estimated or extrapolated: a figure was either published by somebody or measured here, and the row says which.
Command line
There is no tm command line yet. It is the next thing worth building, and this page will document it when it exists rather than describing it in advance. What exists today is a read-only HTTP API, so a shell script or a few curl calls do the whole job:
# what is in the catalogue
curl -s 'https://tinymodels.co/api/models?task=video-classification' | jq '.models[].slug'
# the facts for one model, including the digest and both filenames
curl -s https://tinymodels.co/api/models/all-minilm-l6-v2 | jq '{slug, sha256, file, download_filename}'
# download and verify in one go
SLUG=all-minilm-l6-v2
curl -L -o "$SLUG.safetensors" https://tinymodels.co/models/$SLUG/download
curl -s https://tinymodels.co/models/$SLUG/checksum?format=txt | shasum -a 256 -c -
What a tm client would add over that, when it is written: verification on by default rather than as a separate step, a content-addressed local cache so the same weights are stored once across models and revisions, and an offline tm verify that works against a saved .sha256 file without a network at all.
The API
Read-only, JSON, no key and no account. The full reference, with every field and an example response, is at /api. In short, the same filters the browse page offers:
- GET /api/models — ?q= (name, summary and full card text), ?task=, ?format=, ?licence=, ?size= (one of under-100mb, 100mb-500mb, 500mb-1gb, over-1gb), ?sort= (recency, downloads, size-asc, size-desc), ?limit= (max 100, default 24), ?offset=
- GET /api/models/<slug> — one entry, including sha256, file, download_filename and upstream
- GET /health — model count, port, uptime
Every write is a 404. The only endpoints that exist are the ones above, the catalogue pages, the checksum endpoints and the download redirect.
Running your own copy
The whole hub is one Bun process with no runtime dependencies: SQLite for metadata, the filesystem for nothing at all, and server-rendered HTML.
git clone https://github.com/mrsage-AI/tinymodels cd tinymodels bun run seed # populate the catalogue from seed/catalog.ts bun run start # http://127.0.0.1:8788
It deploys as a container to anything that runs one; Dockerfile and railway.json are in the repository and bun run serve is the entrypoint, which seeds the catalogue on boot and then serves. Because nothing is stored, a deploy needs no volume and no database service — just a process.
The catalogue is the code: to add a model, add a row to seed/catalog.ts and a card to seed/cards/, then re-run the seed. There is no admin interface, because there is nothing to administer.