Rich catalog
Each model carries its own metadata, including parameters, capabilities, license, tags, version history, hardware requirements, and download options across gguf, mlx, and safetensors formats.
New and improved models are published to the Hub, versioned, verified, and made available without a platform update. Models download once and run entirely on the user's machine. The Hub handles distribution and metadata only.
| Capability | Approach |
|---|---|
| Distribution | Models bundled with the application or downloaded on first use |
| Versioning | Semantic versioning; breaking changes trigger a major version bump |
| Integrity | SHA-256 checksum verification on download; cryptographic signing verifies provenance |
| Compatibility | Model versions pinned to compatible application versions |
| Governance | Publisher authorization and approval gates; rollback to previous verified versions |
Each model carries its own metadata, including parameters, capabilities, license, tags, version history, hardware requirements, and download options across gguf, mlx, and safetensors formats.
A system probe reads your RAM, free disk, OS, and architecture, then matches them against each model's requirements. The result drives a per-model Compatible badge and filter.
Downloads stream with progress and SHA-256 verification, are cancellable, and survive a tab switch. Models land in your local model directory.
Load starts a managed llama.cpp server against the model. Each model has its own settings, including context size, GPU layers, threads, flash attention, KV-cache type, and a reasoning toggle.
The inference engine resolves automatically through a managed download, a saved setting, or PATH auto-detect. There is no bundling and no setup script.
The Hub never processes inference data. It distributes artifacts and metadata only, preserving the zero-egress boundary end to end.
Today's Hub runs against a structured catalog that stands in for the central service. The planned registry adds a metadata API, semver with app-compatibility pinning, package signing and provenance, publisher trust gates, an automatic update channel, and shadow mode. Shadow mode runs a candidate model version beside the active one on real workloads, logs both, and promotes the candidate only after validation.
The standardized node contract means new capabilities arrive through model training and export alone.