Weight classes

TinyBrains groups entries by the size of the two files you submit. Admission assigns your class; you do not choose it when you submit. Every active entry carries one rating, on the Open ladder.

The classes are the season’s

A season declares its own size limits, so read them from the season you are entering; this page shows the defaults. The API returns them on every season it reports: GET /v1/games/{game} and GET /v1/games/{game}/seasons both carry a weight_classes table. The site shows them on the home page and beside your entry. A season may also offer only some of the classes. A focused season might run Nano alone, and admission rejects a model that measures into a class the season is not running with CLASS_NOT_OFFERED, a different refusal from being too large for every class.

These are the platform’s starting limits, and a new season takes the previous season’s limits as its default:

The last two columns are the class’s memory. 0 and 0 is no memory, and that is the default.

Limits are inclusive. Under the table above, an entry of 16,384 bytes is Nano and one of 16,385 bytes is Micro. An entry over the largest class the season offers is too large for that season.

Your class limits size and the memory it allows. No class caps compute or rations how much arithmetic your graph may do. The game’s turn deadline bounds that: 1,000 ms for Ants, yours alone, since each seat is its own call. A graph too slow to answer in time misses the turn and takes a strike. Admission reports your inference time on the reference set, and rejects you for time only when its probe at your probe_dims does not fit a turn at all.

The size limits belong to the season, so a class result is comparable within its season, and across seasons only when their limits match. Two seasons with different Nano limits ran two different competitions, and the standings say which limits each one played under.

Memory

A class may let a model carry a memory from one turn to the next. Two numbers in the season’s class table set how much, and on a board of rows × cols cells the cap is

memory_flat_bytes + memory_cell_bytes × rows × cols

A season sets them, and both default to 0, which is no memory: admission refuses a model that declares a memory output in such a class with MEMORY_NOT_ALLOWED. In the API, each entry of a season’s weight_classes carries memory_flat_bytes and memory_cell_bytes beside max_bytes, and an entry without them means 0. The site shows a class’s memory beside its size limit wherever it shows the limit, and the maps page shows what that allows on each board. A season’s classes are fixed once it opens, so a model admitted under a cap plays the whole season under it.

A season may allow at most 262,144 flat bytes and 16 bytes a cell. Admission prices your memory at the smallest board and the largest, as the cap explains, and memory does not count toward your size: your class is still decided by the two files’ bytes.

How many parameters fit

The metric counts raw bytes, with no compression in between, so the number of parameters that fit depends on the dtype you export in:

Exporting float16 weights doubles the model your class holds, at no cost you would notice. Keep the graph’s compute in float32 by casting each initializer back at its use; the runtime folds that cast away when it optimises the plan. You need no new operator, since Cast is on the allowlist. In a measured comparison, the float16 graph chose the same move as the float32 one on every ant of three matches.

Subtract your manifest first. The baselines’ manifest is 930 bytes: 6% of a Nano budget, and negligible in the larger classes.

Two worked examples, from the platform’s own baselines:

The deadline limits a big model before the class does

The table is generous at the top, and the turn is tight. Your seat owns the whole turn: 1,000 ms, one model_infer call per seat with its own deadline. Even so, a fully convolutional network over the largest Ants board runs out of turn long before it runs out of bytes. To fill Mini and above, spend parameters where they cost less per turn: at a reduced resolution, or in a lookup the graph reads without multiplying. A wider copy of the same network runs out of turn first.

A convolution applies every parameter at every cell, so bytes and arithmetic move together, and no tuning separates them: one parameter costs one multiply-accumulate per cell, 2 × cells arithmetic operations, and the kernel size, the grouping and the dtype leave that ratio unchanged. A class cap is a budget in bytes and the turn is a budget in arithmetic, and the two run out at different sizes.

Admission refuses only a model whose probe at its probe_dims takes longer than a turn (PROBE_TOO_SLOW). A model that fits but runs close to the line finds out in play, where each missed turn is a strike.

How admission decides your class

The size metric is bytes(model.onnx) + bytes(manifest.json). Admission chooses the smallest class whose size limit contains that total in the season you submitted to. Admission makes no second check and never moves you to another class for more compute, since a class rations no compute.

Measure the pair’s bytes. An estimate from parameter count misses graph metadata, an exporter’s node names and the manifest’s own length, which all count, and a larger manifest can push an unchanged network into the next class.

The Open ladder

Open is the single rated ladder, and it spans every size. Each entry has one rating on it, and every match updates that one rating, whatever classes it paired.

A weight class is a view of Open: it ranks you among versions in your size class, drawn from the same rating rather than a separate one. So compare entries of different sizes on Open directly, and read a class view to see how you rank among your size peers.

Choosing what to enter

Begin with a model you can train, inspect and run without surprises. Measure size early, leave operation-budget headroom for larger observations, and watch your inference time against the turn deadline. Verify every basic board (together they span the game’s limits) before you optimize for a boundary.

Unused bytes within a class earn no score bonus. Size is the constraint you engineer against, and ranking comes from game results. Compare revisions by both their measured size and their match performance.