Usar un modelo en local tiene sentido por cosas bastante prácticas. Cuando trabajas contra una API, el código sale de tu máquina, pagas por token y mañana pueden cambiarte el precio, el modelo o los términos. En local nadie ve lo que le pegas, no hay factura que crezca con cada petición y, si la red se cae, sigues. No nos engañemos, al menos por ahora, esto no va a sustituir a las soluciones de pago, sus modelos frontera y a todo el andamiaje que ya tienen montado alrededor de ellos. Pero para scripts, limpiezas, comparar JSON o preguntarle cosas sobre un fichero sin mandarlo a un tercero, puede valer.

Al principio me perdí en los nombres. Que si 7B, que si Q4_K_M, que si Instruct, que si 26B-A4B. Y luego está lo de siempre, ves un tutorial que te pone los dientes largos, bajas un modelo que en teoría te cabe, lo arrancas, y el equipo se queda frito o va a dos tokens por segundo. ¿A quién no le ha pasado?

En local casi todo lo que puedes bajar son modelos de pesos abiertos. Ya conté qué significa eso y por qué no es open source del todo. Te bajas los pesos, los corres en tu máquina y nadie ve tus datos. Llama, Qwen, Mistral, Gemma, Phi, DeepSeek y compañía. Si lo vas a usar para trabajar conviene mirar la licencia, que no todas son iguales.

Con qué correrlos

Un modelo, en la práctica, es un fichero grande en el disco. Para usarlo hace falta un programa que lo cargue en memoria y te deje hablar con él. Ese programa puede ser una ventana de chat, o puede dejar que otra herramienta, como opencode, le envíe preguntas y reciba respuestas, en un formato determinado, y en forma de instrucciones para realizar acciones, ejecutar comandos, escribir código, etc. Todo esto sin salir de tu máquina.

Ese formato suele ser el de la API de OpenAI. No es que estés usando nada de OpenAI ni mandando datos a sus servidores. Ellos definieron la primera API que se popularizó para hablar con un modelo, y el resto del ecosistema la copió. LM Studio y Ollama levantan un servidor en tu propio ordenador que responde igual: mismas peticiones, mismas respuestas. Por eso opencode, y casi cualquier cliente, se conecta sin inventar un protocolo nuevo.

Las tres opciones que más se ven son LM Studio, Ollama y llama.cpp. Hacen lo mismo en el fondo: ejecutar el modelo en tu ordenador. Se diferencian en cómo te lo ponen, en si puedes ver y cambiar su código, y sobre todo en el catálogo de modelos que te ofrecen.

LM Studio es una aplicación de escritorio, con ventanas, buscador de modelos y un chat. Eliges el modelo, lo descargas, lo arrancas y hablas con él. También puede dejarlo escuchando en local para que opencode lo use. Es lo que estoy usando ahora, porque para probar y comparar modelos me resulta más cómodo verlo en pantalla. El catálogo es Hugging Face entero, sin filtro: Hugging Face es el sitio donde la gente publica estos modelos, el GitHub de los LLM digamos, y LM Studio te deja bajar casi cualquiera. Eso está bien para trastear, y también implica que te puedes descargar cosas mal convertidas o que luego no van. Es gratis, pero no es software libre: no publican el código, no puedes estudiarlo ni modificarlo.

Ollama hace lo mismo, pero desde la terminal. Escribes un comando para bajar el modelo y otro para arrancarlo. No hay tanto que configurar a mano, y para usarlo con opencode va muy bien. El código sí es abierto (licencia MIT), así que puedes ver cómo funciona y tocarlo si quieres. La diferencia gorda respecto a LM Studio es el catálogo: Ollama no te enseña Hugging Face al completo, sólo modelos que ellos han empaquetado y dan por buenos. Menos donde elegir, menos sorpresas. Si te manejas en la terminal, suele ser el camino más simple. Ya lo usé con opencode. El inconveniente, al menos para mí, es que controlas menos detalles: qué parte del modelo va a la GPU, cuánta memoria reserva, etc.

llama.cpp no es una aplicación para usuario final. Es el programa que realmente sabe ejecutar el modelo: le pasas el fichero, le dices cuánta memoria usar y si debe aprovechar la gráfica. Más preciso, más pesado de manejar. LM Studio y Ollama existen, entre otras cosas, para no tener que pelearte con eso. También es software libre, licencia MIT.

Hay otras interfaces, pero no las he usado en serio. Como tengo un Mac, suelo usar más LM Studio, porque en teoría está más optimizado para la arquitectura Silicon de Apple (los chips M). Tiene soporte integrado para MLX, el framework que Apple diseñó para exprimir sus chips. Necesitas que los modelos tengan versiones MLX, frente al estándar GGUF que es el habitual. Para los que están disponibles, sólo con eso, puedes duplicar la velocidad del modelo frente a ejecutarlo en Ollama con GGUF. Pero ten en cuenta que es un caso particular para la arquitectura Apple.

Qué significan los nombres de los modelos

Un modelo ocupa lo que ocupan sus parámetros por la precisión con la que los guardas. Las B de 7B, 8B o 32B son billions, miles de millones de parámetros. A más parámetros, en general más capacidad de razonar, aunque eso también depende mucho del entrenamiento.

La precisión es la cuantización: apretar esos pesos para que quepan en un equipo normal. El original suele venir en 16 bits, unos 2 bytes por parámetro, así que un 8B se te pone en unos 16 GB sin contar nada más. Demasiado para un portátil normal. Cuantizar es bajar a 8, a 4 o hasta a 2 bits, a costa de perder un poco de finura. Eso de cuantizar lo escucharás mucho hablando de modelos en local. A mí la palabra que más me gusta es lobotizar, porque en el fondo lo que haces con la cuantización es hacer un poco más torpe el modelo. Su entrenamiento es el mismo pero al quitarle precisión a los pesos es como cuando a ti te falta el café del lunes por la mañana. El Q4_K_M que verás habitualmente es el que casi todos usamos: unos 4 bits, medio byte por parámetro. Un 7B-8B se queda en 4 o 5 GB, un 32B en 18 o 20 GB. Si subes a Q8 ocupa casi el doble y apenas ganas inteligencia. Si bajas a 2 bits cabe en cualquier sitio, pero se vuelve torpe y para código no vale. Un 14B en Q4 suele darte más que un 7B en Q8 ocupando parecido.

Los nombres, una vez los desmontas, lo cuentan todo. Por ejemplo, qwen2.5-coder-7b-instruct-q4_K_M: Qwen es la familia, 2.5 la versión, coder que está afinado para código, 7b los parámetros, instruct que está entrenado para obedecer órdenes y no solo completar texto, y Q4_K_M la cuantización. Si ves un 26B-A4B es un Mixture of Experts: 26 mil millones en total pero solo activa 4 por cada token. Más rápido que un denso del mismo tamaño, aunque en disco y en memoria te ocupe como grande. En Mac además verás MLX frente a GGUF. GGUF es el formato más habitual. MLX está pensado para Apple Silicon y la memoria unificada. En el M1, MLX va mejor.

El equipo

Lo que decide qué modelo máximo puedes cargar es la memoria disponible. Y no todos los equipos funcionan igual.

En un PC con Nvidia dedicada tienes la VRAM de la gráfica, separada y muy rápida, y aparte la RAM del sistema. Si el modelo cabe en la VRAM, vuela. Si no cabe, LM Studio y llama.cpp hacen offload y tiran de CPU para el resto, que funciona pero va mucho más lento. Una 4060 de 8 GB es un mundo distinto a una 4090 de 24 GB.

En un Mac con Apple Silicon no hay VRAM separada, hay memoria unificada que comparten CPU y GPU. Puedes cargar modelos más grandes de lo que sugiere la etiqueta de gráfica: en un Mac de 32 GB metes un 30B cuantizado que en una Nvidia de 12 GB ni arranca. A cambio, esa memoria también se la come macOS, el navegador y todo lo demás, y el ancho de banda es menor que en una dedicada potente.

Luego están los portátiles con integrada Intel o AMD, sin gráfica dedicada. También comparten la RAM con el sistema, como el Mac, pero con peor ancho de banda, peores drivers y más trabajo en CPU. Para un 3B o un 7B pequeño en Q4, con paciencia, valen. Para lo demás, no.

Para hacerme una idea uso dos cuentas. La primera: coge lo que ocupa el modelo en disco, lo que Hugging Face dice que pesa, y multiplícalo por 1,2 si vas a usar contexto corto, de 4K, y por 1,5 o 1,6 si quieres ir a 32K con margen. La segunda: unos 0,6 GB por cada mil millones de parámetros en Q4, cerca de 1 GB por B en Q8, más el contexto.

El peso del fichero no es lo que te va a pedir en memoria. Es el punto de partida. Cuando arrancas el modelo, a esos pesos hay que sumarle la caché de clave-valor, donde guarda la conversación para no recalcularlo todo a cada token. Esa caché crece con la ventana de contexto que configures, con las capas del modelo y con lo largo que sea lo que le pegues. El mismo 8B con 4K te pide medio giga extra y ni lo notas. Con 32K, 2 o 4 GB más. Con 128K se te puede comer 8 GB él solo. Por eso dos personas con el mismo modelo pueden tener experiencias distintas: uno lo usa para chatear corto y le va fino, otro le pasa un repositorio entero con opencode y se le hunde.

Tomando Q4_K_M como referencia, y dejando aparte lo que se come el sistema, me salen más o menos estos números:

En un M1 de 16 GB, restando lo que se come macOS, quedan 10 o 12 GB de aire. Un 9B en Q4 te cabe, un 14B ya es ir justo y un 32B ni lo intentes. Si apuras, en cuanto le pegas un fichero un poco grande empieza el swap y todo va a pedales. Mejor un modelo un punto más pequeño con contexto de sobra que uno grande justo de memoria.

Lo otro que decide si trabajar es usable es la velocidad de la memoria. No es tanto la potencia de la CPU como cuántos gigas por segundo puede mover. Una RTX de gama alta de Nvidia anda por los 1000 GB/s, un Mac M1 por los 200. Los nuevos M5 Pro y Max pueden llegar hasta los 600 o 700 GB/s. Una arquitectura Intel o AMD integrada raramente podrá dar más de 100. Por eso el mismo modelo va mucho más rápido en una Nvidia buena. En mi equipo, un M1 Pro con 16 GB, Gemma 4B en Q4 se mueve a unos 50 tokens por segundo, que para chat sobra, y Qwen 3.5 9B en Q4 se queda en 20, un poco justo para picar código, pero factible para tareas pequeñas. Si tu prompt empieza por «hazme una aplicación que…» ni sueñes que te va a funcionar.

Chat no es lo mismo que herramientas

En LM Studio, en modo chat, casi todos los modelos parecen buenos. Les preguntas algo, te contestan con soltura y listo.

Con opencode es otra cosa. Ahí el modelo tiene que llamar a herramientas: leer un fichero, listar un directorio, aplicar un diff. Eso exige que sepa hacer function-calling, que genere el JSON que opencode espera y que no se ponga a explicarte cómo haría la tarea en vez de hacerla.

Me pasó con Gemma 4B en Q4_K_M: en chat perfecto, a 50 tokens por segundo, y en opencode no sabía gestionar las herramientas. Me devolvía un “para listar los ficheros deberías usar ls” en lugar de llamar a la herramienta. Tuve que tocar el system prompt para obligarle a ejecutar y no explicar, y aun así no era muy adecuado. Está afinado para ser asistente de chat, no para usar herramientas.

Qwen 3.5 9B en Q4_K_M sí me funciona con opencode. Llama a las herramientas, aplica el diff y no se pone a dar la charla. El pero es la velocidad: 20 tokens por segundo en el M1, un poco justo. Usable, pero se nota que el equipo va al límite.

Si lo quieres para agente, mira que diga que soporta tools o function-calling, y mejor una variante instruct o coder. Un Qwen de ese tipo está bastante más pensado para esto que un Gemma pequeño de chat. Y aun así puede hacer falta ajustar el system prompt en LM Studio.

En resumen

¿Qué puedes esperar de esto, al menos con la experiencia que tengo yo? Si quieres un chat, trabajar con documentos que no quieres mandar a un servidor que no controlas, o un asistente pequeño para el tren o para cuando no hay red, bien. A nivel de código la cosa se complica. Para tareas pequeñas, ordenar ficheros, scripts atómicos o cambios muy acotados en un repositorio, vale. Si quieres trabajar igual que con la herramienta de pago, sobre un repositorio grande, pedir análisis complejos, refactorings y demás, necesitas un equipo muy potente, yo diría que mínimo 64 GB de RAM, y afinar bastante la configuración, sea con LM Studio o con Ollama.

Los modelos de pesos abiertos que hay hoy ya son lo suficientemente listos para hacer casi cualquier cosa. Con un equipo potente y un buen harness se pueden hacer muchas cosas en local. El límite, la mayoría de las veces, no es el modelo. Es el ordenador y una buena configuración de herramientas.

¿Por qué Mercator se convirtió en el estándar?

La proyección de Mercator nació en 1569, cuando Gerardus Mercator publicó su mapa para navegantes. Su propósito original era facilitar la navegación marítima: en una proyección conforma, cualquier rumbo (línea de rumbo constante) se representa como una recta. Para los navegantes de la Edad de los Descubrimientos, eso era invaluable: podían trazar una línea recta entre dos puntos y mantener ese rumbo para llegar a destino.

Además, Mercator coincidió con el auge del comercio entre Europa y América, y su formato cilíndrico hacía que las regiones cercanas al ecuador se representaran con proporciones relativamente correctas. No es casualidad que el poder económico y naval de Europa en ese momento adoptara y difundiera esta proyección: la necesidad práctica de navegación la convirtió en el estándar marítimo.

Una vez que una herramienta demuestra su utilidad práctica y se extiende por la industria, desbancarla cuesta mucho. Los armadores, las marinas de guerra y los imperios coloniales ya tenían sus cartas de navegación, sus instrumentos y sus protocolos basados en Mercator. Cuando en los siglos posteriores surgieron nuevas proyecciones más precisas —como la de Lambert o la de Mollweide—, ya era tarde: la inercia institucional era demasiado fuerte. Los libros de texto, las colecciones cartográficas y la tradición náutica perpetuaron su uso durante siglos.

Hoy, la razón técnica que explica que Mercator siga presente en servicios como Google Maps o OpenStreetMap no es estética ni política: se debe a que en una proyección conforme, las líneas de rumbo constante se representan como rectas y las escalas locales se mantienen uniformes, lo que facilita enormemente el renderizado por teselas y los cálculos de routing. Pero ojo: lo que ves en tu móvil no es la Mercator original de 1569, sino Web Mercator (EPSG:3857), una adaptación moderna que usa las mismas fórmulas pero simplificadas: asume la Tierra como una esfera (no un elipsoide) para acelerar los cálculos de renderizado por teselas. Es técnicamente Mercator, pero no es la Mercator de los navegantes del siglo XVI.

Para trabajos que requieren precisión métrica —topografía, ingeniería, catastro, SIG profesional—, la cosa cambia: se usa UTM (Universal Transverse Mercator). UTM no es una proyección global como Mercator o Web Mercator. Divide la Tierra en 60 husos de 6° de ancho, cada uno con su propia proyección Mercator transversal local. Dentro de cada huso, la distorsión es mínima, lo que permite medir distancias y áreas con la precisión necesaria para obras civiles, planes de ordenación del territorio o emergencias. En España, por ejemplo, se usan los husos 29, 30 y 31 UTM (EPSG:25829, EPSG:25830 y EPSG:25831), y cada país tiene su propio CRS de referencia.

Lo cierto es que Mercator, y sus variantes, es una proyección excelente para medir el mundo, pero quizás no es la mejor cuando quieres ver cómo realmente es.

Nadie representa la realidad "tal como es"

El punto clave que la resolución de la ONU toca es que ninguna proyección cartográfica es perfecta. Es matemáticamente imposible proyectar una esfera en un plano sin distorsionar algo: ya sea área, forma, distancia o rumbo. Cada proyección sacrifica unas propiedades para preservar otras. Si quieres profundizar en este tema, ya traté antes de la Tierra al navegador en otro artículo del blog, donde expliqué cómo funcionan las proyecciones y por qué Web Mercator se convirtió en el estándar para los mapas web.

Por eso verás que en Mercator:

• Áreas se distorsionan cerca de los polos (Groenlandia aparece del tamaño de África, cuando en realidad es 14 veces más pequeña).
• Las formas se preservan localmente, pero la disposición global cambia.
• Las distancias son correctas solo entre puntos muy cercanos.

La proyección de Peters (o Gall-Peters) surgió como respuesta en 1970 justamente para denunciar esas distorsiones de área, pero desde el punto de vista técnico tampoco está "libre" de errores: la escala y las distancias no están correctamente representadas matemáticamente en todo el mapa.

Los mapas, como hace tiempo me enseñaron, nunca son neutros, son un elemento de comunicación, y como tal siempre tienen una intención. Lo bueno, es que hay muchas proyecciones para elegir. Por ejemplo, National Geographic lleva décadas apostando por una alternativa que equilibra mejor las formas y los tamaños de los continentes...

La National Geographic Society ha defendido consistentemente la proyección de Winkel Tripel para sus mapas mundiales desde la década de 1990. Winkel Tripel busca un compromiso: reduce las distorsiones de área cerca de los polos comparado con Mercator, y preserva mejor las formas que la proyección de Robinson. No es perfecta (ninguna lo es), pero para propósitos educativos y de representación global equilibrada, probablemente sea una buena elección.

La resolución de la ONU se alinea con este espíritu: fomentar que las personas entiendan que los mapas son herramientas diseñadas para fines específicos, no verdades absolutas. Mercator no es "malo", es simplemente una herramienta con más de 450 años de historia, diseñada para navegantes y heredera de las dinámicas de poder de su tiempo. Hoy, la elección de una proyección u otra debe responder a la tarea que tengamos entre manos, no a la imagen que el mapa proyecta de poder o territorio.

La importancia de enseñar qué es un mapa

Cuando voy a dar charlas a colegios y hablo de este tema, la reacción más habitual es sorpresa. El alumnado descubre que la Tierra no se parece al mapa que tienen en la pared del aula, y muchos profesores también se sorprenden. Y es que, aunque usamos mapas desde que tenemos uso de razón —en el móvil, en el cole, en la tele—, casi nunca nos enseñan qué es realmente un mapa: una representación parcial, decidida por alguien, con un propósito concreto.

Enseñar geografía sin explicar qué es una proyección es dejar a medias la formación. Los mapas son herramientas poderosas, pero solo si entendemos sus limitaciones. Si no, corremos el riesgo de creer que Groenlandia es del tamaño de África, que Europa es el centro del mundo o que los mapas son fotos fijas de la realidad.

La resolución de la ONU no pide prohibir Mercator. Pide educación. Y eso es lo más valioso que puede salir de todo esto: que la próxima generación no solo sepa usar un mapa, sino que entienda por qué ese mapa se dibujó así.

En mi setup de IA ya contaba que OpenCode Go es el canal del día a día: una suscripción barata a modelos open weight bien servidos, sin pelearte con la lotería de cada proveedor. En por qué OpenCode hablaba de la herramienta. Aquí va la otra mitad: con qué modelo entro a cada pelea, al menos en el momento en que escribo esto, y sabiendo que la lista de Go se mueve.

No es una tabla de benchmarks. Es el mapa mental que me ha salido de usarlo para picar código, planear cambios, revisar diffs, escribir posts y trastear con mapas y agentes. Donde creo que sé algo, aunque tampoco mucho.

El truco no es el modelo, es el reparto

Antes de nombres: la gracia de OpenCode no es casarte con uno. Es poder decir “esto va a plan con uno gordo y a construir con uno barato”, o “esto lo revisa otro que no ha escrito el código”. Los sub-agentes y el cambio de modelo en caliente no son florituras; son la forma de no quemar el cupo en basura y de no pedir poesía a un modelo de flash.

También ayuda recordar qué son de verdad estos “open source”: en la práctica, pesos abiertos con licencias variadas. Útiles, sí. Mágicos, no. La diferencia la marca más el prompt, el AGENTS.md del proyecto y lo que le dejas tocar, que dos décimas en un leaderboard.

Dicho esto, el catálogo de Go ahora mismo ronda familias como DeepSeek V4, Qwen 3.6/3.7, Kimi (K2.6, K2.7 Code, K3), GLM 5.1/5.2, MiniMax, MiMo, Grok 4.5 e Hy3. No uso todos al mismo nivel. Uso un núcleo y el resto entra cuando el núcleo se queda corto o caro.

Escribir código (el día a día)

Para implementar, refactorizar, arreglar un bug con el repo delante y dejar un diff razonable, me sigo encontrando muy a gusto con DeepSeek V4 Pro y con Kimi K2.7 Code. El primero me parece el caballo de tiro cuando la tarea es “entiende este proyecto y toca lo justo”. El segundo, cuando quiero un modelo que ya viene con cara de agente de código y no se pierde tanto en monólogos.

Si la cosa es mecánica —renombrar, rellenar boilerplate, un script corto, un test que ya sé cómo tiene que ser— bajo a DeepSeek V4 Flash o a MiniMax M2.7 / M3. Gastan poco, responden rápido y para el 60 % de lo que hago en un día de desarrollo sobran. Ahí el error típico es mandar al Pro lo que podría hacer el Flash: al final del mes notas el cupo, no la calidad.

Qwen 3.7 Plus (y el 3.6 Plus cuando toca) me salva cuando el stack se sale del camino trillado o necesito un poco más de “sentido común” de producto dentro del código. No es que DeepSeek falle; es que a veces Qwen propone un diseño menos rígido y me evita pelearme con una solución demasiado literal.

Planear antes de tocar

En modo plan —el de OpenCode que no escribe archivos, solo razona— no quiero al más barato. Quiero al que aguante contexto, no se invente módulos que no existen y sepa decir “esto son tres commits, no uno”.

Para el día a día de planear, suelo tirar de Grok 4.5, Qwen 3.7 Max o Kimi K3. Grok me funciona bien cuando el problema es ambiguo y hay que ordenar ideas (“¿qué harías tú con este bug de permisos y este MCP?”). Qwen Max cuando el plan es más de arquitectura o de desglosar un feature gordo. Kimi cuando el hilo es largo y el repo es denso: se le nota el entrenamiento en contextos largos.

Y luego está GLM 5.2. En mi experiencia se acerca mucho a un modelo frontera: cuando el lío es de verdad complejo, desatasca lo que los otros dejan a medias o empiezan a enquistar —dar vueltas, soluciones cosméticas, planes que no cierran. El pero es claro: es caro. En OpenCode Go me come los créditos a una velocidad que no me puedo permitir como default. Así que no entro con él. Lo saco cuando ya sé que voy a analizar un problema gordo, o cuando llevo un rato con Pro/Code/Max y veo que la sesión se atasca. Es el comodín de “ahora sí, piénsalo en serio”, no el destornillador de todas las mañanas.

El truco práctico: plan normal con Grok/Qwen/Kimi, escalada a GLM 5.2 solo si hace falta, y build con DeepSeek Pro o K2.7 Code. Mezclar las dos cosas en el mismo modelo “porque total…” es cómo acabas con un plan mediocre o con un diff carísimo —y si ese modelo es el GLM, además sin cupo a mitad de semana.

Revisar código (el que no has escrito tú… o sí)

Revisar es otra tarea. No es generar. Es leer con mala leche amable: offs-by-one, permisos, nombres, lo que el autor daba por sentado.

Para revisión me va mejor un modelo que no sea el mismo que acaba de escribir el parche, si puedo. DeepSeek V4 Pro y Qwen Max me han pillado tonterías que el generador daba por buenas; el Max sobre todo cuando la revisión es más de diseño (“¿tiene sentido esta capa?”) que de lint humano. Si el diff es delicado o el fallo se me resiste, a veces subo a GLM 5.2, con la misma regla de oro que en el plan: solo cuando compensa el gasto.

Lo que no hago es mandar a un Flash a “revisar en profundidad” un diff de trescientas líneas. Sale checklist genérico y sensación de seguridad falsa. Para un vistazo rápido sí; para mergear, no.

Redactar (posts, correos, textos que tienen que sonar a persona)

Aquí el mapa cambia. Un modelo excelente picando Python puede dejarte un párrafo que parece manual de microondas. Para escribir en español con tono —un post, una respuesta larga, un texto que luego vas a reescribir a mano— me quedo con Grok 4.5 o con Qwen 3.7 en sus variantes más capaces.

No es que redacten “como yo” solos. Nadie lo hace. Pero se dejan llevar mejor a un registro conversacional, admiten matices y no insisten tanto en el esquema de cinco puntos clave y conclusión. DeepSeek, en cambio, me empuja más al tono de documentación técnica aunque le pida crónica; útil a veces, rígido otras.

Para borradores basura —resumir una reunión, pasar apuntes a lista, traducir un README— Flash o MiMo y listo. No gastes el Max en poner títulos a un changelog.

Explorar, preguntar, “explícame este lío”

Cuando abro el repo ajeno o un rincón que no toco desde hace meses, quiero charla con herramientas: buscar, leer, volver a preguntar. Kimi K2.6 / K3 y Qwen Plus me cuadran. Si la pregunta es corta y no quiero contexto de media hora, DeepSeek Flash o MiMo V2.5: baratos, suficientes, y no me duele iterar diez veces.

Grok también entra aquí cuando la duda es más de criterio que de API (“¿merece la pena este enfoque o estoy sobreingenierizando?”). A veces necesitas un interlocutor, no un autocompletado con ego.

Agentes largos, MCP, muchas herramientas

Cuando la sesión es de verdad agéntica —muchas idas y venidas, MCP de QGIS, skills, permisos, subagentes— noto más las costuras. No todos los modelos “hablan herramientas” igual de bien aunque el harness sea el mismo.

En ese terreno me fío más de Kimi K2.7 Code, DeepSeek V4 Pro y MiniMax para flujos de ingeniería con varios pasos. Si el agente se pone tonto (llama mal a una herramienta, inventa rutas, se olvida del plan), no insisto veinte veces con el mismo: cambio de modelo o acorto el objetivo. La obstinación sale cara en tokens y en paciencia.

Los muy baratos (Flash, MiMo base, Hy3) los uso de apoyo o de subagente acotado, no de cerebro único de una sesión de dos horas.

Una chuleta que yo sí usaría

Sin pretender ciencia, el atajo mental me queda más o menos así:

La fila de abajo importa más de lo que parece. Go te da un techo de uso en dinero, no en “peticiones infinitas del modelo más caro”. Quien vive siempre en el Max —o peor, en el GLM 5.2— descubre el límite a mitad de semana. Quien reparte, llega a fin de mes y encima trabaja mejor, porque no usa un cañón para clavar una chincheta.

Lo que no te va a decir ninguna guía

Primero: tu stack no es el mío. Yo vivo entre Python, geo, administración a ratos, terminal y blogs. Si tu mundo es otro, el ranking se mueve. Prueba en tus repos, no en los míos.

Segundo: el modelo de moda de esta semana no tiene por qué ser tu default. En Go la lista cambia; lo estable es el hábito de elegir por tarea y de separar plan / build / review.

Tercero: el techo de calidad no lo pone solo el LLM. Lo pone el contexto del proyecto, las reglas, los skills y que tú sepas decir “no, eso no”. Sin eso, el Pro alucina con elegancia y el Flash alucina deprisa. Misma enfermedad, distinta velocidad.

Yo, de momento, me quedo con un mapa mental corto: Flash para el ruido, Pro/Code para el oficio, Max/Grok/K3 para pensar antes de romper nada, y GLM 5.2 en la reserva —casi frontera, casi de pago por placer, solo cuando el problema lo pide o la sesión se enquista. El resto del catálogo son variantes y recambios. Y si dentro de dos meses esta chuleta envejece, mejor: significará que los pesos abiertos siguen moviéndose, y que nosotros también.

Menos modelo fetiche, mejor reparto. Eso, al menos a mí, me está funcionando.

Y es que el problema no es que se liberen cosas. El problema es que se vacía el significado de una palabra que nos costó décadas construir.

Cuatro libertades, otra vez

En el software libre la brújula siempre fueron las cuatro libertades: usar el programa para cualquier propósito, estudiarlo, modificarlo y compartirlo, con o sin cambios. La Open Source Initiative tradujo esa idea a una definición práctica de licencias. No es un eslogan. Es un contrato social: si no puedes estudiar y cambiar lo esencial, no es libre aunque diga open en la caja.

Con la IA pasó lo previsible. Empezaron a circular modelos con licencias permisivas sobre los ficheros de pesos, y de ahí al titular de “modelo open source” había un paso muy corto y muy tentador. La OSI, después de un proceso largo y ruidoso, publicó la Open Source AI Definition 1.0. No inventa una filosofía nueva: aplica las mismas libertades a un sistema de IA.

Para que un sistema de IA se considere Open Source AI, tiene que permitirte usarlo, estudiarlo, modificarlo y compartirlo sin pedir permiso. Y aquí viene la parte que a mucha gente le molesta: una precondición de esas libertades es tener acceso a la forma preferida de hacer modificaciones. En software clásico eso es, básicamente, el código fuente. En aprendizaje automático no basta con un binario bonito.

De qué está hecho un modelo (y qué habría que liberar)

Un LLM no es un programa al uso. Es más bien el resultado de un proceso industrial: datos, código, cómputo y parámetros. Si uno se pregunta qué habría que liberar para que las cuatro libertades sean reales, la OSI lo deja bastante claro en tres bloques.

Información sobre los datos. No siempre se puede redistribuir el dataset entero —hay derechos de terceros, datos personales, contratos— y la definición no es ingenua al respecto. Pero sí exige información suficientemente detallada como para que una persona competente pueda construir un sistema sustancialmente equivalente: procedencia, alcance, cómo se obtuvieron y seleccionaron los datos, etiquetado, filtrado, qué partes son públicas y dónde están, qué partes se compran a terceros y a quién. Sin eso, “estudiar el sistema” se queda en mirar el escaparate.

Código. El código completo para entrenar y ejecutar el sistema. Procesado y filtrado de datos, entrenamiento con sus argumentos y ajustes, validación, librerías de apoyo, tokenizadores, código de inferencia, arquitectura. Es decir: no solo el script de demo que carga el modelo y te contesta en el terminal.

Parámetros. Los pesos y demás configuración aprendida. Idealmente también checkpoints intermedios y estado del optimizador cuando aplique. Esto es lo que la gente descarga cuando dice “me he bajado el modelo”.

Si te fijas, liberar solo el último de los tres es como publicar el ejecutable compilado y decir que el software es libre porque cualquiera puede copiar el binario. Puedes usarlo, a veces incluso adaptarlo un poco, pero no puedes reconstruir el camino. Y sin el camino, la libertad de estudiar y modificar de verdad se queda a medias.

Hay otra forma de verlo, más de oficio: el valor de un modelo grande no está solo en el fichero final. Está en la receta, en las decisiones de filtrado, en lo que se dejó fuera, en lo que se reforzó en el alineado, en los fallos que se corrigieron a mitad de entrenamiento. Esa es la parte que casi nunca se abre del todo. Y es justo la parte que permitiría auditar sesgos, reproducir resultados o mejorar el sistema desde fuera sin empezar de cero cada vez.

Entonces, ¿qué son los open weights?

Pues eso: pesos abiertos. Modelos en los que se publican los parámetros finales —a veces bajo Apache 2.0, MIT u otra licencia razonable; a veces bajo licencias propias con condiciones extra— para que cualquiera pueda descargarlos, ejecutarlos, hacer fine-tuning o montar un servicio encima.

No es poca cosa. Respecto a un modelo solo accesible por API, la diferencia es enorme. Puedes correrlo en tu máquina, no mandar tu código a un tercero, elegir el hardware, afinarlo para un dominio, o montar infraestructura propia. En un país, en una empresa o en una administración, eso cambia el tablero de la dependencia. Yo, que estos meses he estado usando modelos en local para escribir, programar y trastear con mapas, lo noto cada día: no es lo mismo alquilar inteligencia por token que tener el artefacto en casa.

Pero open weight no es open source en el sentido de la definición de la OSI. La propia OSI lo explica sin rodeos: los pesos abiertos no incluyen, por lo general, el código de entrenamiento completo ni la transparencia fuerte sobre los datos. Te dan el resultado del entrenamiento, no el proceso. Sirven para desplegar y adaptar; sirven mucho menos para reproducir, auditar de verdad o colaborar en la raíz del sistema.

Es un término útil, siempre que no se use como disfraz. El problema empieza cuando el marketing convierte “pesos abiertos” en “open source” y nos vamos acostumbrando a la trampa. Verdades a medias, otra vez: sí, es más abierto que un modelo cerrado; no, no es software libre con otro nombre.

Licencias que parecen libres (y no siempre lo son)

Aquí el software libre también tiene memoria. Hay licencias que parecen permisivas y luego meten una cláusula que rompe la libertad de uso para cualquier propósito, o la de compartir sin pedir permiso. En modelos pasa igual. Hay familias muy populares cuya licencia permite mucho… hasta que superas un umbral de usuarios o compites en cierto terreno. Otras son genuinamente permisivas sobre los pesos, y aún así el entrenamiento sigue siendo secreto industrial.

Desde el punto de vista ético del software libre, la pregunta no es solo “¿puedo descargarlo?”. Es “¿puedo usarlo para lo que me dé la gana, entender cómo se hizo, cambiarlo de verdad y pasar ese cambio a otra persona sin negociar con el dueño original?”. Si alguna de esas puertas está cerrada o solo entreabierta, llamarlo open source es, como mínimo, un abuso del diccionario.

Y conste que el modelo de negocio de no abrir el entrenamiento es lícito. Faltaría más. Igual que es lícito vender software privativo. Lo que no me parece de recibo es apropiarse del prestigio moral y técnico que el movimiento libre construyó, para vender como libertad lo que en realidad es una distribución controlada de un artefacto.

Por qué importa, más allá del purismo

Se puede pensar que esto es discusión de puristas. Yo creo que no. Cuando una administración pública o una empresa estratégica apuesta por un modelo “abierto”, la letra pequeña decide si estás reduciendo dependencias o solo cambiando de dueño. Si solo tienes pesos, puedes ejecutar y adaptar; si mañana necesitas reentrenar desde una base auditable, entender un fallo sistemático o demostrar cómo se construyó el sistema, te encuentras otra vez pidiendo permiso o reinventando la rueda.

En software libre aprendimos que la conveniencia mueve más que la filosofía. Por eso el statu quo siempre es frágil. Ahora mismo conviene a bastantes actores soltar pesos y quedarse el resto: ganan adopción, narrativa de apertura y una comunidad que mejora el producto en la capa de arriba, sin tocar la fábrica. Es un avance respecto al secretismo total. También es un techo de cristal si nos dormimos en la etiqueta.

A mí los pesos abiertos me parecen una buena noticia, y los uso. Me parece mejor un Llama, un Qwen, un Gemma o un DeepSeek descargable que un muro de API con términos que cambian cada trimestre. Pero no confundo el alivio con la llegada a destino. Open weight es un paso. Open source AI, de verdad, es otra cosa.

Mientras tanto, en los despachos

Y mientras debatimos esto en blogs y foros, gobiernos y agencias de supervisión de la IA hablan sin parar de ética, de confianza, de IA centrada en las personas. La pregunta es en qué se están fijando de verdad.

La respuesta, simplificando, es casi siempre la misma: en el uso. El Reglamento europeo de IA es el ejemplo más claro. Clasifica sistemas por riesgo, prohíbe prácticas inaceptables, exige supervisión humana, documentación, trazabilidad, etiquetado de contenido generado y, para los modelos de propósito general, transparencia y ciertas obligaciones sobre derechos de autor y seguridad. La Oficina Europea de IA y, aquí en España, la AESIA, nacen sobre todo para vigilar eso: que no se despliegue cualquier cosa en sanidad, empleo, fronteras o justicia; que la ciudadanía sepa cuándo habla con una máquina; que haya alguien a quien reclamar cuando el sistema falla.

Todo eso es necesario. Faltaría más. Un modelo libre mal usado también puede hacer daño, y el derecho a no ser discriminado por un algoritmo no se resuelve solo con una licencia OSI. Pero si miras el tablero con gafas de software libre, se ve el hueco enseguida: se regula el comportamiento del sistema en producción mucho más que la libertad de estudiarlo y reconstruirlo.

Cuando el reglamento pide un resumen público del contenido de entrenamiento de los modelos de propósito general, no está pidiendo el dataset ni la receta completa. Pide un mapa a grandes rasgos: fuentes, dominios, algo de procesado. Útil para ejercer derechos y para periodistas o investigadores con paciencia. Insuficiente para lo que la OSI llama la forma preferida de hacer modificaciones. Transparencia de cumplimiento no es lo mismo que apertura radical. Se parece más a la ficha técnica de un electrodoméstico que al código fuente de un compilador.

Lo mismo pasa con buena parte de las estrategias nacionales y de las “agencias de IA ética”. El centro de gravedad está en el riesgo del despliegue, en la gobernanza del proveedor, en la evaluación de impacto, en no comprar sistemas prohibidos. Casi nunca en exigir —ni siquiera en priorizar de verdad en la compra pública— modelos que uno pueda auditar de extremo a extremo, reentrenar con datos propios o mantener sin volver a pasar por caja del fabricante. Se habla de soberanía tecnológica, y a veces se financia un modelo europeo “abierto”; luego, al mirar la letra pequeña, vuelves a encontrarte pesos, licencias a medias y poca fábrica a la vista.

No es que no se mueva nada. Hay iniciativas de modelos abiertos con dinero público, hay excepciones o tratos más suaves para ciertos sistemas de código abierto en el propio reglamento, hay gente dentro de la administración que entiende la diferencia. Pero la corriente principal sigue siendo otra: ética del uso, no ética de la libertad del artefacto. Como si bastara con poner guardarraíles al coche sin preguntar si podemos abrir el capó, fabricar recambios o enseñar a otra persona a arreglarlo.

Desde el mundo del software libre, esa frontera es vieja. Llevamos años diciendo que no basta con que el programa “haga las cosas bien” si no puedes mirar cómo las hace y cambiarlas cuando dejen de hacerlas bien. Con la IA el argumento se vuelve más urgente, no menos: si el Estado y las agencias se conforman con fichas de transparencia y evaluaciones de riesgo sobre cajas negras —aunque sean cajas negras con pesos descargables—, estaremos domesticando el relato ético sin acercarnos de verdad a modelos que se parezcan al software libre.

En nuestras manos está, también como ciudadanía y como sector técnico, empujar la conversación un poco más lejos. No solo ¿se usa bien esta IA?, sino ¿podemos estudiar, modificar y compartir de verdad el sistema con el que nos gobiernan o nos atienden?. Porque si la respuesta es no, la ética se queda en el manual de instrucciones. Y el manual, ya se sabe, lo escribe quien tiene la llave de la fábrica.

Los Sistemas de Información Geográfica (SIG) son herramientas increíblemente potentes, pero también complejas. QGIS es probablemente el SIG de escritorio de software libre más completo y usado del mundo, pero su interfaz tiene una curva de aprendizaje pronunciada. Y aunque sepas usarlo bien, muchas tareas son repetitivas (cargar capas, aplicar estilos, configurar layouts).

¿Y si pudieras decirle a un agente de IA lo que quieres hacer y que lo ejecute directamente sobre QGIS? Sin arrastrar capas, sin buscar el botón correcto, sin recordar dónde está cada opción.

Eso es exactamente lo que permite el MCP de QGIS.

Pero como todo lo que merece la pena, la configuración no siempre sale a la primera. En este artículo te explico qué es MCP, cómo se conecta con QGIS con un agente de IA (OpenCode), la configuración paso a paso, problemas reales que me encontré al hacerlo funcionar, y ejemplos prácticos para sacarle partido.

¿Qué es MCP?

MCP (Model Context Protocol) es un protocolo abierto que permite a modelos de lenguaje (LLMs) interactuar con herramientas y sistemas externos de forma estructurada y segura.

Piénsalo como un USB para la IA: igual que el USB estandarizó la conexión de periféricos al ordenador, MCP estandariza la conexión de la IA con el mundo exterior: bases de datos, APIs, sistemas de archivos y, en este caso, QGIS.

Sin MCP, si le pides a una IA que "cargue un shapefile y lo pinte con un gradiente", lo máximo que puede hacer es generarte el código Python y decirte "copia esto en la consola de QGIS". Con MCP, la IA ejecuta las acciones directamente sobre QGIS.

El flujo es sencillo:

1. Haces una petición en lenguaje natural: "Carga la capa de municipios y coloréalos por población"
2. OpenCode envía la petición al modelo
3. El modelo decide qué herramientas del MCP de QGIS necesita usar
4. Las ejecuta directamente sobre tu QGIS abierto
5. El resultado aparece al instante en tu mapa

Cómo funciona el MCP de QGIS

Arquitectura

Antes de pasar a la configuración, conviene entender cómo se conectan las piezas:

opencode ←→ MCP Server (stdio/HTTP) ←→ TCP :9876 ←→ Plugin QGIS ←→ PyQGIS

El plugin QGIS MCP (github.com/nkarasiak/qgis-mcp) de nkarasiak expone más de 100 herramientas de QGIS a través del protocolo MCP. Pero ojo: el plugin no habla MCP directamente. Tiene un socket TCP interno en el puerto 9876 que solo entiende comandos JSON con un formato propio. Para que opencode (o cualquier cliente MCP) pueda hablar con él, hace falta un MCP Server intermedio que traduzca el protocolo MCP a los comandos que el plugin entiende.

Ese servidor intermedio se ejecuta con uvx y es el que realmente configuraremos en opencode.

Herramientas disponibles

El MCP de QGIS expone las funcionalidades del SIG como herramientas que el agente IA puede invocar. Cada herramienta hace una operación específica:

Hay más de 100 herramientas disponibles. La lista completa cambia con cada versión, pero cubre prácticamente todo lo que harías manualmente en QGIS.

Configuración paso a paso

1. Pre-requisitos

Necesitas tres cosas:

• QGIS instalado (cualquier versión reciente vale, incluida la 4)
• QGIS MCP Plugin instalado en QGIS
• OpenCode instalado
• uv instalado (lo usa uvx para ejecutar el MCP Server sin instalar nada)

2. Instalar el plugin en QGIS

El plugin se llama QGIS MCP. Lo instalas desde el menú de QGIS:

Complementos → Gestionar e instalar complementos... → Buscar "QGIS MCP" → Instalar

Una vez instalado, lo activas desde el menú MCP → Start Server. El plugin se queda escuchando en un socket TCP interno en el puerto 9876.

Puedes comprobar que está vivo:

curl -X POST http://localhost:9876/ -H "Content-Type: application/json" -d '{"action":"ping"}'

3. Configurar OpenCode

Aquí es donde la mayoría de la documentación existente se queda corta. El plugin de QGIS no expone un servidor MCP directamente — solo entiende comandos JSON sobre un socket TCP. Necesitamos un proceso intermedio que haga de traductor.

OpenCode se configura en ~/.config/opencode/opencode.jsonc (o en un opencode.jsonc en la raíz de tu proyecto):

{
  "mcpServers": {
    "qgis": {
      "type": "local",
      "command": [
        "uvx",
        "--from",
        "https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip",
        "qgis-mcp-server",
      ],
    },
  },
}

Con type: "local", opencode lanza el MCP Server como un subproceso cada vez que arranca. El servidor se comunica con el plugin de QGIS a través del puerto 9876 y expone todas las herramientas a opencode vía MCP.

4. Verificar la conexión

Arranca OpenCode en cualquier directorio:

opencode

Si todo funciona, verás el servidor MCP de QGIS en el panel de herramientas de opencode, listo para aceptar comandos.

Problemas y soluciones

Hasta aquí la teoría. Ahora la práctica, con los problemas reales con los que me topé.

Antes de entrar en cada problema, conviene aclarar: el plugin QGIS MCP está bien documentado. Su README en GitHub incluye la configuración correcta para opencode y para otras herramientas (Claude Code, Codex CLI, Gemini CLI, Cursor, etc.). Los problemas que encontré no fueron por documentación incorrecta, sino por dos cosas:

1. La arquitectura no es evidente hasta que la ves. El plugin tiene dos componentes: un proceso dentro de QGIS (socket TCP) y un servidor MCP externo (uvx). Si no sabes que existe esa separación, es fácil asumir que el plugin expone MCP directamente y configurarlo mal.
2. El README asume que el lector conoce uvx. La compilación de dependencias nativas en la primera ejecución no se menciona, y el timeout de opencode (30s) no es suficiente para ese arranque inicial.

Dicho esto, van los problemas.

Problema 1: Conectar al puerto equivocado

Si ya sabes cómo configurar servidores MCP puede que vayas directamente a opencode y lo hagas con type: "url" apuntando a http://localhost:9876, asumiendo que el plugin de QGIS habla MCP directamente. Pero no: el plugin solo entiende comandos JSON sobre un socket TCP, no el protocolo MCP. Es como intentar hablar HTTP contra un servidor que solo entiende el protocolo de Redis. El plugin viene con un configurador para diferentes agentes, incluido opencode.

Solución:
Usar type: "local" con uvx como se muestra en la configuración de arriba. El qgis-mcp-server es el proceso intermedio que traduce de MCP a los comandos JSON que el plugin entiende. O, alternativamente, tener el servidor HTTP ejecutándose de forma persistente (lo explico al final de esta sección).

Problema 2: Timeout en la primera ejecución

La primera vez que opencode ejecuta uvx --from https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip qgis-mcp-server, uvx descarga el código y compila dependencias nativas como cryptography. Esta compilación puede superar los 30 segundos, que es el timeout que opencode tiene por defecto para la inicialización de servidores MCP.

Solución:
Ejecutar el comando manualmente una vez antes de arrancar opencode, para que uvx descargue y compile todo y lo deje en caché:

uvx --from https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip qgis-mcp-server

La primera ejecución puede llevar más de un minuto. Las siguientes serán casi instantáneas.

Si aún así quieres más margen, opencode permite configurar el timeout por servidor MCP:

{
  "mcpServers": {
    "qgis": {
      "type": "local",
      "timeout": 120000,
      "command": [
        "uvx",
        "--from",
        "https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip",
        "qgis-mcp-server",
      ],
    },
  },
}

Ejemplos prácticos

Cargar y visualizar datos

Pídele que cargue archivos directamente desde tu ordenador y los deje listos para trabajar:

Carga el fichero municipios.gpkg que está en mi escritorio, nómbralo "Municipios" y aplícale un estilo graduado por el campo poblacion usando 5 clases con la rampa de color Viridis.

Añade un fondo OSM con el servicio XYZ.

En segundos tienes la capa en QGIS con el estilo aplicado. Sin ir a buscar el archivo en el navegador de capas, sin acordarte de dónde está el estilo graduado.

Manipular datos

Puedes crear campos nuevos, hacer consultas, filtrar, etc. todo en lenguaje natural:

En la capa Municipios, calcula la densidad de población en un nuevo campo llamado densidad.

¿Cuántos municipios tienen más de 50000 habitantes? Dame los nombres.

El agente consulta los datos, los procesa y te responde con la información. No necesitas saber SQL ni recordar la sintaxis de la calculadora de campos.

Análisis espacial

Las operaciones que antes requerían varios clics en el menú Processing ahora se resuelven con una frase:

Haz una unión espacial entre la capa de municipios y la de estaciones meteorológicas, para que cada municipio tenga el nombre de la estación más cercana.

Calcula la altitud media de cada municipio a partir del raster MDT05 y crea un campo nuevo con esos valores.

Crear mapas y layouts

Le dices cómo quieres el mapa y él lo monta:

Crea un layout llamado "Mapa General", tamaño A4 horizontal. Añade un mapa que ocupe toda la página, una leyenda y una barra de escala. Luego expórtalo como PNG.

Configura un atlas con la capa Municipios. Cada página debe mostrar un municipio. Exporta el atlas como PDF.

Trabajar con el proyecto

También puedes gestionar el proyecto al vuelo:

Guarda el proyecto actual como "analisis.qgz" en el escritorio.

¿Qué capas tengo cargadas ahora mismo en el proyecto?

Limitaciones y consideraciones

No es mágico

El MCP de QGIS es tan potente como el modelo que tengas detrás. Los modelos más capaces (Gemini, Claude, GPT-4) entienden bien el contexto geoespacial y saben qué herramienta llamar en cada caso. Los modelos más pequeños pueden confundir herramientas o necesitar prompts más explícitos. Puedes apoyarte en skills o ficheros de memoria de contexto para ayudarles.

Mapas para imprimir

Usar herramientas de procesado es relativamente sencillo para un LLM, incluso si le pides que cree estilos suele ser bastante eficiente. Pero conseguir que te haga un mapa profesional para imprimir ya es otra cosa.

Pueden trabajar con el layout de mapas, pero conseguir que de primeras hagan un buen diseño no es fácil, aquí es donde está más verde. Necesitarás instrucciones detalladas, un buen modelo e incluso crear skills de diseño si quieres conseguir mapas que puedas considerar como versiones finales.

Necesitas QGIS abierto

El plugin MCP de QGIS actúa como servidor, pero necesita que QGIS esté ejecutándose. Si cierras QGIS, pierdes la conexión. Puedes tener QGIS minimizado, pero tiene que estar abierto.

Operaciones destructivas

Herramientas como remove_layer o delete_features están disponibles, pero el plugin las trata con cuidado. OpenCode también te pide confirmación antes de ejecutar operaciones que modifican datos. Aun así, es recomendable trabajar sobre copias cuando hagas pruebas.

Latencia

Cada llamada al MCP viaja de OpenCode al modelo, del modelo de vuelta, y luego se ejecuta en QGIS. No es instantáneo. Para operaciones simples (cargar una capa, cambiar estilo) es rápido. Para geoprocesos pesados (uniones espaciales, estadísticas zonales), el tiempo depende de la carga de trabajo.

Conclusión

Esto está empezando a eclosionar. Estamos viendo cómo la IA se integra en herramientas que antes requerían años de práctica: programas de retoque fotográfico, diseño 3D, edición de vídeo… herramientas complejas que ahora empiezan a entenderse sin conocerlas a fondo.

Con los SIG pasa algo parecido, pero con un matiz importante: para ciertas tareas como retocar una foto es fácil saber lo que quieres aunque no seas fotógrafo, y aún así te quedarás en la superficie, comparado con alguien con experiencia en la profesión. Analizar datos geográficos, crear mapas o interpretar resultados requiere formación. La IA no sustituye ese conocimiento, pero sí acelera los procesos: ejecuta operaciones, prueba combinaciones, genera mapas base que luego puedes ajustar.

Yo sigo pensando lo mismo que meses atrás, cuando todo esto empezó a explotar. Estamos ante el mayor avance en el mundo de la informática después del ratón. La IA está cambiando por completo la forma en la que interactuamos con el software, y eso de por sí, ya es una maravilla.

En esta fase inicial, probar está bien. De hecho, es necesario. El mercado se mueve tan rápido que no sabes qué te va a funcionar hasta que lo usas en el día a día. Pero llega un momento en el que tienes que elegir una como base. No para siempre, no de forma exclusiva, pero sí como herramienta principal en la que invertir tiempo en configurar, aprender y construir un flujo de trabajo alrededor.

Este post es mi justificación personal de por qué OpenCode es esa herramienta para mí.

El problema de elegir

Cada herramienta tiene sus ventajas, pero también un coste de aprendizaje. No me refiero solo al dinero, sino al tiempo que dedicas a entender su funcionamiento, ajustarla a tu forma de trabajar y sacarle partido. Ese tiempo es limitado, y si lo repartes entre varias herramientas diferentes, corres el riesgo de no profundizar en ninguna lo suficiente como para que realmente te aporte valor.

Además, cada vez que cambias de herramienta, pierdes parte de lo acumulado: los atajos de teclado que ya sabías, los ajustes que habías hecho, los flujos que habías optimizado. Empezar de cero con una herramienta nueva no es solo instalarla, es volver a pasar por la curva de aprendizaje hasta que empieza a ser realmente productiva.

En un mercado donde cada semana sale algo nuevo, es fácil caer en el FOMO y estar saltando de una herramienta a otra sin llegar a sacar partido de ninguna. Pero el valor real no está en haber probado muchas herramientas, sino en conocer una bien y haber construido un flujo de trabajo alrededor de ella.

Eso no significa cerrarse a probar cosas nuevas. Significa tener una base sobre la que construir, y a partir de ahí explorar con criterio.

Esta decisión no es tan diferente de las que hemos tomado siempre las personas que nos dedicamos al desarrollo de software al elegir un IDE. Antes era escoger entre VS Code o IntelliJ, y si nos vamos algo más atrás en el tiempo, la guerra Vim o Emacs, y esa decisión definía tu forma de trabajar durante años. La diferencia es que entonces el IDE era una herramienta que comprabas una vez o era gratis, y punto. Ahora la IA viene integrada en el IDE, y con ella llegan las suscripciones mensuales, los límites de uso y los cambios de precio que pueden dejar obsoleta tu configuración de la noche a la mañana. El coste recurrente añade una capa nueva a una decisión que antes era más estable.

Por qué OpenCode

La razón principal es simple: OpenCode es libre. No depende, en exclusiva, de ninguna empresa ni de sus decisiones comerciales. Si mañana OpenAI decide cambiar sus precios, si Anthropic modifica su política de uso, si Cursor elimina el plan gratuito, o los compra alguien, ninguna de esas decisiones afecta a mi capacidad de seguir trabajando con OpenCode. Cambio de proveedor, cambio de modelo, y mi herramienta sigue siendo la misma.

Eso tiene implicaciones prácticas importantes:

• Puedo cambiar de modelo sin cambiar de herramienta. Hoy uso un modelo frontier para tareas que requieren mucho contexto, un modelo específico open-source para codificar, otro para consultas rápidas y baratas. No tengo que adaptarme a un CLI diferente ni aprender otra interfaz.
• Puedo ejecutar modelos locales. Conecto LM Studio, Ollama o el servidor que quiera, y OpenCode habla con él igual que con cualquier API cloud. Ninguna herramienta cerrada te da tanta flexibilidad.
• No hay vendor lock-in. Si un proveedor sube precios o baja calidad, lo cambio sin tocar nada de mi setup. Mi inversión en skills, MCPs y configuración es portable.
• Puedo ver el código, entenderlo y contribuir. No es solo una cuestión ideológica: cuando algo no funciona como espero, puedo mirar el código, saber por qué ocurre y a veces incluso arreglarlo.

Dicho de otro modo: OpenCode es la herramienta que se adapta a mi flujo de trabajo, en lugar de obligarme a adaptar mi flujo de trabajo a ella.

OpenCode en general

Para quien no lo conozca, OpenCode es un agente de IA para desarrollo que se ejecuta en el terminal. Es software libre y está disponible en GitHub. Pero lo que realmente lo diferencia no es solo que sea gratuito, sino cómo está construido.

Arquitectura cliente-servidor

A diferencia de Cursor (atado a su editor) o Claude Code y Codex, con sus aplicaciones específicas, OpenCode separa el servidor del cliente. El servidor gestiona sesiones, proyectos y conexiones con modelos, y los clientes son intercambiables:

• TUI (terminal): la interfaz principal, con navegación por teclado, paneles divididos y una experiencia comparable a un IDE dentro del terminal.
• Interfaz web: opencode web levanta un servidor HTTP con múltiples sesiones visibles a la vez, accesible desde cualquier navegador. Con Tailscale o soluciones similares, puedes conectarte a tu opencode en tu equipo principal desde otros dispositivos, como si estuvieras en local.
• IDE plugin: puede conectarse desde VS Code o cualquier editor que soporte el protocolo.

El resultado es que tienes un único servidor con todas tus sesiones, y puedes conectarte desde donde quieras. Todas comparten el mismo estado.

Agentes

OpenCode tiene dos modos de trabajo que cambian cómo interactúas con el agente, en realidad viene con dos agentes predefinidos:

• Plan Mode: el agente solo explica lo que haría, sin tocar nada. Ideal para tareas complejas donde quieres revisar el enfoque antes de ejecutar.
• Build Mode: el agente ejecuta los cambios directamente.

Cambias entre ellos con TAB, sin comandos ni menús. Si el plan no te convence, ajustas el prompt y vuelves a intentarlo. Si el resultado no es lo que esperabas, /undo revierte los cambios al instante.

Sub-agentes

OpenCode permite definir sub-agentes: instancias especializadas que usan modelos y prompts diferentes para tareas concretas. Puedes tener un agente para revisión de código que use un modelo más lento pero más preciso, otro para scripting rápido con un modelo ligero, otro para documentación. El agente principal delega en ellos según la tarea, todo de forma transparente. Para cada sub-agente puedes definir si tiene permisos de escritura o no, que herramientas puede usar, etc.

A través de la interfaz puedes ir viendo cuáles están trabajando y lo que hacen.

AGENTS.md: contexto que viaja con el proyecto

Cuando ejecutas /init en un proyecto, OpenCode analiza el código y genera un AGENTS.md con la estructura, las tecnologías, las convenciones y los patrones que detecta. Ese archivo se incluye en el contexto del modelo en cada sesión. El resultado es que el agente entiende tu proyecto desde el primer prompt, sin que tengas que explicarle nada.

Sesiones persistentes

Cada proyecto mantiene su historial guardado en SQLite. Puedes retomar una sesión días después y el agente recuerda lo que estabais haciendo. También puedes compartir sesiones con tu equipo mediante /share, que genera un enlace con toda la conversación.

Personalización

Skills, MCPs y system prompts son funcionalidades que OpenCode ofrece igual que otras herramientas, pero con un enfoque abierto: todo se configura con archivos markdown y JSON en ~/.config/opencode/, sin formatos propietarios ni dependencias de servicios externos.

Cómo empezar

La instalación es sencilla y hay varias opciones:

curl -fsSL https://opencode.ai/install | bash
npm install -g opencode-ai
brew install anomalyco/tap/opencode
scoop install opencode
docker run -it --rm ghcr.io/anomalyco/opencode

Una vez instalado, opencode desde tu proyecto arranca el TUI. Con /connect eliges tu proveedor y ya puedes empezar. Si corres /init primero, el agente analizará tu proyecto y generará el AGENTS.md automáticamente.

Gestión de modelos: por qué tener varios

Uno de los aspectos que más valoro de OpenCode es la capacidad de elegir el modelo según la tarea. No uso el mismo modelo para todo, y tener esa flexibilidad cambia completamente la relación coste/beneficio del setup:

• Tareas rápidas y baratas: DeepSeek V4 Flash o Gemma 4 en local para debugging rápido, scripting o preguntas concretas. Casi cero coste, respuesta inmediata.
• Tareas generales de desarrollo: Kimi K2.6,Qwen 3.6 Plus o GML 5 desde OpenCode Go. Cubren el día a día sin preocuparme por el coste.
• Tareas complejas o contexto grande: Gemini 3.1 o Claude Opus desde OpenCode Zen o mi cuenta de Gemini. Solo cuando realmente lo necesito.

Esta granularidad no es posible si tu herramienta te obliga a usar un solo proveedor o un solo modelo. Y el ahorro, tanto en coste como en calidad del resultado, es notable.

Cierre

No estoy diciendo que OpenCode sea la mejor herramienta para todo el mundo. Es importante probar, experimentar y buscar la que te hace tener más comodidad y poductividad en el día a día. Pero está bien mirar un poco más allá de las funcionalidades simplemente y analizar también los modelos que hay detrás, las implicaciones que tiene que las decisiones comerciales de las empresas terminen impactando directamente en tu día a día.

Si valoras la libertad de elegir, la capacidad de adaptar la herramienta a tu flujo de trabajo y no depender de las decisiones comerciales de una empresa, a día de hoy OpenCode es difícil de superar.

En un mercado donde las herramientas de IA cambian cada semana, tener una base libre, flexible y abierta no es un lujo: es una decisión estratégica. Ojalá haya más herramientas que sigan esta filosofía.

Qué es OpenCode Web

OpenCode funciona con una arquitectura cliente-servidor. Cuando abres el TUI en el terminal, estás ejecutando un cliente que se conecta a un servidor local. Ese servidor expone una API HTTP, y OpenCode Web es simplemente otra interfaz para ese mismo servidor.

Para arrancarlo, solo necesitas un comando:

opencode web

Esto levanta un servidor local en un puerto aleatorio y abre el navegador con la interfaz web. Es exactamente la misma experiencia que en terminal: misma sesión, mismos modelos, mismo contexto.

La diferencia está en lo que eso habilita.

Por qué la uso: múltiples proyectos y acceso remoto

La razón principal por la que he empezado a usar OpenCode Web no es estética ni de comodidad en el escritorio. Es la posibilidad de gestionar varios proyectos a la vez desde un único punto.

Cuando trabajas con el TUI en el terminal, cada ventana es un proyecto. Si tienes tres proyectos abiertos, tienes tres terminales, tres pestañas, tres contextos. Con OpenCode Web puedes tener todas las sesiones activas visibles en una sola interfaz, cambiar entre proyectos con un clic y mantener el hilo de cada uno sin perder el contexto.

Pero lo que realmente me hizo empezar a usarla más fue el acceso remoto.

Mi equipo principal es un Mac M1 Pro donde tengo todos mis proyectos, configuraciones, MCPs, skills y recursos. Normalmente trabajo desde ahí. Pero hay situaciones en las que no estoy sentado delante de esa máquina.

Con Tailscale, la herramienta que uso para tener una red privada, me conecto al servidor OpenCode de mi equipo principal desde el navegador de cualquier dispositivo. Abro el iPad, entro en la dirección de Tailscale y tengo acceso a todo: mis sesiones, mis proyectos, mis configuraciones. No es lo mismo que estar delante del terminal principal, pero me ha sacado de más de un apuro.

Configuración básica

Para que esto funcione, necesitas tres cosas:

1. Arrancar OpenCode Web con acceso a la red:

opencode web --hostname 0.0.0.0 --port 4096

El flag --hostname 0.0.0.0 hace que el servidor escuche en todas las interfaces de red, no solo en localhost. Sin esto, solo podrías acceder desde la propia máquina.

2. Proteger el acceso con contraseña:

Si el servidor va a estar accessible por la red, esto es fundamental:

OPENCODE_SERVER_PASSWORD=tu_contraseña opencode web --hostname 0.0.0.0 --port 4096

Por defecto el usuario es opencode, pero puedes cambiarlo con OPENCODE_SERVER_USERNAME. Sin esta protección, cualquiera en tu red podría acceder a tus sesiones y código.

3. Configurar Tailscale (si necesitas acceso remoto):

Tailscale crea una red privada cifrada entre tus dispositivos. Una vez que tu equipo principal y tu iPad o portátil están en la misma Tailnet, puedes acceder al servidor OpenCode como si estuvieras en la misma red local, sin abrir puertos en el router ni configurar nada más.

Lo que no es OpenCode Web

Es importante tener expectativas claras. OpenCode Web no es un reemplazo del TUI para desarrollo intensivo. La interfaz web es más simple, menos pulida y no tiene todas las opciones de navegación por teclado que hace cómodo el terminal. Escribir código largo o hacer tareas complejas en un iPad, por ejemplo, te puede sacar de un apuro, pero no es lo mismo que trabajar con tu setup habitual.

Lo que sí es, y donde realmente aporta, es un punto de acceso ligero. Para revisar el estado de un proyecto, lanzar una tarea al agente, hacer una consulta rápida o continuar un hilo de trabajo que dejaste abierto, funciona perfecto. Y el hecho de poder hacerlo desde cualquier dispositivo con un navegador es una ventaja que el TUI no puede dar por sí solo.

Conclusión

OpenCode Web no es una funcionalidad que necesites si solo trabajas desde tu escritorio y te sientes bien trabajando en la terminal. Pero en el momento en que necesitas flexibilidad, rabajar desde otro dispositivo, acceder a proyectos remotos, o simplemente tener una vista global de todo lo que tienes abierto, se convierte en una pieza clave del setup. También, si quieres tener otra interfaz diferente a un terminal, y poder acceder a varios proyectos a la vez.

Llevo tiempo probando combinaciones de herramientas, modelos y flujos de trabajo. Este artículo es la fotografía de mi setup actual, con la certeza de que dentro de unos meses será diferente, pero también con la convicción de que la estrategia que hay detrás va a mantenerse.

La estrategia: por qué no tengo una sola herramienta

En iCarto tomamos una decisión a la hora de tratar de facilitar la adopción de herramientas de IA: en lugar de comprar una solución de IA corporativa unificada, establecimos un presupuesto individual para que cada persona del equipo explore y decida qué herramientas le funcionan mejor.

Esta decisión tiene una razón de ser. El mercado de la IA se mueve a una velocidad en la que cualquier solución que compres hoy como estándar empresarial puede quedar obsoleta en cuestión de meses. Los modelos, las herramientas y las plataformas evolucionan tan rápido que comprometerse con una única solución ahora mismo es, en mi opinión, un error estratégico. Prefiero que la gente aprenda, experimente y luego compartamos internamente qué funciona y qué no. Este artículo es mi contribución a ese aprendizaje colectivo.

Mi enfoque personal se basa en tres pilares:

1. Una herramienta generalista para el día a día: Gemini, por su versatilidad y ecosistema.
2. Una herramienta especializada para desarrollo: OpenCode, como entorno agéntico donde invierto el tiempo de configuración.
3. Modelos locales para lo que no necesita salir de mi máquina: Gemma 4 y LM Studio, para tareas donde la privacidad importa.

Gemini: el todoterreno de Google

Mi cuenta de Google IA Pro (Gemini) es mi herramienta generalista. No es mi favorita para ninguna tarea concreta, pero es la que mejor cubre el espectro completo cuando no sé por dónde empezar.

Qué hago con Gemini

• Documentación e informes: la generación de texto de Gemini es sólida, pero donde realmente brilla es en la capacidad de procesar documentos largos. Gemini 3.1 maneja contextos enormes sin perder coherencia, algo que a otros modelos les cuesta más.
• NotebookLM: es, para mí, una de las herramientas más infravaloradas de Google. La posibilidad de subir fuentes propias (documentos, PDFs, webs) y construir un asistente que solo responda sobre ese material es increíblemente potente para trabajo de investigación y análisis. La uso mucho combinada con otras herramientas, es casi como poder generar un RAG de forma muy simple.
• Imágenes y exploración: cuando necesito crear imágenes o simplemente explorar una idea sin comprometerme con una herramienta concreta, Gemini es mi punto de partida.
• Contextos muy grandes: en proyectos donde necesito procesar documentación extensa sin perder el hilo, Gemini 3.1 es imbatible. Su ventana de contexto es, hoy por hoy, de las mejores del mercado para uso práctico.

Lo que no me gusta

Google tiene un problema histórico: crea herramientas excelentes de forma individual pero no las integra bien entre sí. El ecosistema Gemini tiene de todo, pero descubrir qué existe y cómo encaja es una tarea en sí misma. No es un problema de calidad, es un problema de cohesión.

En desarrollo, empecé usando Gemini CLI y algo de Antigravity. Con los cambios recientes en Antigravity, si lo uso suelo tirar de su versión sin IDE. Pero no es mi herramienta principal para programar. Para revisión de código sigo usando Visual Studio Code, que he ido ajustando y configurando a lo largo de los años hasta tener un entorno que se adapta a mi forma de trabajar.

OpenCode: el centro de mi desarrollo con IA

Si Gemini es mi navaja suiza, opencode es mi herramienta principal ahora mismo. Es donde más tiempo invierto y donde más rendimiento saco.

La decisión de centrarme en una herramienta de desarrollo con IA no fue trivial. Hay decenas de opciones: Cursor, Windsurf, Claude Code, Antigravity, GitHub Copilot —cada una con sus ventajas. Pero mi filosofía es clara: prefiero conocer una herramienta en profundidad que tener nociones superficiales de varias. OpenCode es la herramienta en la que he decidido invertir, y eso incluye aprender a configurar skills, MCPs, providers y todo el ecosistema que la rodea.

Cómo gestiono los modelos en OpenCode

Tener acceso a una variedad de modelos y poder elegir según la tarea es, para mí, la clave del setup. En OpenCode gestiono esto con dos cuentas complementarias:

OpenCode Go es mi suscripción base. Por $10/mes tengo acceso plano a modelos open-source como DeepSeek V4, Qwen 3.6 Plus, Kimi K2.6 y GLM-5.1, sin preocuparme por el consumo de tokens. Este es mi canal para el día a día: generación de código, revisión, debugging, scripting. Para el 80% de mis tareas, estos modelos son suficientes y no necesito más.

OpenCode Zen funciona con presupuesto prepago. Cargo una cantidad y voy consumiendo según uso. Lo reservo para modelos grandes o muy potentes en casos puntuales donde necesito algo que los modelos open-source no alcanzan. Me permite acceder a Claude Opus o GPT-5 cuando la tarea lo requiere, sin llevarme sorpresas en la factura porque controlo cuánto cargo y cuándo.

La combinación de ambos es lo que hace sostenible el setup: el uso diario va mayoritariamente por Go, y Zen actúa como válvula de escape para cuando necesito potencia extra sin comprometer el presupuesto mensual.

Skills y MCPs

Donde más tiempo he invertido en OpenCode es en la configuración del entorno: skills para automatizar tareas recurrentes y MCPs (Model Context Protocol) para conectar con herramientas externas. Esto es lo que marca la diferencia entre tener un chat con IA y tener un entorno de desarrollo agéntico que realmente entiende tu flujo de trabajo.

La curva de aprendizaje existe, pero una vez que lo tienes configurado, el retorno es inmediato. Puedo lanzar tareas complejas con un comando y el agente sabe qué herramientas usar, qué contexto considerar y cómo estructurar la respuesta.

Modelos en local: Gemma 4 y LM Studio

Aunque el cloud cubre la mayoría de mis necesidades, tener la opción de ejecutar modelos en local es importante. No siempre quieres que tu código salga de tu máquina, y a veces necesitas respuestas rápidas sin depender de la latencia de una API.

Mi equipo es un Mac M1 Pro, que no es ninguna bestia para IA pero mueve modelos pequeños de forma aceptable. He probado varias opciones y mi configuración actual es:

• Gemma 4 como modelo principal para local. Lo muevo a unos 50 tokens por segundo, que es suficiente para tareas de análisis y edición de código que no requieren respuestas largas.
• LM Studio para servir el modelo. Levanta una API compatible con OpenAI en local, y OpenCode se conecta a ella sin configuración adicional.

El matiz importante: usar un modelo local como chat es relativamente sencillo si tu equipo lo aguanta. Pero conseguir que funcione bien como entorno agéntico —donde el modelo tiene que hacer llamadas a herramientas, interpretar resultados y mantener el contexto— es mucho más exigente. He tenido que tunear el system prompt varias veces hasta encontrar un equilibrio que funcione. Los modelos locales no están al mismo nivel que las soluciones comerciales, que unen a estos un entorno de trabajo ya pulido, y es justo reconocerlo.

Aun así, tener esta opción disponible me da flexibilidad. Para tareas sencillas o cuando necesito privacidad, es una alternativa que funciona.

Lecciones aprendidas

Después de meses probando combinaciones, estas son mis conclusiones principales:

Los modelos open-source cubren la mayoría del trabajo diario. Con una buena ventana de contexto y habilidades bien configuradas, modelos como DeepSeek V4 o Qwen 3.6 rinden a un nivel que hace un año habría sido impensable para código abierto. La inversión en configuración —skills, prompts, MCPs— es lo que realmente marca la diferencia.

Los modelos frontier siguen siendo necesarios, pero como recurso puntual. Gemini Pro, Claude Opus o GPT-5 tienen capacidades que los open-source aún no igualan en tareas muy específicas. Tener acceso a ellos sin comprometer el presupuesto mensual es cuestión de diseñar bien el sistema de decisión: qué tareas van a modelos baratos y cuáles justifican el coste de un modelo caro.

La variedad de modelos es más importante que la calidad de uno solo. No uso el mismo modelo para revisar un documento, generar código, analizar una base de datos o mantener una conversación exploratoria. Cada tarea tiene un perfil de coste, latencia y capacidad diferente, y el setup gana cuando puedes elegir en cada momento.

Invertir en una herramienta, no en muchas. Conocer OpenCode en profundidad me ha dado más rendimiento que probar diez herramientas diferentes sin llegar a dominar ninguna. La configuración de skills, MCPs y flujos de trabajo es tiempo invertido que se amortiza con cada uso. Eso no significa que siga explorando y probando muchas otras, pero por el momento todo lo que es trabajo profesional va a OpenCode.

Cierre

No considero este setup definitivo. El mercado de la IA se mueve demasiado rápido como para aferrarse a una combinación concreta. Pero la estrategia sí creo que se mantendrá: variedad de modelos, una herramienta principal bien configurada, acceso a modelos frontier cuando sea necesario y modelos locales para lo que no debe salir de la máquina.

Siento que estamos rascando la superficie de lo que la IA puede hacer en el día a día del desarrollo de software. Experimentar, probar y compartir lo que funciona es, ahora mismo, la mejor inversión que podemos hacer. Aún así, para el trabajo profesional es bueno mantener cierta estabilidad y apostar por una herramienta de base. En el momento en que decida cambiarla será porque estoy convencido de haber encontrado una alternativa mejor, al menos para mi uso.

Creo también que es muy importante experimentar a tu propio ritmo, si te dejas llevar por todo lo que aparece en redes sociales, necesitarias dedicar varias horas al día a probar todo. Más que nunca es necesario sentar las bases de todas las novedades que supone la IA, pero sin querer abarcar todo, porque es imposible. Prefiero invertir en entender los conceptos e ir construyendo un sistema y dinámicas que me funcionen, que copiar las de otros, por mucho hype que estén despertando.

Pero antes de entrar en materia, hay que aclarar un concepto importante porque es fuente de confusión constante: cuando hablamos de modelos "open source" en IA, casi siempre nos referimos en realidad a modelos de pesos abiertos (open-weight). La diferencia es sutil pero clave:

• Open-weight: el fabricante publica los pesos del modelo (los parámetros entrenados) para que cualquiera pueda descargarlos y usarlos. Pero el código de entrenamiento, los datos y el proceso completo no se comparten. Licencias como Apache 2.0 o MIT permiten uso comercial sin restricciones.
• Open source real (según OSI): además de los pesos, se comparten el código de entrenamiento, los datos (o su composición) y los checkpoints intermedios. Esto es extremadamente raro en modelos grandes.

Cuando una empresa dice que su modelo es "open source", normalmente significa que puedes descargar los pesos y ejecutar el modelo, usarlo comercialmente (con restricciones variables según la licencia), y hacer fine-tuning y adaptación. Pero lo que no incluye casi nunca son los datos de entrenamiento (sabemos la composición general, pero no los ejemplos concretos), el código de entrenamiento completo, los checkpoints intermedios, ni la metodología exacta de limpieza y filtrado de datos.

Esto tiene implicaciones prácticas: no puedes verificar de forma independiente si el modelo fue entrenado con datos sesgados o con contenido con copyright. Tienes que confiar en lo que dice la empresa. Es mejor que un modelo cerrado, desde luego, pero no es el ideal del software libre tradicional.

Así que, con matices, podemos decir que hoy tenemos una gran variedad de modelos "abiertos" que podemos usar, descargar y en muchos casos afinar, pero cuyo proceso de entrenamiento sigue siendo un secreto industrial.

Familias de modelos por empresa

Voy a agrupar los modelos más relevantes por la empresa que está detrás.

Meta — Llama 4

Meta ha sido el gran impulsor del ecosistema open-weight con su familia Llama. En 2026, Llama 4 es su apuesta más ambiciosa, con tres variantes principales:

Arquitectónicamente, Llama 4 adopta Mixture of Experts (MoE), lo que significa que aunque el modelo tenga cientos de miles de millones de parámetros totales, solo activa una fracción por inferencia. Scout y Maverick activan solo 17B parámetros, lo que los hace sorprendentemente eficientes.

La licencia de Llama es propia de Meta: permite uso comercial, pero si tu producto supera los 700 millones de usuarios activos mensuales, necesitas permiso especial. Es una cláusula pensada para que gigantes como Google o Microsoft no puedan usarlo libremente compitiendo con Meta.

Alibaba — Qwen 3.5

La familia Qwen de Alibaba es probablemente la que más rápido ha evolucionado. En febrero de 2026 lanzaron Qwen 3.5, con versiones desde 27B hasta 397B parámetros, todas bajo Apache 2.0.

Qwen 3.5 destaca especialmente en razonamiento y tareas multimodales (texto + imagen). En GPQA Diamond, Qwen 3.5 lidera los modelos open-weight con un 88.4%, superando a modelos cerrados de generaciones anteriores.

Apache 2.0 es una de las licencias más permisivas que existen: puedes usar, modificar, distribuir y vender sin restricciones. Alibaba ha apostado fuerte por esta estrategia para ganar adopción global.

DeepSeek — V4 y V3.2

DeepSeek, el laboratorio chino, ha sido uno de los grandes disruptores. Su modelo DeepSeek V4-Pro alcanza un 80.6% en SWE-bench Verified, a solo 0.2 puntos de Claude Opus 4.6, y lo hace con licencia MIT.

DeepSeek llamó la atención mundial en 2025 por sus afirmaciones de entrenamiento eficiente (con un coste declarado muy inferior al de modelos equivalentes), lo que generó tanto admiración como controversia. Lo cierto es que sus modelos son, hoy por hoy, referencia en codificación y razonamiento matemático.

MIT es incluso más permisiva que Apache 2.0: básicamente puedes hacer lo que quieras con el modelo, siempre que incluyas el aviso de copyright.

Mistral AI — Mistral Large 3

Mistral, la startup francesa, representa a Europa en la élite de los LLMs. Su Mistral Large 3 (675B total / 41B activos) compite en la frontera, con licencia Apache 2.0 para los modelos abiertos. También tienen modelos más pequeños como Mistral 7B (el original que los hizo famosos) y Mixtral 8x22B.

Mistral tiene una estrategia dual: ofrece modelos abiertos potentes bajo Apache 2.0 y una versión comercial (Mistral Large) con capacidades adicionales bajo licencia paga. Es un enfoque pragmático que les ha dado una base de desarrolladores muy leal en Europa.

Google — Gemma 4

Google tiene dos líneas: Gemini (cerrado) y Gemma (abierto). Gemma 4, lanzado en 2026, es posiblemente el movimiento más importante de Google en el espacio open-weight.

Gemma 4 viene en tamaños de 2B, 9B y 31B (versión medium), y lo relevante es que todo Gemma 4 está bajo Apache 2.0. La versión de 31B alcanza un 80% en LiveCodeBench con solo una décima parte de los parámetros activos de los MoE frontera. Es ideal para ejecución local y edge deployment.

Moonshot AI — Kimi K2.5 / K2.6

Moonshot AI es una empresa china que ha destacado por su enfoque en contextos largos. Sus modelos Kimi fueron los primeros en soportar 2M tokens de contexto efectivo. Hoy, Kimi K2.5 y K2.6 son sus modelos estrella, con 1T parámetros totales (32B activos) y licencia open-weight.

Kimi K2.5 destaca especialmente en generación visual-a-código y agentes autónomos. K2.6 (lanzado a principios de 2026) mejora los benchmarks de razonamiento y codificación.

Zhipu AI — GLM-5

Zhipu AI es otro laboratorio chino que ha irrumpido con fuerza. Su GLM-5 (744B total / 40B activos) bajo licencia MIT es uno de los modelos más potentes en tareas de sistemas complejos y agentes de larga duración.

Microsoft — Phi-4

Microsoft ha apostado por modelos pequeños pero muy capaces. Phi-4 (14B) bajo licencia MIT demuestra que no todo es tamaño: supera a modelos de 70B+ en razonamiento matemático con una fracción de los recursos. Es perfecto para dispositivos con recursos limitados.

MiniMax — M2.5 / M2.7

MiniMax, otra empresa china, ha lanzado MiniMax-M2.5 (229B total / 10B activos) y su versión mejorada M2.7, enfocados en flujos de trabajo de ingeniería de software. Son modelos ligeros y rápidos, con buena relación calidad-recurso.

01.AI — Yi

Fundada por Kai-Fu Lee, 01.AI publicó la familia Yi bajo licencias Apache 2.0. Aunque no están en la frontera absoluta en 2026, siguen siendo modelos sólidos, especialmente en tareas en chino e inglés.

Tabla resumen de modelos y licencias

Routers de modelos: cómo acceder a todo esto

Todos estos modelos, al ser open-weight, se pueden descargar y ejecutar en local usando herramientas como Ollama, LM Studio o vLLM. De hecho, esa es una de las grandes ventajas del ecosistema abierto: no dependes de ningún proveedor y tus datos no salen de tu máquina. Sin embargo, ejecutar modelos grandes requiere hardware potente —una GPU con suficiente VRAM— y no todo el mundo tiene una RTX 4090 o un clúster en casa. Modelos como DeepSeek V4-Pro (1.6T parámetros) necesitan múltiples GPUs para funcionar a velocidad aceptable.

Aquí es donde entran los routers de modelos: servicios cloud que te permiten usar estos modelos sin necesidad de infraestructura propia. Unifican el acceso a decenas de modelos bajo una misma API, de modo que no tienes que gestionar 20 cuentas y 20 facturas diferentes.

OpenRouter

OpenRouter es el router más conocido. Funciona como una pasarela unificada: te registras una vez, cargas crédito y accedes a 400+ modelos de 60+ proveedores.

Fortalezas: - Catálogo enorme: desde los modelos frontier (Claude, GPT) hasta los más nicho - Auto-fallback: si un proveedor falla, OpenRouter redirige automáticamente - Sin logging por defecto (tu código no se usa para entrenar) - API compatible con OpenAI (cambias la URL y ya funciona) - Modelos gratuitos disponibles (limitados)

Debilidades: - Añade latencia (es una capa intermedia) - Comisión del 5.5% en compras de crédito - El tier gratuito es muy limitado (50 requests/día sin crédito)

OpenRouter usa precios passthrough: pagas lo mismo que pagarías yendo directamente al proveedor. Su negocio está en la comisión de crédito, no en marcar precio.

Groq

Groq es un caso diferente. No es un router, es un proveedor de inferencia con hardware propio: sus LPUs (Language Processing Units) son chips diseñados específicamente para ejecutar LLMs. El resultado es una velocidad de inferencia que puede alcanzar 500-1000 tokens/segundo, muy por encima de lo que ofrecen las GPUs tradicionales.

Fortalezas: - Velocidad bestial: tiempo hasta el primer token por debajo de 200ms - Tier gratuito generoso: 250K+ tokens/minuto - API compatible con OpenAI - Modelos populares: Llama 4 Scout, Qwen3-32B, DeepSeek

Debilidades: - Catálogo limitado (solo modelos open-source que ellos optimizan para su hardware) - No es un router (solo un proveedor) - Sin posibilidad de auto-hospedar (el hardware LPU es suyo)

Groq es ideal cuando necesitas velocidad y trabajas con modelos open-source populares. No te sirve si necesitas un modelo específico que ellos no tengan.

OpenCode Go

OpenCode Go es la apuesta del equipo de OpenCode. Por $10/mes obtienes acceso a 14+ modelos open-source de última generación a través de una API única.

Fortalezas: - Precio planísimo: $10/mes sin preocuparte por tokens - Modelos frontier open-source: DeepSeek V4 Pro, Qwen 3.6 Plus, Kimi K2.6, GLM-5.1, MiniMax M2.7 - API compatible con OpenAI (funciona con cualquier herramienta que hable OpenAI API) - Política zero-retention: tu código no se usa para entrenar - Infraestructura en US, EU y Singapur

Debilidades: - Límites de consumo por ventanas de tiempo: tu suscripción de $10 te da un pool de $60/mes en compute, con sub-límites de $12/5h y $30/semana para evitar abusos. Con modelos baratos (DeepSeek V4 Flash a $0.14/M tokens) llegas a miles de requests; con modelos caros (Kimi K2.6) el límite se alcanza antes. Nunca pagas más de los $10 al mes. - Solo modelos open-source (no hay Claude, GPT ni Gemini) - Dependes de la disponibilidad del servicio

OpenCode Go es perfecto si tu flujo de trabajo se basa en modelos open-source y quieres un coste predecible sin sorpresas en la factura.

Comparativa rápida

Conclusión

El ecosistema de modelos open source en 2026 es más rico que nunca. Hay modelos para cada necesidad, desde los gigantes multimodales como Qwen 3.5 o Llama 4 hasta pequeños pero matones como Phi-4 o Gemma 4 que funcionan en un portátil.

La principal recomendación que puedo dar es:

1. Para uso general con máxima calidad, Qwen 3.5 y DeepSeek V4 son las mejores opciones open-weight hoy por hoy.
2. Para ejecución local, Gemma 4 (31B) o Phi-4 (14B) son imbatibles en relación calidad/recursos.
3. Para desarrollo de software, Kimi K2.6 destaca en generación de código y agentes autónomos. Como alternativas, DeepSeek V4-Pro es el rey del SWE-bench Verified (80.6%) para tareas complejas, y Qwen 3.7 Max lidera en SWE-Bench Pro dentro del ecosistema OpenCode Go.
4. Para acceder a todo sin complicaciones, OpenRouter es la navaja suiza. Si buscas velocidad, Groq. Si prefieres coste fijo, OpenCode Go.

Y recuerda: aunque llamemos "open source" a estos modelos, lo que realmente tenemos son pesos abiertos con licencias variadas. Úsalos, aprovéchalos, pero sé consciente de lo que estás usando y de las limitaciones reales de cada "open" que ves en la etiqueta.

Durante la Revolución Industrial, la llegada del telar mecánico destruyó por completo el sector de los tejedores artesanales. Quienes habían pasado años aprendiendo la técnica manual de entrelazar hilos vieron cómo su oficio desaparecía ante una máquina que hacía lo mismo de forma masiva, rápida y barata. ¿Significó eso el fin de la industria textil? Al contrario. La manufactura de la tela se convirtió en una utilidad genérica, lo que redujo los costes drásticamente. El valor real de la industria se desplazó hacia arriba: hacia el diseño de moda, el patronaje a escala y la logística.

Pero hacer software no va solamente de tejer hilo, el proceso es mucho más complejo y la llegada de la IA no va transformar radicalmente la industria. Va a cambiar cosas y vamos a necesitar adaptarnos, eso sí.

Lo que cuesta entender, al parecer, es lo que la IA realmente hace: encontrar patrones matemáticos en datos existentes. Si limitamos nuestra profesión a lo que la IA puede replicar, corremos el riesgo de congelar la industria. La informática real sigue siendo un terreno estrictamente humano. Como decía Edsger Dijkstra:

"Computer science is no more about computers than astronomy is about telescopes"

La IA es un telescopio potentísimo, pero no es la astronomía. Confundir la capacidad de escribir código sintáctico con la capacidad de resolver problemas mediante la computación es el mayor error conceptual que estamos cometiendo.

Seguramente has experimentado con el vibe coding: te pones a construir una aplicación con IA, piensas en sacarle rendimiento, ponerla en un market y venderla. En unas pocas horas tienes una aplicación funcional y sientes que ya has hecho el 80% del trabajo. Piensas: «Mañana cierro los últimos flecos y la publico». Pero ese 20% que falta resulta no ser tan sencillo. Ya no es cuestión de horas, sino de días o semanas. O simplemente, nunca llegas a publicarla, porque la IA no es tan buena lidiando con la complejidad del mundo real. Esos últimos flecos son el producto, la usabilidad y la infraestructura: todo aquello que requiere el conocimiento y la experiencia de una persona.

Lo que la IA no sabe hacer: El mundo real más allá del código

Un modelo de lenguaje puede escribir una función limpia si la instrucción es lo suficientemente meticulosa. El problema es que el software no vive en el vacío; convive en un ecosistema complejo de usuarios, servidores, costes y decisiones estratégicas.

Existen tres dimensiones críticas donde la IA carece de la capacidad operativa para decidir:

1. El criterio de digitalización (Saber cuándo NO hacer software)

La IA siempre va a intentar resolver el problema generando texto o código, porque esa es su naturaleza estadística. Carece del criterio para analizar un proceso de negocio y concluir: "La solución óptima aquí no es construir una aplicación, sino cambiar este flujo organizativo en el mundo real". Saber cuándo no introducir tecnología porque sí, para evitar complejidad innecesaria, es una de las mayores muestras de madurez en ingeniería.

2. La experiencia de usuario (UX)

La IA no tiene un modelo mental de la realidad. Puede replicar interfaces basadas en patrones de diseño comunes (como colocar un botón de carrito arriba a la derecha), pero no entiende la fricción humana. No sabe el estrés que siente un operario de almacén usando una aplicación bajo la luz del sol directa, ni la confusión de un usuario ante un menú saturado. La UX requiere empatía y observación, algo que no se encuentra en una matriz de embeddings.

3. Las limitaciones y el diseño de la infraestructura

Escribir código es fácil; hacer que ese código escale de forma eficiente bajo restricciones de hardware reales es ingeniería pura. La IA no sufre cuando una base de datos PostgreSQL se satura por falta de memoria, ni entiende el impacto en costes que implica mover datos entre diferentes regiones de la nube. No contempla escenarios sin una buena conexión a Internet, con cortes de electricidad o sin cobertura móvil. La IA es como los experimentos de laboratorio, siempre asume condiciones ideales. Puede darte la sintaxis de una consulta, pero el diseño de una arquitectura tolerante a fallos que optimice los recursos físicos requiere comprender los trade-offs reales del sistema.

La trampa del estancamiento: La IA copia el pasado, el humano diseña el futuro

Hay una reflexión profunda que quizás estamos ignorando debido al hype: los modelos de lenguaje construyen software tal y como se ha hecho hasta hoy. Como los LLMs se entrenan con repositorios existentes (como el histórico de GitHub), son maestros de la probabilidad estadística respecto a lo que ya existe. Esto significa que la IA es, por definición, una fuerza conservadora y retrospectiva.

El bucle de la imitación: La IA encuentra y replica patrones. Si detecta que el 90% de los proyectos usan una estructura determinada para una API, te devolverá esa estructura. Está optimizada para darte la respuesta más probable, no la más innovadora.

Ante un desafío tecnológico inédito, un problema para el cual no existen tutoriales en internet ni código de entrenamiento, la red neuronal falla o alucina. No puede inventar un paradigma de programación nuevo; solo puede combinar los vectores numéricos de lo que alguien ya escribió antes.

Si las personas que nos dedicamos a la informática delegamos el pensamiento y la evolución de la disciplina en los asistentes de código, congelaremos el desarrollo de la tecnología. Nos estancaremos replicando las mismas arquitecturas y los mismos errores del pasado en un bucle infinito de software autogenerado.

Innovación frente a imitación

La evolución tecnológica nunca ha llegado por hacer de forma más rápida lo que ya sabíamos hacer. Llegó cuando Alan Turing imaginó una máquina que no existía, cuando se diseñaron los primeros sistemas operativos distribuidos para resolver la saturación de los mainframes, o cuando nacieron arquitecturas web descentralizadas para soportar millones de usuarios simultáneos.

Para que la informática siga avanzando, quienes nos dedicamos a la ingeniería debemos cambiar el enfoque de nuestro trabajo diario:

• Menos memorización de sintaxis, más pensamiento sistémico: Dejemos que la IA maneje los tokens mecánicos de la sintaxis y enfoquémonos en comprender los fundamentos lógicos y físicos de los sistemas. El hecho en sí de escribir código es fácil para la IA, conoce las estructuras, los patrones, la sintaxis, pero saber qué usar y cuándo es cosa nuestra.
• Enfrentar la incertidumbre: El verdadero valor de la ingeniería radica en los márgenes de los problemas nuevos, allí donde no hay documentación de StackOverflow ni datos de entrenamiento para el modelo. La innovación seguirá siendo humana, si dejamos a la IA diseñar las soluciones, serán siempre las que ya conocemos.
• Liderar la orquestación: Tratar a la IA como lo que es: un traductor universal de patrones existentes que acelera la imitación, permitiéndonos a nosotros liberar tiempo para la verdadera innovación y el diseño de soluciones estructuralmente nuevas. La IA es una herramienta que nos hace el trabajo más fácil, pero no hace nuestro trabajo.

Conclusión

Al final, la IA que conocemos hoy es solo eso: una herramienta. Una increíblemente potente, sí, pero una herramienta al fin y al cabo. Bien usada, nos facilita la vida, pero ni nos sustituye ni va a hacerlo en el corto plazo.

No es magia. No convierte a un principiante en un experto, ni a alguien sin criterio estético en un buen diseñador. La IA es un espejo que amplifica lo que ya somos.

El futuro no lo construirán quienes solo sepan hablar con la máquina, sino aquellos que, partiendo del criterio y la visión, dominen la IA como una palanca para ejecutar esa visión. Y entre dos profesionales con la misma visión, quien domine la herramienta para trabajar más rápido y mejor, será quien marque la diferencia.