llamafit 0.1.1

Added

• Standalone executables for Windows, macOS and Linux on x86-64 and ARM: one
  self-contained file per platform, with the interpreter, the dependencies, the catalog,
  the generated facts, the hardware profiles, the schemas and all 37 message catalogs
  inside it. Nothing to install and no Python needed. Built by
  .github/workflows/binaries.yml from packaging/llamafit.spec on five machines, because
  PyInstaller is not a cross-compiler, and attached to the GitHub release with SHA-256
  checksums. The Linux builds are made on Ubuntu 22.04 so that they need glibc 2.35 and
  not 2.39, which is the difference between running on Debian 12 and RHEL 9 and refusing
  to start there. docs/standalone.md covers which file to take, how to verify it, what
  Windows and macOS will say about a binary nobody has paid to sign, and the one thing
  the binary leaves out.
• .github/workflows/binaries-attach.yml puts binaries on a release that already exists,
  by hand, calling the same build. It touches nothing else: a version number on PyPI can
  be used once and never again, while a release asset can be replaced any number of
  times, so a platform can be rebuilt after a fix without going near an upload that
  cannot be repeated.

Changed

• All 37 translation catalogs are complete. Thirty-one of them carried about a
  quarter of the messages, the column headings and the short phrases without the sentences
  that explain anything, and now carry all 1,153. Every one of them still says at the
  top that it has not been read by a speaker of its language, because it has not, and
  that is still the most useful contribution anyone can make here.
• Every number a reader sees uses their own decimal separator. Eleven messages formatted
  floats with a numeric conversion, which writes a point whatever the language, so a
  sentence saying 0.92 GB sat directly underneath a table that had just written
  0,0165 for the same reader. No wording changed in any language.
• Eleven catalogs no longer guess the curator's gender in the one message whose English
  says "their machine". Each uses its own way of saying "one's own" instead.

Fixed

• multiprocessing.freeze_support() is called before anything else in main(). Nothing
  in LlamaFit starts a process, since the bandwidth measurement uses threads, but
  py-cpuinfo does, and in a frozen build a child process is started by re-running the
  executable with --multiprocessing-fork, which Click meets as an option it has never
  heard of and answers with a usage error printed across whatever the real run was
  drawing. It affects the standalone binary only, on the first command most people try.
• llamafit install llama.cpp no longer fails against a release whose archives have not
  finished uploading. llama.cpp tags several builds a day and the files arrive after the
  tag, so for a few minutes the newest release carries nothing; the installer took it and
  said "release b10931 publishes nothing for windows x86_64", which is true of that tag
  and reads as a statement about the platform. A tag with no files is not a build anybody
  can install, so the newest one that publishes files is chosen, and the plan names it.
• The hint that says where a global option goes no longer blames the wrong option.
  llamafit --gpu-vram 0 --ram 8GiB plan … is a usage error about --gpu-vram, and the
  hint declared --ram misplaced and offered a command line that was not one: it took
  the value of the first option for the command name, and moved an option without its
  value.

llamafit 0.1.0

Added

• recommend and fit take view flags that change what is drawn and never what is
  ranked: --sort KEY[:asc|:desc] over eleven keys (score, speed, quality,
  context, size, prompt, card, ram, fit, model, quant), --search,
  --installed, --runs, --min-fit on recommend, --columns LIST, --wide and
  --hide-excluded; each says so in a line under the table. The same eleven words are
  the dashboard's s cycle and the API's sort=, and a test asserts the three agree.
• Dashboard keys: S the previous sort key, o reverse the order, e hide or show the
  unranked rows, c every column with the table scrolling sideways; n now moves the
  cursor to the first unranked row, whose reason the explanation pane shows. The Needs
  form gained the slowest generation worth having, the command line's --min-tps.
• llamafit --json with no command prints recommend --json rather than opening a
  full-screen application over a document, and llamafit --help says what the bare command
  does: it opens the dashboard, and in a pipe prints what recommend would.
• Project scaffold: packaging, CI matrix, lint, type-check and test configuration.
• Design specification covering host detection, llama.cpp integration, the model catalog,
  GGUF facts, memory budgets, placement planning, speed estimation, scoring, the CLI, TUI
  and web dashboard, the installer, and the verifier (docs/specs/).
• Implementation plan for phase 1A, foundation and host scan (docs/plans/).
• Repository documentation: README, roadmap, contributing guide, code of conduct, security
  policy, support guide, issue and pull request templates, and the docs/ set.
• Reference-machine calibration measurements from 2026-09-09
  (docs/calibration/2026-09-09-reference-machine.md).
• Host scan: OS, CPU (cores, performance cores, instruction sets), memory (totals, DDR facts,
  measured or estimated bandwidth), GPUs (NVIDIA, AMD, Apple, generic), disks.
• llama.cpp detection: binaries, build, backends, local GGUF files, running servers.
• llamafit system and llamafit doctor with Rich tables, --json, hints and exit codes.
• Documentation: CLI reference, platform support, development guide, contributing guide.
• Model catalog: curated YAML per model family, with parameters, architecture, context,
  capabilities, licence, published benchmark scores and the Hugging Face repositories that
  publish the GGUF files. The volatile fields live in a generated <family>.facts.json beside
  each file, so nothing ever rewrites hand-written YAML.
• GGUF header reader for local files and for remote URLs over HTTP range requests, and the
  architecture facts derived from a header: layer, head and vocabulary counts, expert counts,
  the byte breakdown by tensor class, KV bytes per token, the declared context length and
  sliding window. A quant published as several shards is read as a set, not from its first file.
• Memory budget: for a model, a quant, a placement and a context, what every component needs
  and which pool it lands in — weights prorated by the layers on the card, the key-value cache
  and the recurrent state, the compute and output buffers, the vision projector and the two
  fixed overheads. Every line says whether its bytes came from the file's own tensor table or
  from a fitted formula, because a budget that presented both in one voice would lend the
  measured figures' authority to the modelled ones. A configuration that needs more than the
  card has free is reported as paging rather than as failing: an NVIDIA driver does not refuse
  the allocation, it pages to system memory and the speed collapses while the server starts and
  looks healthy, and that is the failure a person cannot see for themselves. Attention and the
  cache on the card with the experts in system memory is judged like any other placement.
  Where an architecture allocates memory its GGUF header does not describe — Qwen3.8-Flash-Next
  allocates about 9 MiB of cache per 1,024 tokens beyond the shapes it declares, 27 percent of
  its cache at 32K and 1.1 GB at 128K — the budget carries it on a line naming the architecture
  and the component rather than leaving it out. Reporting less memory than a configuration will
  use is the one way of being wrong that turns into "this fits" when it does not. The always-on
  shared experts are a line of their own, so a tensor override that sends just those to system
  memory can be costed: on the reference machine it frees 239 MiB and turns Qwen3.8-Flash-Next
  at 32,768 tokens from 29 MiB over an 8 GB card into 211 MiB inside it, which is the best
  configuration anyone has measured on that machine. What a GPU backend costs before it
  allocates anything is a lookup keyed by the card, with the conservative 300 MiB default
  underneath it: a card somebody has measured gets the measured figure and every other card
  keeps the safe one, and the budget line says which of the two a reader is looking at,
  because 180 MiB on an 8 GB card is two rungs of the context ladder.
• llamafit list and llamafit search: browse the catalog, filtered by use case, capability,
  licence, vendor or text.
• llamafit info <model>: one model in full, with every quant it publishes, the GGUF facts
  read from it, and what each of those quants would cost on this machine — the run mode, both
  pools, an estimated speed, the largest context it holds and the verdict, one line each, with
  --quant to narrow it to one and --context to size it for a length you name. One line and
  no more: the budget component by component, the ladder and the command line are plan's, and
  two commands printing the same screen is a defect of its own.
• llamafit catalog validate|refresh|show: check the catalog files, fill their volatile fields
  from Hugging Face without downloading any weights (--dry-run, --check and --model), and
  print one entry as JSON or YAML.
• Custom models: entries in custom_models.yaml are merged with the bundled catalog, an entry
  whose id matches a bundled one replacing it.
• llamafit install llama.cpp: downloads a published llama.cpp build and installs it into
  ~/.llamafit/llama.cpp, which is the first directory the detector looks in, so nothing has to
  be configured afterwards. The archive is chosen from the asset names for the operating system,
  the architecture and the backend, with the CUDA runtime archive a Windows CUDA build cannot
  start without brought along beside it, and with the CUDA version chosen against the card's
  actual driver rather than by taking the newest — a CUDA 13 build does not run slowly on a
  driver below 580, it does not run at all. The whole plan is printed before anything is
  written: which release, which archive, how large, how much is already on disk, whether a
  checksum is published, where it will go, what is already there and how much room the volume
  has. A directory that does not carry LlamaFit's own marker file is never overwritten without
  --force, because people build llama.cpp themselves with their own flags and no download can
  put that back. The published checksum is verified on the partial file before anything is
  unpacked, and a file that fails it is deleted rather than left to be resumed onto; an
  interrupted download continues where it stopped; and PATH is changed only on an explicit
  --add-to-path and a yes, with the undo printed in the same breath as the offer.
• Placement planner: for one model and quantisation on one machine it searches the run modes
  in order -- everything on the card, routed experts in system memory, some layers on the card,
  the processor alone -- and keeps the best configuration that fits rather than the first,
  choosing the context, the micro-batch, the KV cache type, the number of layers on the card
  and where the vision projector lives. A faster mode wins over a longer context, and a floor
  under the context ladder is what keeps that from recommending a working configuration nobody
  could work in. It takes the memory budget as an injected function, so it can be read, tested
  and changed apart from the thing that sizes a configuration. For a mixture-of-experts model
  holding its routed experts in system memory it also tries sending the always-on shared
  experts after them, which is what -ot ffn_.*_shexp=CPU does: they run for every token, so
  it is tried second and never preferred, but on the reference machine those 239 MiB are what
  turns the best configuration anybody has measured there from withheld into recommended. A
  placement that moved them says so on its own command line.
• llamafit.services.plan: the join between the memory budget and the placement search, which
  is what lets the planner run against real models on a real machine rather than only against
  an injected fake.
• Hardware profiles: a machine described in a JSON file instead of probed, so LlamaFit can
  answer for a machine that is not this one -- a card somebody is thinking of buying, or the
  twenty identical machines a model is being chosen for from a build server that is none of
  them. A profile becomes the same Host a scan produces, so every service downstream takes
  it without knowing which it got, and single-value overrides substitute one pool of the live
  scan for a what-if. A simulated host cannot be mistaken for a measured one: it carries a
  simulation object naming the profile, its file and the pools that were overridden, and a
  simulated flag computed from it, so the fact reaches a --json consumer as a field rather
  than only a reader as a heading. On the terminal it is the first row of the host table, in
  red, before any figure.
• llamafit hardware list|show|validate|path: the profiles LlamaFit can reach, one profile
  with the provenance line that says where its figures came from, the host a profile stands
  in for (show --as-host), a check that follows the catalog's hab...