​

Model catalog

Which models providers can serve, which are warm now, what they cost, and how the catalog is maintained.

Malibu keeps three lists, each with its own job: A catalog model only routes when an eligible Mac with enough unified memory is online and serving it, and the rate card prices it. Check the live list with the public GET https://api.malibu.tech/v1/status or GET https://api.malibu.tech/v1/stats/models, or the authenticated GET /v1/models, before you depend on a specific ID in production.

​

Signed network catalog (23 September 2026)

The signed network catalog lists 17 models. Each row carries the exact artifact identity (SHA-256) a provider must serve, a minimum unified-memory floor, and benchmark gates. The catalog was re-signed on 23 September 2026 to cover all 17 recommendable models, and that signed catalog is live. Prices are from the live rate card (generated_at 2026-09-22), in USD per million tokens. The minimum-memory column is the catalog floor. A Mac must also meet the row’s memory-bandwidth tier (the two 32B rows need a higher tier than the rest) and its throughput and time-to-first-token gates before autotune recommends it. In practice, an 8 GB Mac serves the 3B row, a 16 GB Mac serves 8B-class rows, 24–32 GB Macs open the 20B–35B rows, and the largest rows need Max or Ultra chips with 80 GB or more. Rate-card IDs are slugs, while chat requests use MLX serve IDs. Map one to the other with the table above. Gemma also has an alias row, gemma-4-26b-a4b-it, at the same price. Rates on the card are credits per million tokens (1,000,000 credits = $1.00, `usd_per_million_credits = 1`). Sticky-conversation cache hits bill at 25$0.50 / $1.00) applies only if no row matches.

​

Which models a provider is recommended

Autotune on the provider picks the best paid row that fits the Mac’s unified memory and clears the benchmark gates. At recommend time the provider downloads the current signed catalog feed from Malibu and checks its signature against keys compiled into the release. It falls back to the copy compiled into its release if the download fails, the signature does not verify, the feed is older than the compiled-in copy, or the feed is more than 30 days old. So recommendations follow the signed feed, not the release number. Stable provider v1.8.123 fetches the live 17-row signed feed. The copy compiled into v1.8.123 has 10 of the 17 rows (it predates the Qwen3-30B-2507, Qwen3.5, Qwen3.6, Qwen3.8 and GLM-4.5-Air rows). A v1.8.123 Mac that cannot fetch a current feed recommends only from those 10.

​

Warm now (23 September 2026, 04:59 UTC)

GET https://api.malibu.tech/v1/stats/models listed two warm models: The other 15 catalog models are priced and signed but had no Mac serving them at that moment. A model that no routable Mac is serving is not advertised, and requests for it return 404 model_not_found until one does. The warm set changes as Macs join, leave, and switch models. Treat this table as a snapshot, not a guarantee.

​

What a catalog entry contains

​

Catalog distribution

The catalog, rate card, and demand rank are signed feeds. Malibu serves the current versions, and each provider release also carries a compiled-in copy as a fallback. The provider verifies the signatures before it uses them. The signed catalog anchors:

• which models a provider may be recommended and admitted for;
• which weight artifacts count as canonical. The provider verifies downloaded weights against model_sha256 before serving paid traffic, and settlement checks the served artifact against the catalog;
• the RAM and benchmark gates autotune applies.

Providers reject a signed feed that is more than 30 days old and fall back to the compiled-in copy. Malibu re-signs the feeds before they reach that age.

​

Adding a model

Adding a model to the catalog is an operator action and ships as a signed release:

1. Pin the MLX weights to a Hugging Face revision and record the artifact SHA-256.
2. Add the catalog row (RAM floor, bandwidth tier, benchmark gate) and a rate-card row.
3. Sign and publish the release.
4. Providers pick up the new catalog from the signed feed at their next recommendation, or from the compiled-in copy after they update. A provider then serves the model once autotune recommends it or the provider switches to it.

To propose a model, contact the Malibu team with the model ID, the MLX weights, and the target RAM tier.

​

Receipt binding

Receipts carry model_hash, the artifact identity from the catalog row the provider served. The receipt verifier has catalog-check flags (--catalog / --catalog-url), but offline verification of current receipts is pending a verifier update: the released verifier cannot parse receipts that carry model_hash. Full trust boundary: Security & trust model.