Model catalog
The set of models the network knows how to serve, and how the catalog is maintained.The model catalog is the authoritative list of models the network is willing to route requests to — including their canonical MLX model IDs, weight hashes, memory requirements, and rate-card entries.
What the catalog contains
For each catalog entry:Currently shipping
The v0 catalog covers the MLX-native OSS frontier, tier-matched to Apple Silicon RAM:
Full live list:
GET /v1/models (only models with at least one warm provider) and GET /v1/rate-card (per-model pricing).
Catalog distribution
The catalog is served as a signed static feed off the release infrastructure. Providers pull it on install and on autoupdate. Signature verification anchors:- Which models are eligible to serve.
- Which weight hashes count as canonical (receipts referencing an off-catalog
model_hashverifyinvalid). - Which templates are marked tool-calling / structured-output capable.
Adding a model
Adding a new model to the catalog is an operator action. Steps:- Publish MLX weight files with a canonical SHA-256.
- Add a catalog entry with
model_id,model_hash, RAM tier, and rate card. - Sign and publish the updated catalog feed.
- Existing providers pick up the update on next autoupdate cycle; new installs get it directly.
MalibuAI/malibu with the model ID, weight file, and target RAM tier.
Model retirement
Retiring a model means:- Removing it from the signed catalog feed.
- Providers stop advertising it warm on next feed refresh.
- Buyer requests for a retired model return
404 model_not_available.
Receipt binding
Receipts carrymodel_hash, and malibu-verify 1.1.x cross-checks it against the catalog. A valid receipt therefore certifies:
- The signed tuple was produced by the provider’s key.
- The provider claimed to run this specific model file (by hash).
- That file is in the catalog.