He empezado a programar con Grok (después de meses con Claude)

En este blog he hablado de Claude más de una vez. Es con lo que programo casi a diario: agentes que leen el repo, proponen cambios, lanzan tests y se acuerdan de los seis sitios que hay que tocar cuando publico un episodio del podcast. En Cómo programo en 2026 conté ese stack con naturalidad. Grok, la IA de SpaceXAI (antes xAI), me quedaba de lado. Hasta escribí un repaso de lo que le había pasado a Grok sin usarlo de verdad en el flujo de trabajo.

Esta semana he cambiado eso. No he tirado Claude a la basura. He empezado a probar Grok en serio —sobre todo Grok Build, el agente de terminal— y me he forzado a usarlo en un proyecto real de un rato, no en un “hola mundo”. Esto es lo que me he llevado, sin bombo y sin hachazo.

Por qué ahora #

Tres motivos, en orden de honestidad:

1. Curiosidad técnica. Grok 4.5 se vende para programar y para tareas agénticas. Si Claude es mi default, me interesa saber si hay un plan B decente —el mismo razonamiento que me llevó a meter la IA de Apple en mi app de fitness: menos dependencia de un solo proveedor.
2. El producto se ha puesto serio. Ya no es solo el chatbot de X. Hay CLI, sesión, créditos, un TUI de agente. Eso se parece más a cómo trabajo yo que a un chat web.
3. Quería un experimento acotado. No “migro todo el Moodle a Grok”. Algo pequeño, acabable en un día, que me obligue a pelearme con auth, firma de macOS y un problema real.

Cómo lo estoy usando #

El flujo se parece al de Claude Code más de lo que esperaba: abres el agente en el directorio del proyecto, das una instrucción en lenguaje natural, y el modelo lee archivos, edita, ejecuta comandos y va cerrando el círculo. En mi caso es Grok Build en el Mac (el de la mesa y el mini de casa, según toque).

Lo que hago con él ahora mismo:

• Proyectos nuevos o de un día, donde no arrastro años de contexto mental en otro agente.
• Utilities de macOS / scripts, donde el coste de equivocarse es bajo.
• Explorar APIs y repos sin miedo a “gastar” el hilo de un agente que ya tiene cargado el Jitsi o el blog.

Lo que sigo haciendo con Claude (de momento):

• Plugins de Moodle y la deuda de mod_jitsi.
• Cosas donde la memoria entre sesiones y mis skills ya están muy afinadas.
• El día a día del blog y la web del mini, que ya tienen ganchos y convenciones que el otro agente “se sabe”.

No es un divorcio. Es dual-stack.

Qué se siente distinto (uso real, no leaderboard) #

Comparar modelos por tablas de benchmarks es un deporte olímpico. A mí me importa más la sensación al cabo de un par de horas de trabajo real:

• Ritmo. Grok Build se mueve con ganas: propone, aplica, compila. En un proyecto pequeño eso es un plus. En uno enorme aún no lo he exprimido igual.
• Menos “casa tomada”. Claude lleva meses en mi flujo (skills, hooks, memoria). Con Grok empiezo de cero: más fricción al principio, menos inercia.
• El tema créditos. Con Claude tengo un hábito de gasto. Con Grok no, y me molestaba no ver el % sin abrir el TUI y tirar de /usage. Eso me llevó al experimento de abajo.
• Lo no documentado duele igual en todas partes. Cuando hay que cazar un endpoint de billing o un contrato OIDC, da igual la marca: toca leer strings del binario, probar y dejar constancia de que hoy funciona.

No voy a decir que Grok es “mejor” o “peor” que Claude. Aún no lo sé a escala Moodle. Sí sé que es usable para construir algo de verdad en una tarde.

El experimento: una menubar con el % de Grok #

Para no ir a ciegas con el consumo, me monté GrokUsageBar: una app de barra de menú de macOS que muestra el porcentaje de créditos del periodo, el mismo dato que saca /usage (o /cost) dentro de Grok Build.

En la barra: el logo de Grok y un 0.7% (con decimal si vas por debajo del 10%). Al clic: panel con used/limit, periodo, historial en sparkline, notificaciones al 80% y al 100%, y un toggle de abrir al iniciar sesión.

Lo jugoso no es SwiftUI —un MenuBarExtra en media mañana— sino de dónde sale el número:

• Grok Build guarda la sesión en ~/.grok/auth.json (OAuth).
• El uso se consulta con
  GET https://cli-chat-proxy.grok.com/v1/billing
  y el token de esa sesión.
• El porcentaje es used / monthlyLimit. No inventamos dólares a ojo.
• Si el token caduca, la app renueva por OIDC y escribe de vuelta en auth.json, como hace el CLI.

Letra pequeña: ese endpoint no es una “API pública de billing” de catálogo. Es lo que usa el propio cliente hoy. Puede cambiar. La app es de uso personal; si la firmas con Apple Development y te la dejas en /Applications, te sobra. Para pasársela a alguien haría falta Developer ID y notarización.

El código está en GitHub: SergioComeron/GrokUsageBar. Instalación en mi Mac: ./install.sh (Release firmado → Applications).

Qué no he cambiado (todavía) #

• No he reescrito el blog ni el pipeline del mini “porque Grok”.
• No he dejado de abrir Claude cuando el contexto del proyecto ya vive allí.
• No tengo una métrica sagrada de “productividad +X%”. Tengo horas de uso y un artefacto que no existía ayer.

Eso me basta para no llamar a esto una “migración”. Es una apertura de mesa.

Lo que me llevo #

Hace poco escribía sobre Grok como noticia. Esta semana lo he usado como herramienta. La diferencia se nota: de repente dejas de opinar solo por hilos de X y empiezas a opinar por commits y fricción real.

Claude sigue siendo el plato principal. Grok ha entrado en el menú. Y de paso tengo en la barra del Mac un recordatorio de que los créditos no son infinitos —cosa que, con cualquier proveedor, conviene no olvidar.

Si pruebas Grok Build y te montas algo parecido (u otra utility tonta que te quite un roce del día a día), ya me contarás. Los experimentos pequeños son los que mejor enseñan si un agente nuevo merece sitio en el stack… o solo una semana de curiosidad.