Kimi K3 vs Fable 5 vs GPT-5.6 Sol: el open source chino ya revienta a Claude y GPT
En el primer experimento medí el coste de la misma landing con un prompt quirúrgico: cada gradiente, cada medida, cada URL. Aquellos números medían si el modelo sabía seguir instrucciones. Este mide algo más parecido a un encargo de cliente real: le pasé a tres modelos una imagen de referencia y un brief de doce líneas, y les dejé elegir marca, textos, productos y hasta el framework.
Los tres contendientes: Claude Fable 5 y GPT-5.6 Sol, los de siempre, y un recién llegado, Kimi K3 de Moonshot, que salió hace un par de días. El resumen: los tres entendieron el encargo sorprendentemente bien, la calidad de código está muy pareja, y lo que más pesa vuelve a ser el coste, con una diferencia que las tablas de precios no cuentan.
Cómo generé la misma landing con tres IAs distintas
Adjunté una imagen de una pastelería que me gustó de Pinterest y un brief corto: landing de una dulcería española de tartas y galletas creativas, siete secciones, animaciones, responsive, SEO, y que arranque a la primera. La marca, los copys, los productos, la paleta y el framework los decidía el modelo.
Dejar el stack libre es deliberado. En el experimento 1 imponer React o Framer Motion tenía sentido porque medía obediencia. Aquí habría matado la señal que busco: cómo elige y maneja cada modelo sus herramientas. Así que la elección de stack no se dicta, se puntúa.
Los tres corrieron con su agente nativo y esfuerzo máximo. El detalle interesante para quien quiera replicarlo: Kimi K3 se ejecuta desde el propio Claude Code, porque Moonshot expone un endpoint compatible con la API de Anthropic. Eso convierte Fable contra Kimi en una comparación de modelo puro (mismo agente, mismas herramientas), mientras que GPT-5.6 Sol, que va por Codex, mezcla modelo y agente.
Todo el experimento es público: brief, protocolo, script de medición y el código exacto de cada modelo en github.com/ivanlhz/ia-tests. Y las tres landings están desplegadas tal cual las entregó cada modelo, sin retocar una línea, para que las juzgues tú mismo:
- Fable 5 (Migaja) → bakery-fable5.vercel.app
- Kimi K3 (Miga) → bakery-kimi.vercel.app
- GPT-5.6 Sol (Miga Mía) → bakery-sol.vercel.app
Las tres IAs eligieron el mismo stack: Astro y GSAP
Antes de puntuar nada, un patrón que no esperaba tan marcado. Sin ponerse de acuerdo:
- Los tres bautizaron la marca con la palabra “miga”. Migaja (Fable), Miga · Obrador Creativo (Kimi) y Miga Mía (Sol). La palabra perfecta en español para una pastelería, y los tres la encontraron solos.
- Los tres eligieron Astro con GSAP, sin React. Teniendo libertad total, ninguno se fue a Next ni a un SPA. Todos al generador estático, que para una landing sin componentes interactivos pesados es la decisión correcta. Y GSAP en vez de Framer Motion, coherente al no montar React.
- Los tres clavaron el SEO técnico. Título único, meta description, Open Graph, JSON-LD, un solo
<h1>,lang="es",alten todas las imágenes,prefers-reduced-motion. Ninguno se dejó los fundamentos.
Dentro de esa coincidencia hay un detalle que delata cómo trabaja cada agente. Fable y Kimi montaron el proyecto con exactamente la misma versión de Astro, la 5.13: la que llevan grabada en su entrenamiento. Sol fue el único que usó la última versión, Astro 7, y además con las dependencias fijadas a versión exacta, sin rangos. Es un punto real a su favor: su agente comprobó qué existe hoy en vez de tirar de memoria, que es justo lo que harías tú antes de arrancar un proyecto.
Comparativa de las tres landings generadas por IA
Los catálogos lado a lado dejan ver la primera diferencia:
Fable monta el catálogo más comercial: nueve productos, badges (“La más pedida”, “Superventas”, “Nueva”, “Para regalar”) y categorías. Kimi va más editorial, seis productos con fichas cuidadas y hasta una opción vegana, con textos que tienen voz (“para los que piden poco dulce”, “la rara de la casa”). Sol se queda corto, con cuatro productos y una jerarquía comercial más pobre.
El copy es de lo mejor de los tres. “Tartas con mucha miga”, “dinosaurios trepando el glaseado”, “Elige tu flechazo”. Español nativo, con gracia, que vende. Ninguno cayó en el lorem ni en el español de traductor automático.
Donde se separan de verdad es en la ejecución, y ahí el ganador cambia:
| Fable 5 (Migaja) | Kimi K3 (Miga) | GPT-5.6 Sol (Miga Mía) | |
|---|---|---|---|
| Parecido a la referencia | El mejor | Medio | El peor |
| Animaciones | Parpadean (blinkeos) | Fluidas | Hero roto |
| Responsive móvil | Roto, secciones cortadas | Perfecto | Menú transparente |
| Código y SEO | Completo | Completo | Completo |
Fable es el que más se parece a la imagen de referencia, el único que reprodujo la ola de glaseado goteante y la paleta frambuesa, y el único que intentó el efecto de crema cayendo sobre el fondo (aunque no llegó a rematarlo). Ese es su punto fuerte. El problema es el acabado: las animaciones parpadean al cargar y el responsive se rompe, con secciones que aparecen cortadas en móvil.
Kimi no copia la referencia, va por su cuenta, pero entrega la web mejor terminada: animaciones fluidas y un responsive que funciona sin fallos. Es la que yo pondría en producción con menos retoques.
Diseño responsive: dónde falla cada IA en móvil
El móvil es lo que decide el experimento, y lo comprobé abriendo el menú hamburguesa de cada uno a 390 px de ancho.
El menú de Sol es el fallo más claro: al desplegarse, su fondo es transparente, así que la página que queda por detrás se ve a través del menú y los textos se solapan hasta quedar ilegibles. En un móvil real, la navegación es inusable. Sol acumula además otros problemas de acabado: un logo que es solo texto, una sección con fondo verde oliva que se sale de la paleta rosa de la referencia, una galleta navideña fuera de temporada en el catálogo, y un footer con líneas vacías.
Fable resuelve bien el menú, con un overlay rosa sólido y CTA de WhatsApp, pero se queda ahí: en otras secciones el responsive se corta, y el hero parpadea al entrar. Kimi es el único que pasa el móvil sin peros.
Cuánto cuesta generar una landing con cada IA
Aquí está el dato que no se ve en ninguna tabla de precios. Kimi K3 es el único de los tres que factura por token de verdad; Fable y Sol van por suscripción. Y su factura fue esta:
| Fable 5 | GPT-5.6 Sol | Kimi K3 | |
|---|---|---|---|
| Facturación | Suscripción (Max) | Suscripción (Plus) | API de pago |
| Coste | $35,09 | $9,59 | ~4,16 € reales |
| ¿Dinero real? | No, API equivalente | No, API equivalente | Sí |
Esta fila no se lee de izquierda a derecha, porque no son la misma unidad. Para Fable y Sol, ese dólar es “coste API equivalente”: una vara común para comparar, pero no dinero que salga de mi cuenta, porque pago una cuota mensual. Solo Kimi da una cifra de euros indiscutible. Y esa cifra, para una web con el código al nivel de la de Fable, fueron poco más de 4 € en dinero real.
Por qué el coste real de Kimi no es el que dicen los logs
Este es el hallazgo más útil del experimento para cualquiera que quiera medir lo que le cuesta un modelo de terceros. Mi script leyó los logs de la sesión de Kimi y calculó 1,75 $ por tokens. La factura real de Moonshot fue de ~4,16 €. El script se quedó corto 2,4 veces.
El motivo: Moonshot no reporta las escrituras de caché en el endpoint compatible. Los logs las marcan a cero, pero las factura igual. La lección es directa: para cualquier endpoint compatible de terceros, fíate de la factura del proveedor, no del coste que calcules desde los logs. El precio por token que ves y el que pagas no coinciden.
Límites del experimento
- Es n=1. Una tarea, una pasada por modelo, un día concreto. Medición honesta, no ley universal.
- Las unidades de coste no son comparables. Solo Kimi es dinero real; Fable y Sol son coste API equivalente. Para su euro real haría falta el delta de cuota semanal, que aún no cerré.
- El esfuerzo de Kimi no es verificable. Al ir por un endpoint de terceros, no se puede confirmar que aplicara el razonamiento máximo. Su “MAX” lleva asterisco.
- El harness de Kimi no es idéntico al de Fable pese a compartir agente. No es una comparación de laboratorio perfecta.
- Los modelos cambian. Kimi K3 salió hace días; los números tienen fecha de caducidad. El método, no.
Qué IA elegir para generar una landing
- La barrera ya no es entender el encargo, es el acabado. Tres modelos frontier interpretaron un brief ambiguo con las mismas decisiones sensatas (Astro, GSAP, SEO completo, marca “miga”). Se separan en el pulido: las animaciones, el responsive, la fidelidad al diseño.
- Un modelo abierto y de pago por token entrega calidad de frontera por muy poco dinero real. Kimi K3 sacó la web mejor terminada por ~4 €.
- Mide siempre contra la factura, no contra los logs. En endpoints de terceros el coste calculado puede quedarse a menos de la mitad.
Esta es la misma disciplina que aplico en proyectos de cliente: el coste de un sistema de IA no se estima con la tabla de precios del proveedor, se mide con telemetría propia sobre tareas reales. Si estás decidiendo qué modelo usar y quieres números en vez de opiniones, hablamos 30 minutos.