Grok Build open source: instálalo en local sin humo ni promesas de IDE

Por qué acabó en GitHub: la cagada que lo hizo open source

Grok Build no llegó a GitHub por filosofía de empresa ni por un comunicado de "creemos en el software libre". Llegó porque xAI la lió subiéndolo primero a servidores propios de forma que generó suficiente ruido y desconfianza como para que el movimiento open source fuera la única respuesta creíble. La presión vino de fuera; la transparencia, por necesidad.

Ese contexto importa. Cuando una empresa publica el código del cliente después de una cagada de distribución, lo que obtienes es el cliente (el que corre en tu máquina), no el sistema completo. Los modelos, la infraestructura y lo que viaja entre tu terminal y los servidores de xAI siguen siendo cajas negras. Puedes hacer cargo build y auditar el TUI; no puedes auditar lo que está al otro lado de la conexión. Son capas distintas. No las mezcles.

Con eso claro, vamos a lo que sí puedes hacer: instalarlo, autenticarlo y entender el repo de verdad, incluido el asunto de los modelos.

Qué es Grok Build y para qué sirve de verdad

Grok Build no es un chat con esteroides ni un plugin de VS Code con un iconito de robot. Es un agente de codificación de xAI que se ejecuta en una interfaz de terminal a pantalla completa (lo que en jerga se llama TUI: Text User Interface). En castellano de barra: se come toda la pantalla de la terminal y se pone a trabajar ahí, no en un sidebar de un editor.

Lo que hace, según el material disponible, es concreto:

Entiende la base de código en la que estás.
Edita archivos.
Ejecuta comandos shell.
Busca en la web.
Opera directamente sobre el sistema de archivos y el control de versiones de la máquina local.

Eso último no es un detalle cosmético. No te "sugiere" un parche para que tú lo copies: trabaja sobre tu disco y tu git. No es un plugin de IDE. No es un chat convencional. Si lo abres esperando una conversación amable en un panel lateral, te estás equivocando de herramienta.

La promesa operativa de esta guía es simple: al terminar sabes cómo dejarlo instalado, autenticado y listo en local, qué modelos puedes usar, y si te interesa el código, cómo sacarlo del repo en Rust sin liarte con dependencias.

Requisitos antes de tocar nada

No hace falta un rack de GPUs ni un ritual. Con lo que consta:

Un sistema macOS, Linux o Windows.
En Windows, el camino sano es el binario precompilado. La compilación desde fuente no ha sido testeada en ese sistema; si te empeñas, puedes encontrarte errores no documentados. Mejor no ser el conejillo de indias.
Si vas a compilar desde fuente: macOS o Linux, toolchain de Rust (fijada en el archivo rust-toolchain.toml del repo) y protoc accesible en el PATH o en la variable de entorno PROTOC.
Un entorno donde puedas abrir el navegador al menos una vez para autenticarte con xAI en el primer arranque. Si estás en un servidor sin GUI o detrás de un proxy, prepárate la autenticación antes, o te quedas bloqueado.

No se especifican requisitos de hardware adicionales en el material. No inventamos RAM mínima ni GPU. Si el binario arranca y la auth pasa, ya estás en el juego.

Instalación con el binario precompilado (el camino de la gente con prisa)

Si quieres usarlo y no pelearte con compiladores, el binario precompilado es el camino. Comandos oficiales:

macOS, Linux o Git Bash:

curl -fsSL https://x.ai/cli/install.sh | bash

Windows PowerShell:

irm https://x.ai/cli/install.ps1 | iex

Cuando termine, comprueba que el binario está donde debe y responde:

grok --version

Si grok --version te devuelve algo y no un "command not found", la instalación del binario ha ido bien. Si falla, el problema suele ser PATH (el instalador metió el binario en un sitio que tu shell no mira) o que ejecutaste el script en un entorno distinto del que estás usando después (PowerShell vs CMD, zsh vs bash, etc.).

Tres trampas típicas en este paso:

Pipar scripts de curl a bash sin mirar. Es el patrón habitual de muchos CLIs; no lo conviertas en religión. Si tu política de seguridad lo prohíbe, descarga el script, léelo y ejecútalo a mano. El material no da otra vía de instalación del binario; la oficial es esa.
Mezclar Git Bash y PowerShell en Windows y luego preguntarte por qué grok no está en el PATH del otro. Instala y verifica en el mismo entorno donde lo vas a usar.
Asumir que con el binario ya "estás dentro". Falta la autenticación. Sin eso, el primer arranque no es un saludo amable: es un muro.

Primer arranque y autenticación con xAI

En el primer arranque, Grok Build abre el navegador para autenticarte con xAI. No es un paso opcional ni un "por si quieres personalizar". El material lo presenta como parte del flujo normal de entrada.

Flujo mental:

Lanzas la TUI (tras la instalación del binario o tras el build desde fuente).
El proceso intenta abrir el navegador para el login con xAI.
Completas la autenticación ahí.
Vuelves a la terminal con la sesión lista.

Si tu entorno no tiene interfaz gráfica (servidor headless, contenedor mínimo, máquina remota sin display) o estás detrás de un proxy, el navegador no se abre solo o no llega a donde tiene que llegar. Ahí el material es claro en la consecuencia: hay que resolver la autenticación de antemano para no quedarse bloqueado. No detalla el procedimiento exacto de "auth previa" paso a paso; lo que sí dice es que no puedes fingir que el login no existe.

Esto no es un detalle de UX. Un agente que edita archivos y lanza shell en tu máquina local tiene que saber quién eres ante el servicio. Tratar la auth como "ya lo haré luego" es la forma más rápida de montar un setup a medias y perder la tarde.

El primer arranque no es "abre y programa": es "abre, autentica y entonces programa". Sin GUI o con proxy, resuelve el login antes o te comes el bloqueo.

Qué modelos puedes usar

Aquí el repo es más generoso de lo que mucha gente asume: no estás atado solo a los modelos de xAI.

El repositorio incluye un archivo de custom models que documenta exactamente cómo añadir modelos externos. El soporte en la práctica cubre dos categorías:

Modelos de Grok (los propios de xAI, que son la opción por defecto y la que requiere autenticación con tu cuenta xAI).
Modelos externos (proveedores adicionales que puedes configurar a través del archivo de custom models del repo. Si tienes API key de otro proveedor compatible, puedes apuntarlo ahí).

Para el detalle exacto de qué proveedores externos están soportados y cómo se configura cada uno, el sitio de verdad es ese archivo en el repo: está pensado precisamente para que sea la referencia viva, no una captura en un artículo que caduca a los dos meses de un update.

Lo que sí puedes asumir: no es una caja cerrada solo para Grok. La flexibilidad de modelos es una de las partes que el repo documenta de forma explícita, no algo que tengas que hackear.

Compilar desde fuente: el repo está en Rust

Si te interesa el código, auditar, tocar o simplemente no fiarte solo del binario, el repositorio está escrito en Rust. La toolchain no es "cualquier Rust que tengas por ahí": viene fijada en rust-toolchain.toml. Eso significa que rustup (si lo usas bien) se alinea a la versión que el proyecto declara, en lugar de inventarse un mismatch de ediciones o de features del compilador.

Dependencia crítica aparte del toolchain:

protoc (el compilador de Protocol Buffers) tiene que estar en el PATH, o bien la variable de entorno PROTOC tiene que apuntar a él.

Sin protoc, la build se te cae en el paso de generación de código de protobuf. No es un "nice to have".

Ejecutar la TUI sin instalar el binario a mano

Para levantar la interfaz directamente desde el árbol del repo:

cargo run -p xai-grok-pager-bin

Eso compila (si hace falta) y arranca el paquete de la TUI. Útil para desarrollo o para probar un checkout concreto.

Binario de release

Para un ejecutable optimizado de release:

cargo build -p xai-grok-pager-bin --release

El ejecutable queda en el árbol de build, bajo target/release/ (el material apunta al artefacto generado a partir de ese paquete). A partir de ahí, puedes ponerlo en tu PATH o invocarlo con ruta absoluta.

Plataformas soportadas para el build desde fuente

macOS y Linux: soportados.
Windows: no ha sido testeada la compilación desde fuente. En Windows, el material recomienda el binario precompilado. Si intentas compilar en Windows "porque Rust es multiplataforma", puedes tropezar con errores no documentados. No es una teoría: es la advertencia explícita del material.

Resumen sin romanticismo: forkear y compilar tiene sentido si estás en macOS/Linux, tienes Rust y protoc en condiciones, y quieres control sobre el binario que ejecutas. En Windows, ahorra sangre: binario precompilado.

Cómo se usa (con lo que sí se sabe, no con fantasía de marketing)

Aquí toca ser honestos hasta el borde. El material no enumera atajos de la TUI, paneles, comandos internos ni un manual de modos. No hay lista de "pulsa Ctrl+X y magia". Lo que sí define es el modo de trabajo:

Interfaz de terminal a pantalla completa.
Agente que entiende el codebase.
Edita archivos en local.
Ejecuta shell.
Busca en la web.
Trabaja sobre filesystem y control de versiones de la máquina.

Traducción a tareas humanas reales:

Te metes en el directorio del proyecto que te importa.
Arrancas Grok Build (binario o cargo run).
Completas auth si es la primera vez.
Trabajas desde esa TUI, no desde un chat flotante de un IDE.

Si esperabas un "paso 3: abre el panel Agents y marca Auto-apply", te has equivocado de producto. Esto no se presenta como extensión de un editor concreto. Es un agente con cara de terminal.

Lo que no vamos a rellenar con humo:

Comparativa objetiva con Claude Code o Aider. Hay quien promete abordarlo en otros textos; en este material no se desarrolla. No hay tablas, no hay wins, no hay "es mejor porque…".
Si compensa forkear el repositorio frente a otras herramientas. La pregunta queda sin respuesta factual en el fragmento disponible. Forkear tiene sentido técnico (auditar, parchear, compilar tu build) o no, según tu caso.
Disección completa del repositorio (módulos, arquitectura interna, telemetría, etc.). Si te preocupa qué sale de tu máquina hacia fuera, mira análisis específicos de telemetría y destilación; no rellenes el hueco con fe.

Errores comunes (dónde la caga todo el mundo)

Tratarlo como un chat de IDE

Llegas, esperas un panel lateral, no lo encuentras y concluyes que "no funciona". No: es una TUI a pantalla completa. El modelo mental es otro. Si tu flujo es 100% "vivo dentro de Cursor/VS Code y no salgo", Grok Build te va a chocar aunque el binario esté perfecto.

Instalar y olvidar la autenticación

Sobre todo en CI, bastiones SSH o máquinas sin display. El primer arranque quiere navegador. Sin plan de auth previa, te comes un bloqueo. No es un bug misterioso: es el flujo.

Compilar en Windows "porque Rust"

El material es explícito: compilación desde fuente no testeada en Windows. El camino soportado ahí es el binario. Si te lanzas al cargo build en Windows y sale fuego, no es sorpresa documentada; es territorio sin mapa.

Faltar `protoc` y maldecir a cargo

Si compilas desde fuente, protoc en PATH o PROTOC definida. Sin eso, la build de un proyecto con protobuf se te rompe en generación de código. Antes de tocar flags de optimización, mira dependencias de sistema.

Asumir que solo funciona con modelos de xAI

El repo tiene soporte para modelos externos vía el archivo de custom models. No lo configures, úsalo. Asumir que estás atado a Grok por defecto y ya está es perder la mitad del punto de que el cliente sea open source.

Confundir "open source del cliente" con "todo es transparente y gratis"

Que el repo del cliente/TUI se pueda compilar no responde a "qué manda a los servidores", "cuánto cuesta" ni "qué telemetría se va". Son capas distintas. No mezcles "puedo hacer cargo build" con "conozco el sistema de punta a punta".

Flujo recomendado, de punta a punta

Si quieres un checklist reproducible, sin paja:

Elige vía de instalación
- ¿Quieres usar y listo? Binario.
- ¿Quieres código y control del build en macOS/Linux? Fuente + Rust + protoc.
- ¿Windows? Binario. No te hagas el héroe con el source.
Instala
- macOS/Linux/Git Bash: curl -fsSL https://x.ai/cli/install.sh | bash
- Windows PowerShell: irm https://x.ai/cli/install.ps1 | iex
- O, en macOS/Linux desde repo: cargo build -p xai-grok-pager-bin --release / cargo run -p xai-grok-pager-bin
Verifica (binario): grok --version
Prepara auth si no tienes GUI o hay proxy. No dejes este paso "para después del café".
Si quieres usar modelos externos, revisa el archivo de custom models del repo antes de arrancar. Configúralo con tu API key del proveedor que uses.
Arranca en un repo real (no en /tmp vacío si quieres ver si "entiende la base de código"). Deja que la TUI tome la pantalla.
Trabaja con el contrato real de la herramienta: filesystem local, shell, web, control de versiones. Si tu política de empresa prohíbe agentes con shell libre sobre el monorepo, no es un "tip de productividad": es un no organizativo. El agente no es un linter inocente.
No asumas ranking frente a otras tools sin datos. Mide en tu contexto.

Si en algún momento te interesa el ángulo de qué manda el CLI hacia fuera y el ruido alrededor de destilación y telemetría, hay material aparte sobre Grok Build CLI y lo que xAI no te cuenta de lo que sale de tu máquina. Esta guía es de instalación y ejecución local, no de forense de red.

Qué hay (y qué no hay) en el repo según lo que consta

Lo que sí podemos afirmar del repositorio a partir del material:

Está escrito en Rust.
La toolchain está fijada en rust-toolchain.toml.
Hay un paquete ejecutable de la TUI: xai-grok-pager-bin.
Se lanza en dev con cargo run -p xai-grok-pager-bin.
Se construye en release con cargo build -p xai-grok-pager-bin --release.
Necesitas protoc (PATH o PROTOC).
Build desde fuente: macOS y Linux; Windows no testeado.
Hay un archivo de custom models que documenta cómo usar modelos externos además de los de Grok.

Lo que no está en el material y por tanto no vamos a disfrazar de guía:

Mapa completo de crates, arquitectura interna, tests, telemetría embebida, puntos de plugin.
Lista exhaustiva de qué proveedores externos funcionan y cuáles no (para eso, el archivo de custom models en el repo).
Guía de contribución o política de forks.
Veredicto "forkea esto en vez de Claude Code/Aider".

Forkear un cliente en Rust puede ser una decisión de control, auditoría o parche. Compensar o no frente a otras herramientas de codificación con IA no se responde con los hechos de este encargo. Quien te venda un "sí, forkéalo sí o sí" o un "ni se te ocurra" sin datos está haciendo de gurú, no de técnico.

Cierre sin moraleja

Grok Build llegó a GitHub por una cagada, no por vocación. Con lo que hay encima de la mesa: es un agente de codificación en TUI de xAI que toca tu máquina de verdad (archivos, shell, web, control de versiones), soporta tanto modelos de Grok como externos via custom models, se instala con un script de binario o se compila desde un repo Rust con protoc y toolchain fijada, y el primer arranque autentica con xAI por navegador. Windows: binario. macOS/Linux: binario o source.

Abre la terminal, instálalo, autentica, mira el archivo de custom models si quieres salir del entorno xAI, y pruébalo en un repo tuyo. El resto de promesas, a la basura hasta que haya datos.

Preguntas frecuentes

¿Cómo se instala Grok Build en local?

Con el binario precompilado: en macOS, Linux o Git Bash ejecuta curl -fsSL https://x.ai/cli/install.sh | bash; en Windows PowerShell, irm https://x.ai/cli/install.ps1 | iex. Después verifica con grok --version. En macOS y Linux también puedes compilar desde el repo en Rust con protoc y la toolchain de rust-toolchain.toml.

¿Grok Build funciona en Windows compilando desde fuente?

No está testeada la compilación desde fuente en Windows. En ese sistema el camino recomendado es el binario precompilado vía el script de PowerShell. Intentar un cargo build en Windows puede producir errores no documentados; macOS y Linux sí están soportados para el build desde el repo.

¿Qué modelos soporta Grok Build?

Soporta los modelos de Grok (los propios de xAI, que requieren autenticación con cuenta xAI) y también modelos externos que se configuran mediante el archivo de custom models incluido en el repositorio. Si tienes API key de otro proveedor compatible, puedes apuntarlo ahí sin necesidad de modificar el código.

¿Por qué xAI publicó Grok Build como open source?

El movimiento open source vino después de una cagada con la distribución inicial del repositorio en servidores propios de xAI, que generó suficiente desconfianza como para que publicar el código del cliente fuera la respuesta obligada. Lo que se publica es el cliente TUI; los modelos e infraestructura de xAI siguen siendo privados.