Per-model adaptation — engine flags, quant variants, chat and tool templates — is hard, boring work, and we accept that. What must be excellent is the base underneath it, so that adapting a model is editing a data file, not writing code. Recipes are that data file, and schema v1 is now in the tree: the types, validation, a published JSON Schema, and example recipes.
The format decision: YAML for hand-authored recipes — comments, multi-line chat templates, what ML contributors already write — and JSON on the wire for the Management API and machine-generated skeletons. One serde struct behind both; the loader accepts .yaml, .yml and .json. Not TOML (nested lists read badly), not JSON5 (a third format nobody asked for).
The minimal recipe is genuinely minimal — an id and where the weights live. Backend and format are inferred; you get one implicit default variant:
# recipes/smollm2-135m-instruct.yaml
schema_version: 1
id: smollm2-135m-instruct
family: smollm2
source:
hf: bartowski/SmolLM2-135M-Instruct-GGUF
file: SmolLM2-135M-Instruct-Q8_0.gguf
A full recipe carries what actually differs per model: quant variants mapped to VRAM and RAM requirements, the tool-call parser, engine arguments, a known-good backend, and a smoke test (prompt → expect_contains). Variants can even switch backends — a GGUF for laptops and a bf16 safetensors variant for GPU boxes in the same file.
Next: the resolver (recipe × detected hardware → variant) and migrating the compiled-in catalog to recipes/*.yaml. From there, a new model is a pull request anyone can send.