Part 2 of 5

From Model Name to Artifact System

The second page turns a casual model label into the concrete artifact contract the repo actually uses.

Broken intuition

A model family name still does not say which repo to fetch from, which revision to pin, whether serving needs one GGUF file or a whole MLX snapshot, or whether extra companion artifacts must travel beside the main weights. src/coding_agent/fetch.clj:9-25 src/coding_agent/fetch.clj:50-63 src/coding_agent/serve.clj:45-60

Experiment

Start from a label, then add the missing fields until the repo can fetch, verify, serve, and address one concrete artifact.

This builder shows why a family name is too small: packaging format versus inference engine and supported feature versus configured feature stay separate checks in the repo.

Revealed constraint

The repo has to keep multiple distinctions alive at once: packaging format versus inference engine, supported feature versus configured feature, exact file versus quant selector, and main artifact versus companions. That is why fetch resolves refs first, serve chooses runtime-specific arguments second, and benchmark requests use different model ids for MLX and llama.cpp. src/coding_agent/fetch.clj:9-25 src/coding_agent/fetch.clj:27-35 src/coding_agent/fetch.clj:50-63 src/coding_agent/serve.clj:45-60 src/coding_agent/bench.clj:46-53

Named concept

The artifact system is the full serving contract: family name, HuggingFace repo, pinned revision, file-or-snapshot shape, quant or weight format, required companions, lock material, server binary, and the request model id the local API expects. src/coding_agent/lock.clj:41-64 src/coding_agent/serve.clj:45-60 src/coding_agent/bench.clj:46-53

  • GGUF locks pin an exact file plus sha256, with companion sha256 values when :mmproj or :mtp is present.
  • MLX locks pin repo and revision, then verify the whole snapshot directory against a manifest. src/coding_agent/fetch.clj:161-174
  • The server still matters after the artifact is pinned, because llama.cpp and MLX load different shapes from disk.

Repo implementation

The same repository already shows all of these fields in real candidates. The M3 profile includes a Qwen GGUF exact file, a quant selector variant, a Gemma vision model with mmproj and MTP companions, and an MLX vision snapshot; the M1 profile includes both a GGUF exact file and an MLX 4bit snapshot. The lock code preserves those shapes, and the benchmark client addresses them differently at request time. profiles/m3-max-128gb.edn:12-39 profiles/m1-16gb.edn:10-27 src/coding_agent/lock.clj:41-64 src/coding_agent/bench.clj:46-53

Recognition

Pick the claim that stays true even after the filename changes.

Select a claim to reveal whether it is stable enough to automate.

Sources

src/coding_agent/fetch.clj:9-25 src/coding_agent/fetch.clj:27-35 src/coding_agent/fetch.clj:50-63 src/coding_agent/fetch.clj:73-90 src/coding_agent/fetch.clj:109-119 src/coding_agent/lock.clj:41-64 src/coding_agent/serve.clj:45-60 src/coding_agent/bench.clj:46-53 profiles/m1-16gb.edn:10-27 profiles/m3-max-128gb.edn:12-39

Why keep this separate from filenames?
The filename lab helps read names, but this page is the bigger contract: fetch, lock, serve, and request routing still need repo, revision, shape, and integrity data that no filename can carry by itself.