---
title: Model recipes
description: Pick a model, inspect its runtime, and copy a command that matches your machine.
---

<ModelRecipeCatalog />

## 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

1. **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.
2. **Prefer verified or integrated entries.** These have a bound pipeline; everything else is reference material.
3. **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.
4. **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.

## What each model page contains

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:

<RecipeRecords items={[
  {
    term: 'Catalog',
    detail: 'Stable model ID, tasks, official sources (paper, project, code, weights), aliases, and integration status.',
  },
  {
    term: 'Publisher',
    detail: '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.',
  },
  {
    term: 'Runtime profile',
    detail: 'Input contract, artifact contract, backend stage, and runtime readiness.',
  },
  {
    term: 'Environment',
    detail: 'Python, CUDA tier, pinned packages, validation imports, and dedicated vs. unified routing.',
  },
  {
    term: 'Pipeline binding',
    detail: 'The runner and concrete pipeline target used by WorldFoundry, per variant.',
  },
  {
    term: 'Benchmarks',
    detail: 'Evaluation benchmarks recommended by the manifest or referenced in its evidence notes, linked to the Benchmark Hub.',
  },
  {
    term: 'Evidence',
    detail: '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

```bash
# 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](/docs/guides/inference) — the full request-file and artifact flow once you have picked a model.
- [Environment reference](/docs/reference/environments) — how unified vs. dedicated environment routing is decided.
- [Evaluation](/docs/evaluation) and the [Benchmark Hub](/docs/evaluation/benchmark-hub) — score a model's outputs; model pages link to benchmarks their manifests recommend or reference.
- [Add a model](/docs/guides/add-model) — how new catalog manifests (and their optional `docs:` block) are written.