Este documento presenta un experimento comparativo entre cinco modelos de IA aplicados a tareas reales de desarrollo web: Big Pickle, GLM 5.1, MiniMax M2.5, Qwen3.6 Plus y Sonnet 4.6. La comparación se realizó dentro de un mismo proyecto JAM Stack con Waku, React, Tailwind y TypeScript, buscando evaluar no solo la calidad del código generado, sino también su utilidad práctica al integrarse en una base de código existente.
En lugar de medir a los modelos con prompts aislados, se definieron tres tareas complementarias que representan necesidades comunes en proyectos modernos:
(1) Implementar un modal accesible (WCAG 2.2 nivel AA) con foco, ARIA y tests.
(2) Implementar un hook de persistencia en localStorage seguro para SSR/RSC.
(3) Implementar un endpoint Waku para envío de correos con Resend, protección antiabuso e integración frontend/backend.
Además de revisar cumplimiento técnico, se analizaron aspectos de mantenibilidad, UX, DX, robustez de testing, calidad de integración JAM Stack y comportamiento general bajo restricciones reales de proyecto (estructura de carpetas, convenciones de nombres y ejecución de pruebas). En paralelo, se registraron métricas de costo, consumo de tokens, uso de ventana de contexto y una estimación de huella de carbono para obtener una visión más completa.
El objetivo principal de este experimento no es declarar un ganador absoluto, sino identificar fortalezas y debilidades por tipo de tarea. De esta manera, las conclusiones permiten seleccionar el modelo más conveniente según el contexto: calidad técnica, velocidad de iteración, estabilidad de pruebas, integración backend o relación valor/costo.
Finalmente, es importante destacar que los resultados representan una fotografía de esta prueba puntual (mismo entorno, mismos prompts y misma sesión), por lo que pueden variar ante cambios en versiones de modelos, herramientas o criterios de evaluación. Aún así, el análisis sirve como referencia práctica para tomar decisiones informadas al trabajar con modelos de IA en desarrollo de software.
Tarea: Modal accesible WCAG 2.2 nivel AA
(al final del prompt se agregó el nombre del modelo)
Prompt:
Contexto:
Estoy creando un modal accesible que cumpla con las pautas WCAG 2.2 nivel AA para una aplicación web. El modal debe ser fácil de usar para todas las personas.
Requisitos:
→ Ignore cualquier otro archivo, componente o función. Solo cree el modal accesible.
→ Debe cumplir en su totalidad con las pautas WCAG 2.2 nivel AA
→ Es importante que atrape el foco al abrirse y retorne el foco al elemento que lo abrió al cerrarse
→ Debe ser semánticamente correcto, utilizando roles y atributos ARIA apropiados
→ Debe ser responsivo y funcionar bien en dispositivos móviles
→ Debe ser estilado con Tailwind CSS
Tarea:
(1) Implemente un modal accesible que cumpla con las pautas WCAG 2.2 nivel AA
(2) Explique cómo se asegura de que el modal cumpla con las pautas de accesibilidad
(3) Muestre cómo integrarlo en un proyecto real
(4) Proporcione ejemplos de uso y personalización del modal
(5) Genere test unitarios para el componente
Formato esperado:
→ Código claro y bien estructurado
→ Explicaciones breves por sección
→ El nombre del archivo debe ser 'modal' + '{nombre del modelo} + '.ts' (ejemplo: modalGLMCincoPuntoUno.ts o modalBigPickle.ts)
→ Deberá guardarse en comparacionDeModelos\src\components\modal
El nombre de su modelos es:
Modelos evaluados
→ Big Pickle
→ GLM 5.1
→ MiniMax M2.5
→ Qwen3.6 Plus
→ Sonnet 4.6
Uso de tokens
→ GLM 5.1: 71 170
→ Qwen3.6 Plus: 42 457
→ Sonnet 4.6: 39 534
→ MiniMax M2.5: 36 253
→ Big Pickle: 22 374
Cantidad de líneas (entre todos los archivos generados)
La mejor implementación actual es Big Pickle. Es la única que no oculta el dialog completo con aria-hidden, sí mueve el foco al abrir, lo mantiene dentro con Tab, lo retorna al cerrar, usa role="dialog", aria-modal, aria-labelledby, Tailwind y layout responsivo.
Pero ninguna cumple al 100% con el prompt. La más cercana es Big Pickle para el componente accesible, mientras que GLM 5.1 es la más completa en ejemplos/integración/tests, pero tiene un bug de accesibilidad fatal.
Hallazgos Clave
(1) Sonnet 4.6 y GLM 5.1 ocultan el modal a lectores de pantalla. En ambos casos, el contenedor padre tiene aria-hidden="true" y dentro está el role="dialog". Un hijo no puede “desocultarse” con aria-hidden="false" si un ancestro está oculto.
(2) MiniMax falla el requisito central de focus trap. Solo enfoca el botón de cierre y maneja Escape; no implementa navegación cíclica con Tab/Shift+Tab. Además también pone aria-hidden="true" en el padre del diálogo.
(3) Qwen tiene focus trap incompleto. Implementa lógica para ciclar entre primer/último elemento, pero no mueve el foco al modal al abrirse. También usa IDs fijos (modal-title, modal-description), lo que puede romper relaciones ARIA si hay más de un modal renderizado.
(4) Big Pickle es el más correcto en accesibilidad, pero no es entrega completa. Su componente está mejor resuelto: foco inicial, trap, retorno de foco, ARIA correcto y sin aria-hidden en el ancestro del diálogo. Sus debilidades son: usa Math.random() para IDs en vez de useId, restaura body.style.overflow a vacío en vez del valor original, no trae archivo de ejemplos/integración separado y sus tests son débiles/no ejecutables en el proyecto actual.
UX
→ Big Pickle: El modal es funcional, atrapa el foco al abrirse y retorna el foco al cerrarse. El color del texto del contenido del modal no tiene suficiente contraste con el fondo.
→ GLM 5.1: El modal es funcional, atrapa el foco al abrirse y retorna el foco al cerrarse. El color del texto del contenido del modal no tiene suficiente contraste con el fondo. Es muy parecido al de Big Pickle.
→ MiniMax M2.5: El modal es funcional, pero no atrapa el foco al abrirse. La UI tiene un contraste correcto. Posee dos botenes que permiten cerrar el modal.
→ Qwen3.6 Plus: El modal es funcional, atrapa el foco al abrirse y retorna el foco al cerrarse. Es también muy parecido al de Big Pickle. Es el único modelo que agregó una animación al modal.
→ Sonnet 4.6: El modal es funcional, atrapa el foco al abrirse y retorna el foco al cerrarse. La UI tiene un contraste correcto. Es muy parecido al de MiniMax M2.5. (5) Posee solo un botón para cerrar el modal.
Tests
→ 5 archivos de tests fallaron con la primera ejecución: 148 tests: 86 pasaron y 62 fallaron.
→ MiniMax M2.5, Sonnet 4.6 y GLM 5.1 usan aria-hidden="true" que oculta el modal. Esto hace que los tests de accesibilidad fallen porque el modal no es accesible para lectores de pantalla.
→ Big Pickle y Qwen 3.6 Plus tiene su test de foco mal planteado, retorna el foco al body, pero el test espera que retorne al botón de apertura. Esto hace que los tests de foco fallen.
Mantenibilidad
Por estructura, API más clara y completa, ejemplos, tests y calidad de código (sin olvidar el problema de aria-hidden), la implementación de GLM 5.1 es la más mantenible.
MiniMax M2.5 es la menos mantenible por su falta de foco trap, lo que es un requisito central.
Por simplicidad y accesibilidad real, Big Pickle es la mejor opción, pero su falta de ejemplos y tests lo hace menos mantenible que GLM 5.1.
Notas
→ Big Pickle presentó 3 advertencias Object is possibly 'undefined'. Fácil de corregir. Código sencillo, usa Math.random() para generar IDs en vez de useId, lo que puede causar problemas de accesibilidad si se renderizan múltiples modales. Restaura body.style.overflow a vacío en vez del valor original, lo que puede causar problemas si hay otros modales o elementos que también modifican el overflow del body. La implementación más accesible de la comparación. Terminó los archivos, pero no indicó cuando terminó, se "quedó pensando".
→ GLM 5.1 presentó 4 advertencias Object is possibly 'null'. Fácil de corregir. Creó dos tipos de modales: normal y de confirmación. También creó un hook para manejar el estado del modal, evitando la necesidad de manejar el estado en el componente padre.
→ Sonnet 4.6 presentó 4 advertencias Object is possibly 'null'. Fácil de corregir. Cuenta con un hook para manejar el foco, buen uso de useID para generar IDs únicos. También creo un componente de confirmación, lo que da flexibilidad para casos de uso comunes sin necesidad de modificar el componente base del modal. Fue el único que cambió la extensión a .tsx, el resto de los modelos mantuvieron la extensión .ts. Este detalle fue un error en el prompt, por lo que no resta ni suma puntos a ningún modelo, pero es importante destacarlo.
→ MiniMax M2.5 no presentó advertencias. Posee una prop opcional de footer para personalizar el pie del modal, permitiendo agregar funcionalidad extra al modal sin modificar su estructura interna, ya sea para agregar botones, información adicional o cualquier otro contenido que se desee mostrar en el pie del modal. Esto hace que el componente sea más flexible y reutilizable, ya que se puede adaptar a diferentes necesidades sin modificar su código base. También posee un hook para manejar el estado del modal, evitando la necesidad de manejar el estado en el componente padre. Terminó los archivos, pero no indicó cuando terminó, se "quedó pensando".
→ Qwen 3.6 Plus no presentó advertencias. Posee una prop que permite el posicionamiento del modal, lo que permite mostrar el modal en diferentes partes de la pantalla según las necesidades. Posee un hook (que no se exporta) para manejar el estado del modal, y otro para manejar el foco, lo que facilita la implementación de la lógica de atrapamiento de foco y retorno de foco. Fue el segundo más rápido, solo detrás de Sonnet 4.6. Fue el único que agregó 'use client' al inicio de su código.
Tarea: Hook de persistencia en localStorage
(al final del prompt se agregó el nombre del modelo)
Prompt:
Contexto:
Estoy desarrollando una aplicación JAM Stack con Waku + React + TypeScript. Necesito un hook reutilizable para guardar preferencias del usuario en localStorage, por ejemplo tema, idioma o filtros de una página.
Requisitos:
→ Ignore cualquier otro archivo, componente o función. Solo cree el hook solicitado.
→ React + TypeScript
→ Debe funcionar en Waku
→ Debe ser seguro para SSR/RSC, sin acceder a window durante render server-side
→ Debe manejar errores de localStorage
→ Debe permitir valores tipados
→ Debe evitar errores si el almacenamiento está bloqueado o lleno
→ Debe ser fácil de probar
Tarea:
(1) Implemente un hook useLocalStorageState
(2) Permita definir key, initialValue, serialize y deserialize
(3) Lea desde localStorage solo en cliente
(4) Sincronice cambios entre pestañas usando el evento storage
(5) Incluya una función para resetear el valor
(6) Exponga estado de disponibilidad del storage: isPersistent
(7) Explique cómo usarlo para tema, idioma o filtros
(8) Indique limitaciones del enfoque
(9) Genere tests unitarios para SSR safety, lectura/escritura, reset, errores de parseo y sincronización entre pestañas
Formato esperado:
→ Código claro, documentado y bien estructurado
→ Explicaciones breves por sección
→ El archivo debe llamarse useLocalStorageState + {nombre del modelo} + .ts
Ejemplo: useLocalStorageStateGLMCincoPuntoUno.ts
Notas:
→ Agregue 'use client' si corresponde.
→ No acceda a window ni localStorage durante render server-side.
→ No use dependencias externas.
→ Priorice seguridad en SSR, tipado y DX.
El nombre de su modelo es:
Modelos evaluados
→ Big Pickle
→ GLM 5.1
→ MiniMax M2.5
→ Qwen3.6 Plus
→ Sonnet 4.6
Uso de tokens
→ Sonnet 4.6: 11 900
→ GLM 5.1: 10 268
→ Qwen3.6 Plus: 6 914
→ MiniMax M2.5: 5 689
→ Big Pickle: 4 218
Cantidad de líneas (entre todos los archivos generados)
→ GLM 5.1: hook: 327 + test: 680. Total: 1 007
→ Sonnet 4.6: hook: 339 + test: 487. Total: 826
→ MiniMax M2.5: hook: 291 + test: 463. Total: 754
→ Qwen3.6 Plus: hook: 293 + test: 423. Total: 716
→ Big Pickle: hook: 125 + test: 285. Total: 410
Análisis Rápido por GPT 5.3-Codex (Xhigh)
La mejor implementación actual es Sonnet 4.6. Es la más sólida en SSR/hidratación, manejo de errores, sincronización entre pestañas y API del hook.
La segunda mejor es GLM 5.1: muy completa y mantenible, aunque con algunos problemas en su suite de tests.
Ninguna cumple al 100% el prompt porque, aunque casi todas muestran ejemplos de uso, no hay una sección clara y explícita de limitaciones del enfoque.
Hallazgos Clave
(1) Sonnet 4.6 es el hook técnicamente más correcto hoy. Arranca con estado SSR-safe, sincroniza storage entre pestañas, y tiene reset explícito.
Detalle a vigilar: el reset fuerza una heurística de persistencia.
(2) GLM 5.1 es muy buena implementación, pero su test suite tiene casos discutibles.La implementación de lectura/escritura segura está bien en sus archivos.
Pero en tests hay escenarios de deserialización con Date que no necesariamente lanzan error.
(3) Big Pickle cumple base funcional, pero con riesgo de hidratación y tests frágiles. Lee localStorage dentro del inicializador de estado, lo que puede provocar diferencias SSR/cliente; además define persistencia inicial.
Sus tests mockean window sin dispatchEvent, pero luego lo usan.
(4) MiniMax M2.5 es la implementación más problemática. Crea un external store por render, lo usa con useSyncExternalStore, y además lo mete en dependencias de efecto, abriendo la puerta a re-ejecuciones innecesarias.
También usa valor cerrado en setValue e ignora eliminación remota de clave.
(1) Qwen 3.6 Plus es correcto en lo básico, pero con decisiones riesgosas. También inicializa estado leyendo storage durante render cliente, con key fija en ref.
Su suite depende de estilo Jest en varios puntos, lo cual es válido solo si el setup global carga correctamente.
Mantenibilidad
Sonnet 4.6 creo la solución más mantenible, gracias al diseño consistente de API, tipado y utilidades.
GLM 5.1 tiene buena estructura, pero hay que corregir su suite de tests para que sea realmente confiable.
Test
→ Los tests de Sonnet 4.6 pasaron en su totalidad desde el inicio.
→ La suite de tests para el hook de GLM 5.1 tenía pruebas que "congelaban" la suite.
→ Las 24 pruebas del test de Qwen 3.6 Plus, fallaron.
Notas
→ MiniMax M2.5 fue el primero en terminar, seguido de Qwen 3.6 Plus.
→ La implementación de MiniMax M2.5 generó problemas en el build, y fue imposible de usar en desarrollo debido a un loop infinito.
→ MiniMax M2.5 generó un endpoint Waku en una carpeta distinta a la indicada en el prompt.
→ Big Pickle generó el hook en una carpeta aparte, que llamó ooks.
→ Big Pickle y Qwen 3.6 Plus crean un par Clave-Valor en localStorage apenas carga la página, incluso antes de que se ejecute el hook.
Tarea: Creación de endpoint Waku + API
(al final del prompt se agregó el nombre del modelo)
Prompt:
Contexto:
Estoy desarrollando una API para un servicio de enviar correos desde el navegador, tipo formulario de contacto. Quiero crear un endpoint que use la API, reciba los datos del formulario y envíe el correo utilizando Resend. El proyecto está hecho con Waku.
Requisitos:
→ Ignore cualquier otro archivo, componente o función. Solo cree el endpoint y API.
→ Node.js + TypeScript
→ Debe funcionar en entorno serverless
→ Límite: 66 requests por minuto por usuario
→ Debe ser eficiente, seguro y escalable
→ Debe permitir enviar correos sin autenticación, pero con protección contra abusos
Tarea:
(1) Implemente la API para recibir los datos del formulario y enviar el correo utilizando Resend
(2) Implemente el endpoint Waku para enviar correos con Resend
(3) Explique cómo maneja la seguridad y la protección contra abusos
(4) Muestre cómo integrarlo en un proyecto real, tanto en el backend como en el frontend
(5) Indique limitaciones del enfoque
Formato esperado:
→ Código claro, documentado y bien estructurado
→ Explicaciones breves por sección
→ El nombre del archivo debe ser 'endPointWaku' + '{nombre del modelo} + '.ts' (ejemplo: endPointWakuGLMCincoPuntoUno.ts o endPointWakuGPTBigPickle.ts) y 'api' + '{nombre del modelo} + '.ts' (ejemplo: apiGLMCincoPuntoUno.ts o apiGPTBigPickle.ts) para el backend y frontend respectivamente.
→ Guarde los archivos de la API en comparacionDeModelos\src\API y los archivos del endpoint Waku en comparacionDeModelos\src\pages_api
El nombre de su modelos es:
Modelos evaluados
→ Big Pickle
→ GLM 5.1
→ MiniMax M2.5
→ Qwen3.6 Plus
→ Sonnet 4.6
Uso de tokens
→ GLM 5.1: 38 297
→ Sonnet 4.6: 29 759
→ Qwen3.6 Plus: 10 771
→ Big Pickle: 5 831
→ MiniMax M2.5: 5 756
Cantidad de líneas (entre todos los archivos generados)
La mejor implementación actual es GLM 5.1 Es la única que, dentro de las carpetas solicitadas, entrega un cliente en src/API y un endpoint Waku en src/pages/_api, con ruta coherente entre frontend y backend, validación, honeypot, límite de body, rate limiting, timeout y envío con Resend.
Pero ninguna cumple al 100% con el prompt. La más cercana es GLM 5.1 para integración real en Waku, mientras que Sonnet 4.6 parece la implementación más sólida a nivel de seguridad y Resend.
Hallazgos Clave
(1) GLM 5.1 es la mejor implementación usable en Waku. Tiene apiGLMCincoPuntoUno.ts en src/API y endPointWakuGLMCincoPuntoUno.ts en src/pages/_api. El cliente llama a /endPointWakuGLMCincoPuntoUno, que coincide con cómo Waku expone rutas _api.
Sus debilidades son: el rate limit usa Map en memoria, no es realmente escalable en serverless multi-instancia; simula éxito si faltan variables de entorno; y tiene errores TypeScript con exactOptionalPropertyTypes.
(2) Sonnet 4.6 tiene buen endpoint. Su endpoint usa el SDK de Resend, valida campos, escapa HTML, maneja CORS, aplica rate limit por IP y devuelve errores claros. Técnicamente es una de las mejores piezas.
(3) Qwen3.6 Plus tiene endpoint en carpeta correcta, pero el cliente apunta mal. El endpoint está en src/pages/_api/endPointWakuQwen36Plus.ts, pero el cliente llama a /api/contact. En Waku, ese archivo se expondría como /endPointWakuQwen36Plus, no como /api/contact.
Además no incluye honeypot ni límite de tamaño de body, y su rate limit también es solo memoria local.
(4) MiniMax M2.5 no cumple la integración Waku. Puso el endpoint en src/pages/api, pero Waku espera src/pages/_api. Además importa NextConfig desde waku, pero ese tipo no existe. También el cliente llama a /api/endPointWakuMiniMaxM2Punto5, ruta que no corresponde al patrón real de Waku.
Tiene un bug adicional en el contenido del correo: escribe el mensaje donde debería ir el email.
(5) Big Pickle separa mal cliente y backend. apiBigPickle.ts importa resend, por lo que no es realmente una API frontend segura: contiene lógica server-side en src/API.
Además no implementa honeypot, no limita tamaño del body y su rate limit también es en memoria.
Mantenibilidad
Sonnet 4.6 tiene la implementación más sólida tecnicamente por el uso de SDK oficial, validación, manejo de errores y seguridad. Qwen3.6 Plus también es buena pero con errores de integración. GLM 5.1 es la más usable en Waku pero con problemas de seguridad y escalabilidad. Big Pickle y MiniMax M2.5 tienen problemas de estructura y bugs.
Notas
→ Solo la implementación de Sonnet 4.6 retorna error si falta alguna variable de entorno, las demás implementaciones simulan un envío exitoso, lo que puede ocultar problemas de configuración en producción.
→ La implementación de Big Pickle corta ejecución si no encuenta la IP en los headers del proxy, por lo que no se puede probar en local sin configurar un proxy que agregue esa cabecera.
→ Sonnet 4.6 estructuró un mensaje correo con buen estilo, los demás modelos escribieron el mensaje sin formato.
→ MiniMax M2.5 generó un endpoint Waku en una carpeta distinta a la indicada en el prompt.
Conclusión
El experimento comparativo entre los modelos Big Pickle, GLM 5.1, MiniMax M2.5, Qwen3.6 Plus y Sonnet 4.6 reveló diferencias significativas en términos de calidad técnica, experiencia de persona usuaria, eficiencia de recursos y costo operativo. Cada modelo mostró fortalezas y debilidades particulares, lo que sugiere que la elección del modelo más adecuado depende del contexto específico de uso.
La creación de buenos prompts, uso de plugins/herramientas que reduzcan la ventana de contexto, comandos y skills, pueden hacer una gran diferencia en precios, calidad y eficiencia. En este sentido, el modelo más caro no siempre fue el que entregó mejores resultados, y el modelo más barato no siempre fue el menos útil.
Este análisis fue inspirado por las posibilidades que permiten herramientas como Open Code, que permiten usar y experimentar con múltiples modelos de manera rápida, súper fácil y directa dentro del flujo de trabajo de desarrollo, además de ofrecer planes accesibles y generosos, algo cada vez más importante.
Hay muchos más modelos pendientes a probar, por lo que esta es la primera edición de lo que seguramente será una serie de comparaciones. Además, los modelos están en constante evolución, por lo que es posible que algunos resultados cambien con el tiempo. Sin embargo, este análisis proporciona una base sólida para entender las diferencias entre estos modelos y tomar decisiones informadas al elegir cuál usar para tareas específicas de desarrollo web.
Setup de la comparación
Costos totales (para las tres solicitudes en una misma sesión)
→ GLM 5.1: $1.33
→ Sonnet 4.6: $0 (el monto se debe a que es parte del plan ya pagado de Github Copilot Pro, pero aproximadamente costó $1.19)
→ Qwen3.6 Plus: $0.26
→ MiniMax M2.5: $0 (el monto se debe a que usé la versión Free, pero hubiese costado aproximadamente $0.05)
→ Big Pickle: $0
Tokens totales (para las tres solicitudes en una misma sesión)
Entrada: 2200 aproximadamente para cada modelo
→ GLM 5.1: 119 735
→ Sonnet 4.6: 81 193
→ Qwen3.6 Plus: 60 142
→ MiniMax M2.5: 47 698
→ Big Pickle: 32 243
Ventana de contexto usada (total para las tres solicitudes en una misma sesión)
→ GLM 5.1: 58%
→ Sonnet 4.6: 41%
→ Qwen3.6 Plus: 23%
→ MiniMax M2.5: 23%
→ Big Pickle: 16%
Generación de CO2 estimada (total para las tres solicitudes en una misma sesión)
→ GLM 5.1: 35.92 g
→ Sonnet 4.6: 24.36 g
→ Qwen3.6 Plus: 18.04 g
→ MiniMax M2.5: 14.31 g
→ Big Pickle: 9.67 g
El total es equivalente a:
Conducir 0.75 km en auto de gasolina / Enviar 25 emails / Ver 2 horas de televisión
Supuestos para el cálculo:
→ 0.1 g CO₂ / 1,000 tokens → escenario eficiente
→ 0.3 g CO₂ / 1,000 tokens → escenario promedio
→ 0.5 g CO₂ / 1,000 tokens → escenario alto
Se asume misma eficiencia energética para todos los modelos, aunque en la práctica puede variar según la infraestructura y optimización de cada proveedor.
Favoritos (por categoría)
UX: Big Pickle
En la tarea de modal fue el más sólido en accesibilidad real (focus trap, retorno de foco y estructura ARIA sin ocultar el diálogo completo a lectores de pantalla).
Aunque visualmente fue más simple y realmente tiene problemas de contraste, y tiene menos extras, fue el que mejor protegió la experiencia de uso para personas con navegación por teclado/lector.
Lo he usado anteriormente para arreglar algunos bugs y me ha resultado bastante bien, no tengo ninguna queja para el tipo de modelo que es. Me parece un buen modelo para hacer planes y empezar a iterar.
Segundo lugar: Qwen3.6 Plus.
DX: GLM 5.1
Fue el más completo en integración, ejemplos y utils en varias tareas (modal con variante de confirmación, hook de estado y flujo más guiado).
En endpoint Waku fue el que dejó la integración más utilizable de extremo a extremo dentro de la estructura esperada del proyecto.
Su punto débil es que esa amplitud vino con más complejidad y mayor costo/tokens, algo que realmente no esperaba.
Es uno de los dos modelos con los que puedo crear código de buena calidad cuando trabajo con el Backend desde ahora.
En hooks de persistencia fue el más mantenible y el más estable en pruebas (¡suite completa pasando a la primera!).
El código tiende a estar mejor separado por responsabilidades y con buena claridad de API.
En modal tuvo un error de accesibilidad importante (aria-hidden en ancestro), pero en consistencia general de ingeniería frontend quedó arriba.
Definitivamente está en mi top 3 de modelos a usar, para lo que sea. Esperaba fuera el modelo más costoso de esta prueba.
Segundo lugar: Qwen3.6 Plus.
BackEnd (endpoints y utilidades server): Sonnet 4.6
En la tarea de endpoint mostró mejor calidad técnica del lado server: validación, manejo de errores, seguridad defensiva y uso sólido del SDK.
Entrega respuestas más claras y predecibles ante errores.
Junto a GLM 5.1 son los modelos que estaré usando para Backend.
Segundo lugar: GLM 5.1.
JAM Stack: Sonnet 4.6
No hay mucho más que agregar sobre este modelo. Buena para tareas de programación en general, con buenos skills y documentación, puede hacer casi cualquier cosa con una calidad bastante alta. Para tareas de frontend/backend/testing es el que más me gustó en general, con un costo razonable para lo que entrega.
Segundo lugar: GLM 5.1.
Testing: Sonnet 4.6
Fue el más estable en resultados reales de pruebas,sus tests cubren escenarios importantes sin depender de hacks frágiles del entorno.
Otros modelos tuvieron más fricción por mocks inestables, supuestos SSR inválidos o diseño de test menos robusto.
Aunque probaría primero con otros modelos gratis como Big Pickle y a partir de ahí iteraría con Sonnet 4.6 para mejorar la suite de tests si es necesario
Segundo lugar: GLM 5.1.
Valor, eficiencia y costo
Modelo que aporta más valor en relación al costo
Ganador: Sonnet 4.6
Mantuvo calidad alta en frontend/backend/testing con un costo total menor al de GLM 5.1 y mejor consistencia global en resultados.
No fue el más barato absoluto, pero parece el modelo más versátil y confiable para tareas de programación general, con un costo razonable para lo que entrega.
Modelo más eficiente
Ganador: Big Pickle(eficiencia de recursos)
Fue el que menos tokens y menor ventana de contexto consumió en total.
Para comenzar a aprender a usar Open Code, este definitivamente es el mejor modelo, además para empezar a hacer planes, iterar componentes y flujos, y luego ir mejorando la calidad con otros modelos más caros.
Si la métrica principal es rendimiento por recursos computacionales, es el más eficiente.
Modelo menos eficiente
¿Ganador?: GLM 5.1 (menos eficiente)
Fue el de mayor consumo de tokens, mayor uso de ventana de contexto y mayor costo total.
Produce salidas completas y útiles, pero su costo operativo para lograrlo fue el más alto.
Aunque su costo es menor (entrada: $1.40 / salida: $4.40 / lectura en caché: $0.26) comparado con Sonnet 4.6 (entrada: $3.00 / salida: $15.00 / lectura en caché: $0.30), al usar más tokens y consumir más ventana de contexto, su costo total para las mismas tareas fue más alto. Aún así, es un gran modelo con una calidad de salida muy buena.
¿Qué modelos seguiré usando?
Este es el orden en que, de manera general, seguiré usando los modelos para tareas de desarrollo web:
(1) Sonnet 4.6
(2) GLM 5.1
(3) Qwen3.6 Plus
(4) Big Pickle
(5) MiniMax M2.5
Si logro bajar la catidad de tokens de salida de GLM 5.1, es posible que lo use más seguido que Sonnet 4.6.
Qwen3.6 Plus es un modelo que me gustó bastante, y al que, sin mayor explicación, le tengo fé.
MiniMax M2.5 es el modelo que no creo usar mucho.
Y Big Pickle, será el modelo que usaré para hacer pruebas rápidas, iterar componentes y flujos.
