Un binario de 100 megas para un CLI
Anthropic acaba de anunciar que Claude Code ya está disponible como native build. Traducción: un ejecutable binario que puedes instalar con un curl y que no necesita Node.js.
Suena bien, ¿no? Un comando, sin dependencias, auto-updates en background. El sueño de cualquier herramienta CLI.
Pero hay un detalle: el binario pesa 100MB.
Para ponerlo en perspectiva, el binario de git pesa unos 3MB. El de curl menos de 1MB. Incluso Go, que tiene fama de generar binarios gordos, raramente supera los 15-20MB.
¿Qué narices hay dentro de esos 100 megas?
No es Rust, es Bun con traje de ejecutable
Cuando vi el anuncio, mi primer pensamiento fue: «Han reescrito todo en Rust». Tiene sentido, ¿no? Si quieres un binario nativo, rápido y sin runtime, Rust es la opción obvia.
Pues va a ser que no.
Claude Code sigue siendo TypeScript. Lo que han hecho es usar bun build --compile para empaquetarlo como ejecutable.
Cómo funciona bun build --compile
El comando mágico es este:
bun build ./src/index.ts --compile --outfile claude
¿Qué hace exactamente? Tres cosas:
1. Bundling
Primero, Bun actúa como bundler. Toma tu archivo de entrada (index.ts), resuelve todos los import, y genera un único archivo JavaScript con todo el código concatenado. Incluye tus dependencias de node_modules, resuelve tree-shaking para eliminar código muerto, y minifica el resultado.
Hasta aquí, nada diferente de lo que hace esbuild o webpack.
2. Embedding
Aquí viene lo interesante. Bun coge ese bundle de JavaScript y lo incrusta dentro de un ejecutable junto con el runtime de Bun completo.
El ejecutable resultante tiene esta estructura (simplificada):
┌─────────────────────────────────┐
│ Runtime de Bun (~95MB) │
│ ├── JavaScriptCore engine │
│ ├── APIs nativas (fs, http) │
│ ├── Zig runtime │
│ └── libc estática │
├─────────────────────────────────┤
│ Tu código bundleado (~5MB) │
│ └── JavaScript minificado │
└─────────────────────────────────┘
Cuando ejecutas el binario, el runtime de Bun extrae el código JavaScript de sí mismo y lo ejecuta. Es como un archivo ZIP autoextraíble, pero para código.
3. Cross-compilation
Bun puede generar binarios para otras plataformas:
bun build ./src/index.ts --compile --target=bun-linux-x64 --outfile claude-linux
bun build ./src/index.ts --compile --target=bun-darwin-arm64 --outfile claude-mac
bun build ./src/index.ts --compile --target=bun-windows-x64 --outfile claude.exe
No necesitas tener Linux para generar un binario de Linux. Bun incluye los runtimes precompilados para cada plataforma.
JavaScriptCore vs V8
Node.js usa V8, el motor de JavaScript de Chrome. Bun usa JavaScriptCore (JSC), el motor de Safari.
¿Por qué importa? Porque son bestias diferentes:
| Aspecto | V8 (Node) | JavaScriptCore (Bun) |
|---|---|---|
| Tiempo de arranque | ~50ms | ~5ms |
| Pico de rendimiento | Muy alto | Alto |
| Uso de memoria | Mayor | Menor |
| JIT tiers | 2 (Ignition → TurboFan) | 4 (LLInt → Baseline → DFG → FTL) |
JSC tiene un arranque más rápido porque tiene más tiers de compilación JIT. Empieza interpretando código muy rápido (LLInt) y va optimizando en background mientras ejecuta. V8, en cambio, necesita hacer más trabajo inicial antes de empezar a ejecutar.
Para un CLI que arranca, hace algo, y termina, esos 45ms de diferencia en arranque importan. Para un servidor que corre durante horas, importa menos.
Por qué Zig (y no Rust, ni C++)
Bun está escrito principalmente en Zig, con algo de C++ para las partes que interactúan con JavaScriptCore.
Jarred Sumner, el creador de Bun, eligió Zig por varias razones:
-
Interoperabilidad con C: Zig puede llamar a código C sin overhead ni FFI. JavaScriptCore está escrito en C++, y Zig puede enlazar con él directamente.
-
Control de memoria sin garbage collector: Como Rust, pero con una sintaxis más simple y sin el borrow checker que te pela las manos.
-
Compilación cruzada trivial: Zig puede compilar para cualquier plataforma desde cualquier plataforma. No necesitas una máquina Linux para compilar para Linux.
-
Binarios pequeños (relativamente): Un «Hello World» en Zig pesa ~5KB. En Go, ~2MB. En Rust, ~300KB.
El resultado es un runtime que arranca rápido, usa poca memoria, y se puede distribuir como un único binario estático. Exactamente lo que necesitas para esto.
Lo que NO es
Para que quede claro: esto no es compilación AOT (Ahead-of-Time) como hace GraalVM con Java o WASM.
Tu código TypeScript no se convierte en instrucciones de CPU. Sigue siendo interpretado por JavaScriptCore en tiempo de ejecución. Lo único que cambia es que el intérprete viene empaquetado junto con el código.
Es el mismo truco que hace:
– pkg para Node.js
– PyInstaller para Python
– electron-builder para apps Electron
No es magia. Es meter el runtime y el código en el mismo paquete. Por eso pesa 100MB — la mayor parte es JavaScriptCore y las APIs de Bun, no el código de Claude Code.
¿Qué gana Anthropic?
Aquí está el meollo. Porque este cambio no es por ti.
Menos tickets de soporte
¿Sabes cuántos problemas da npm? Permisos rotos, cache corrupto, conflictos de versiones de Node, PATH mal configurado, node_modules de 800MB que desaparecen misteriosamente…
Cada uno de esos problemas es un ticket de soporte. Cada ticket de soporte es dinero y tiempo. Multiplica por los millones de usuarios de Claude Code y entenderás por qué Anthropic ha decidido eliminar npm de la ecuación.
Auto-updates sin fricción
Con npm, actualizar Claude Code requiere que el usuario ejecute npm update -g @anthropic/claude-code. Algunos lo hacen. Muchos no.
Con el native build, las actualizaciones ocurren automáticamente en background. Anthropic tiene control total sobre qué versión estás ejecutando. Para una empresa que itera rápido y corrige bugs constantemente, esto es oro.
Entorno controlado
Cuando te llega un bug report, lo primero que preguntas es: «¿Qué versión de Node tienes? ¿Qué versión de npm? ¿Qué sistema operativo?». Con el native build, todo eso desaparece. El entorno de ejecución es el mismo para todos.
Bugs más reproducibles = bugs más fáciles de arreglar.
¿Y qué gana el usuario?
Si no tienes Node.js instalado
Clara mejora. Antes necesitabas:
- Instalar Node.js
- Configurar el PATH (si no se hizo automáticamente)
- Instalar npm (viene con Node, pero a veces hay que actualizarlo)
- Ejecutar
npm install -g @anthropic/claude-code - Rezar para que no haya conflictos
Ahora necesitas:
curl -fsSL https://claude.ai/install.sh | sh
Para alguien que no es desarrollador — un product manager, un escritor, un diseñador — la diferencia es abismal.
Si ya tienes Node.js
Honestamente, ganas poco. Quizás te ahorras algún problema ocasional de npm. Las auto-updates son convenientes. El syntax highlighting nativo que solo viene en el native build es un nice-to-have.
Pero si ya tenías Claude Code funcionando con npm, el cambio es básicamente lateral. No vas a notar diferencia en el día a día.
Los 100MB en perspectiva
Sé que suena a barbaridad. 100MB para un CLI. Nuestros abuelos programaban con 4KB de RAM y aquí estamos descargando 100 megas para ejecutar comandos.
Pero seamos realistas:
- VS Code pesa ~300MB
- Slack ~500MB
- El SDK de iOS ~30GB
- Un proyecto medio de Node.js tiene un
node_modulesde 500MB+
Y mi favorito: macOS Sequoia incluye 45GB de fondos de pantalla.
Cuarenta y cinco gigabytes. De wallpapers. Vídeos en 4K de medusas flotando, olas rompiendo, y la aurora boreal para que tu Mac tenga un salvapantallas bonito. Son 450 veces el tamaño de Claude Code. Para. Fondos. De. Pantalla.
Claude Code te da un asistente de IA que puede escribir código, ejecutar comandos, y gestionar proyectos enteros. Los fondos de pantalla de Apple te dan… medusas.
En 2026, con fibra de 1Gbps y SSDs de 1TB como estándar, 100MB es ruido estadístico. Lo descargas en segundos, lo guardas y te olvidas.
¿Es elegante? No. ¿Importa en la práctica? Tampoco. Y desde luego importa menos que las puñeteras medusas.
¿Deberías migrar?
Si tienes la versión npm y funciona bien, no hay prisa. Puedes migrar ejecutando claude install desde la versión npm.
Si estás instalando Claude Code por primera vez, usa el native build. Es la opción recomendada y la que menos problemas te va a dar.
Si eres de los que les molesta tener un binario de 100MB ocupando espacio, puedes seguir con npm. Anthropic dice que van a mantener ambas opciones, aunque está claro cuál es la apuesta de futuro.
El patrón que se repite
Esto no es nuevo. Es el mismo patrón que vemos una y otra vez en software:
- Empiezas con dependencias compartidas (DLLs, librerías del sistema, npm packages)
- Te encuentras con problemas de compatibilidad, versiones, y distribución
- Acabas empaquetando todo junto en un blob gordo que simplemente funciona
Docker hizo lo mismo. Electron hizo lo mismo. Bun está haciendo lo mismo.
¿Es la solución más elegante? No. ¿Es la que menos problemas da? Casi siempre sí.
A veces la ingeniería no va de encontrar la solución más bonita, sino la que menos tickets de soporte genera. Y Anthropic, con sus mil millones de revenue y millones de usuarios, lo sabe mejor que nadie.
Relacionados: – Bun: El runtime que quiere jubilar a Node — Tutorial completo de Bun para devs que vienen de Node, incluyendo la compra por Anthropic. – 10 GB de VM para un chatbot — Por qué Claude Desktop mete Ubuntu entero en tu Mac. Otra decisión de Anthropic que prioriza «funciona» sobre «elegante».
Read this article in English.
