diff --git a/recipes/llvm21.toml b/recipes/llvm21.toml
new file mode 100644
index 00000000..6668c78b
--- /dev/null
+++ b/recipes/llvm21.toml
@@ -0,0 +1,68 @@
+# LLVM 21.1.2 — el LLVM que `rustc` necesita. NO es un duplicado de `llvm18`: son para dos cosas
+# distintas y ninguna sirve para la otra.
+#
+# ══ POR QUÉ 21 Y NO EL 18 QUE YA ESTÁ SELLADO ══════════════════════════════════════════════════
+# El plan era «rustc desde fuente con el llvm18 del corpus». Medido en el propio bootstrap de rustc
+# (`src/bootstrap/src/core/build_steps/llvm.rs`), el mínimo por versión es:
+#
+#     rustc 1.87 → LLVM ≥18   ·   1.90 → ≥19   ·   1.93/1.95 → ≥20   ·   **1.97 → ≥21**
+#
+#     panic!("\n\nbad LLVM version: {version}, need >=21\n\n")
+#
+# El lab —y por tanto todo lo que construimos— está en **rust 1.97.0**, así que con `llvm18` sólo se
+# podría construir `rustc 1.87`… que a su vez no se puede bootstrapear con lo que tenemos. La salida
+# no es bajar de rustc: es subir de LLVM.
+#
+# `llvm18` se queda donde está: lo usa `mesa-llvmpipe` y mesa 24.0.9 **no soporta** LLVM 21. Dos
+# consumidores con rangos incompatibles ⇒ dos artefactos. No es deuda, es la realidad de los rangos.
+#
+# ══ DIFERENCIAS DE BUILD FRENTE A `llvm18`, Y SON A PROPÓSITO ══════════════════════════════════
+# · **Sin DYLIB.** `llvm18` construye `libLLVM.so` porque mesa la enlaza. rustc quiere las estáticas
+#   y su `llvm-config`; y el link del dylib es lo que pide MUCHA RAM (la receta de llvm18 anota
+#   «worker GORDO» por eso). Sin él, el pico baja y entra en el worker de 6 núcleos y 16 G.
+# · **RTTI ON** (rustc lo exige) y sólo el target **X86**: nada de compilar los 20 backends.
+name    = "llvm21"
+version = "21.1.2"
+license = "Apache-2.0 WITH LLVM-exception"
+
+[source]
+tarball = "https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.2/llvm-project-21.1.2.src.tar.xz"
+sha256  = "1a417d1c8faf8d93e73fec1cbb76d393ed3218974c2283c7bac9672d3d47c54b"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+flags    = []
+
+[deps]
+# Mismas deps que `llvm18`: `samurai` es el ninja del corpus (nombre distinto, mismo programa) y
+# `pkgconf` lo pide el configure de cmake.
+build = ["cmake", "samurai", "python3", "pkgconf"]
+
+[build.phases]
+# `g++` del sandbox con `-static-libstdc++ -static-libgcc`, igual que `llvm18` y `cmake`: C++ a
+# escala con zig sigue siendo terreno minado (ver el runtime de C++ que tiene que COINCIDIR).
+configure = '''
+CC=gcc CXX='g++ -static-libstdc++ -static-libgcc' \
+cmake -S llvm -B build -G Ninja \
+  -DCMAKE_BUILD_TYPE=Release \
+  -DCMAKE_INSTALL_PREFIX=/usr \
+  -DLLVM_TARGETS_TO_BUILD=X86 \
+  -DLLVM_BUILD_LLVM_DYLIB=OFF \
+  -DLLVM_LINK_LLVM_DYLIB=OFF \
+  -DLLVM_ENABLE_RTTI=ON \
+  -DLLVM_ENABLE_PROJECTS="" \
+  -DLLVM_ENABLE_TERMINFO=OFF \
+  -DLLVM_ENABLE_ZLIB=OFF \
+  -DLLVM_ENABLE_ZSTD=OFF \
+  -DLLVM_ENABLE_LIBXML2=OFF \
+  -DLLVM_ENABLE_LIBEDIT=OFF \
+  -DLLVM_ENABLE_BINDINGS=OFF \
+  -DLLVM_INCLUDE_TESTS=OFF \
+  -DLLVM_INCLUDE_EXAMPLES=OFF \
+  -DLLVM_INCLUDE_BENCHMARKS=OFF \
+  -DLLVM_INCLUDE_DOCS=OFF
+'''
+compile = "ninja -C build"
+install = "DESTDIR=/out ninja -C build install"