The fields every entry is read into
Every release in this register is read into the same short list of columns: licence, size, hardware, resolution and length. Each page here says why that column exists, what a value in it is quoted from, and which questions it is deliberately no help with. As of 2026-09-12.
A register is only as good as the shape it forces onto what it reads. These columns were chosen because a repository usually states something in them, and because the gaps are informative on the occasions when it does not. A column nobody ever fills is a column that tells you nothing; a column that is full for four vendors and empty for the fifth tells you something about the fifth.
Two of them get confused with each other constantly. Size is a property of a published file. Hardware is a property of a run, and the parameter count predicts the memory figure so poorly here that merging the two would manufacture errors rather than save a column.
Two more are entangled on purpose. Resolution and length both move the memory a run consumes, both are stated by some repositories and skipped by others, and both belong to one model rather than to a family. Each cell therefore carries the release it was stated for, which is why no row here summarises a vendor in a single line.
Licence is the odd one out: the only column whose value is a name rather than a measurement, and the only one where a helpful summary would be worse for the reader than a bare quotation with a link to the file.
1What each column holds, and what it does not
| Field | What the column holds | What it does not settle |
|---|---|---|
| Hardware | Whatever a repository states about running the weights, with the command it applies to | What an hour of that machine costs, or whether the card you own is close enough |
| Length | The clip length a release states, in the unit the repository chose | Whether the output holds together for the length the code accepts |
| Licence | The name on the file that ships beside the weights | What those terms permit for one particular plan in one particular place |
| Resolution | The output size a release states, with the model it belongs to | Whether a larger size is coming, or exists behind a hosted interface |
| Size | The parameter count, attached to the variant it was stated for | The memory a run consumes, which moves with four settings the count cannot see |
Inclusion rule. Fields that appear as a row in the fixed table on a model page. A field only one repository states keeps its row, because the silence of the others is part of the entry. Order. Alphabetical by field name.
2One page per column
- Licence — What the licence column in this register holds: the name on the file shipped beside the weights, the three shapes it takes here, and what it leaves open.
- Size — Why the parameter count gets a column of its own, what each figure is attached to, and why two releases of the same size here need different machines.
- Hardware — What the hardware column holds: figures quoted with the command they belong to, a ladder from four gigabytes to eighty, and why an empty cell stays so.
- Resolution — Why a pixel size appears here for two different reasons, why the vendor's qualifier is kept in the cell, and how it moves the hardware figure beside it.
- Length — Why clip length is kept in whichever unit the vendor published, what a supported length does not promise, and which side here states the longest one.
Between them these pages are the reading instructions for every model entry: what a cell is quoting, what the vendor attached to it, and where an empty one is empty on purpose rather than from neglect.
Also in the register: Models, Hosted, Questions, Learn, Data. What a release has to publish is set out on the reading page.