Model recipes

Pick a model, inspect its runtime, and copy a command that matches your machine.

Last updated: Oct 7, 2026

On this page

How to read readiness How to choose a model What each model page contains Common commands Where this fits in the docs

270 modelsruntime data from repository manifests

How to read readiness

Every model carries one readiness badge. The badge is computed from independent manifest records and never rounds missing evidence up to a stronger claim.

Runner verified — A WorldFoundry runner-parity artifact is recorded for at least one route. Select the variant and configuration named in that evidence.
Integrated — A runnable pipeline is bound, but end-to-end GPU parity is still pending. Run it; treat outputs as unvalidated until parity is recorded.
Runtime ported — Runtime code exists in-tree; the route is still being wired up. Inspect the manifest; running may require manual steps.
Profile only — Only a runtime profile is recorded — no bound pipeline. Use the page for provenance and planning; no run command is shown.
Planned — The entry records intent and upstream provenance only. Track it; nothing is runnable yet.
Blocked — A recorded blocker (license, weights, upstream) prevents integration. Read the manifest notes for the specific blocker.

How to choose a model

Filter by family and task. Use the category tabs (Video, World models, 3D & 4D, Embodied, Hosted API) and the search box — it matches model names, aliases, providers, and task ids.
Prefer verified or integrated entries. These have a bound pipeline; everything else is reference material.
Check the runtime line. Dedicated environments need their own install; unified-environment models share one conda environment. Python and CUDA tell you whether your driver stack matches before you install anything.
Open the model page. Each page explains what the model is, where it comes from, its input/output contract, exact environment, weight repositories with pinned revisions, and a command builder that emits the copy-paste run command for a chosen variant.

Model pages combine generated runtime records with model-specific articles. docs/fumadocs/scripts/generate-model-recipes.py refreshes recipe data and pages marked pageSource: generated; authored articles are maintained separately. Each page keeps these claims separate:

Catalog: Stable model ID, tasks, official sources (paper, project, code, weights), aliases, and integration status.
Publisher: The formal publishing institution (company first, then university or lab) with its kind. GitHub handles are never presented as brands; when the repository records no formal institution, the page says so explicitly.
Runtime profile: Input contract, artifact contract, backend stage, and runtime readiness.
Environment: Python, CUDA tier, pinned packages, validation imports, and dedicated vs. unified routing.
Pipeline binding: The runner and concrete pipeline target used by WorldFoundry, per variant.
Benchmarks: Evaluation benchmarks recommended by the manifest or referenced in its evidence notes, linked to the Benchmark Hub.
Evidence: Native-demo and WorldFoundry-runner parity; a catalog entry alone is not proof of a successful GPU run.

Unknown values remain Not recorded. Catalog manifests can carry a curated bilingual docs: block with overview, architecture, publisher attribution, and recommended benchmarks. Entries without that block use recorded catalog and runtime metadata. Usage notes and blockers live in the Runtime contract on each model page. Catalog tasks describe model capabilities; the command builder uses the CLI's accepted task-profile IDs and options. Recorded validation applies to the stated route and configuration.

Common commands

# Inspect the complete catalog manifest.
worldfoundry-eval zoo model-show \
  --model-id <model-id> \
  --include-manifest \
  --json

# Resolve checkpoints, credentials, and local asset blockers without downloading.
worldfoundry-eval zoo model-download \
  --model-id <model-id> \
  --check-local \
  --json

# Resolve and install the environment manifest for one runtime profile.
bash scripts/setup/model_env_install.sh --model <model-id>

# Download declared checkpoints for a runtime profile.
bash scripts/inference/prepare_model_infer.sh <model-id> --download

# Run a recorded task profile (each model page generates the exact flags).
worldfoundry-eval run <model-id> --pipeline.task-profile <task> --json

Where this fits in the docs

Run inference — the full request-file and artifact flow once you have picked a model.
Environment reference — how unified vs. dedicated environment routing is decided.
Evaluation and the Benchmark Hub — score a model's outputs; model pages link to benchmarks their manifests recommend or reference.
Add a model — how new catalog manifests (and their optional docs: block) are written.