Alibaba escondió la parte más interesante del lanzamiento de Qwen3.8-Max en una página de documentación que pasó casi desapercibida: las instrucciones para conectar Claude Code, el propio entorno de programación de Anthropic, directamente con Qwen.
Piénsalo por un momento. Anthropic desarrolló el entorno de programación, Alibaba replicó la API que funciona por debajo y ahora Claude Code puede ejecutar Qwen sin notar la diferencia. Y lo más curioso es que esto funciona en ambas direcciones: durante el lanzamiento, Alibaba utilizó el propio Claude Code para obtener las puntuaciones de Fable 5 que incluyó en su tabla comparativa.
La propuesta se puede resumir en una sola idea: según las pruebas de Artificial Analysis, una tarea con Fable cuesta 3,14 dólares, mientras que con Qwen cuesta 0,91 dólares. Eso significa que, por el precio de un intento con Fable, puedes realizar tres intentos con Qwen. Y cuando trabajas con tareas que pueden evaluarse mediante pruebas automatizadas, tres intentos suelen ofrecer mejores resultados.
¿Quieres probarlo ahora mismo? Abre el archivo ~/.claude/settings.json e introduce esta configuración:
{
"env": {
"ANTHROPIC_BASE_URL": "https://token-plan.ap-southeast-1.maas.aliyuncs.com/apps/anthropic",
"ANTHROPIC_AUTH_TOKEN": "your-model-studio-key",
"ANTHROPIC_MODEL": "qwen3.8-max"
}
}Solo necesitas tres valores para cambiar el modelo que funciona dentro de Claude Code. Así de sencillo.
Cambias la URL base, añades tu clave de API e indicas el modelo Qwen que quieres utilizar. De repente, el entorno de programación que usas todos los días está trabajando con un modelo de mezcla de expertos (Mixture of Experts, MoE) de 2,4 billones de parámetros, con un precio de entrada cinco veces menor.
Y sigue siendo, literalmente, Claude Code.
Hace unos meses, yo misma tenía mis dudas sobre este tipo de afirmaciones. No confiaba demasiado en los sistemas de orquestación que combinan varios modelos, porque normalmente el mejor modelo individual termina ganando cuando comparas precisión y coste.
Pero aquí no estamos hablando de un sistema que decide entre diferentes modelos. Estamos hablando de un único modelo que realiza varios intentos para mejorar sus propios resultados.
Y funciona por una razón puramente matemática.
Las cuentas detrás del precio
Primero, veamos los precios por millón de tokens:
Modelo | Entrada | Salida | Entrada en caché |
|---|---|---|---|
Qwen3.8-Max | 2,00 USD | 6,00 USD | 0,25 USD |
Claude Fable 5 | 10,00 USD | 50,00 USD | ≈1,00 USD (90 % de descuento) |
GPT-5.6 Sol | 4,00 USD | 20,00 USD | 0,50 USD |
Gemini 3.1 Pro | 2,00 USD | 12,00 USD | 0,20 USD |
Las publicaciones de la semana del lanzamiento prometían un descuento enorme: cinco veces menos en tokens de entrada y 8,3 veces menos en tokens de salida.
En la práctica, la diferencia real se acerca más a tres veces.
Artificial Analysis evaluó todos los modelos utilizando exactamente el mismo conjunto de pruebas y publicó el coste total: 1.532 dólares para Qwen3.8-Max frente a 5.455 dólares para Fable 5.
Por tarea, eso representa 0,91 dólares frente a 3,14 dólares.
La diferencia se reduce porque Qwen genera mucho más texto.
Con exactamente la misma carga de trabajo, produjo 150 millones de tokens de salida, mientras que Fable necesitó 83 millones. Y que los tokens sean más baratos deja de ser tan relevante cuando utilizas casi el doble.
Kilo Code encontró una proporción similar en su propia prueba de creación de interfaces de usuario, compuesta por diez tareas: 3,05 dólares para Qwen frente a 8,44 dólares para Fable.
Por tanto, la comparación real es bastante sencilla:
Renuncias a un intento con Fable y, por el mismo presupuesto, puedes realizar tres intentos con Qwen para resolver la misma tarea.
Las pruebas de rendimiento
Las tablas comparativas que aparecen durante el lanzamiento de un modelo merecen un análisis riguroso. Veamos qué resultados realmente se sostienen.
En el Intelligence Index de Artificial Analysis, Fable 5 obtiene 62 puntos y Qwen alcanza 58.
La diferencia es de solo cuatro puntos, mientras que el coste de Qwen representa aproximadamente un tercio.
En la clasificación Frontend Code de Arena.ai, donde las personas votan sin conocer qué modelo generó cada resultado visual, Qwen debutó en el cuarto puesto con 1.668 puntos Elo y llegó a superar a Fable 5.
La tabla de lanzamiento de Alibaba también presenta varias victorias adicionales, entre ellas Terminal-Bench 2.1, OSWorld-Verified y pruebas de seguimiento de instrucciones.
Pero el dato más interesante es precisamente la derrota que la propia Alibaba reconoce.
En SWE-bench Pro, una evaluación de ingeniería de software de nivel profesional que utiliza repositorios reales, Fable obtuvo 80,0 puntos frente a los 67,7 de Qwen.
Cuando una empresa presenta una diapositiva en la que su competidor aparece más de 12 puntos por delante, conviene prestar especial atención a ese resultado.
El patrón es bastante consistente en las distintas evaluaciones.
Fable es más inteligente, especialmente en trabajos de ingeniería largos, complejos y distribuidos entre varios repositorios.
Qwen, por su parte, ofrece capacidades cercanas a las de los modelos más avanzados, pero con un descuento sostenido de aproximadamente tres veces.
Ninguno de los dos proveedores discute realmente esta diferencia. Simplemente eligen destacar los resultados que mejor respaldan su propuesta.
Una diferencia de cuatro puntos en inteligencia y una diferencia de aproximadamente tres dólares por tarea. Datos: Artificial Analysis, agosto de 2026.
Por qué sigue teniendo sentido utilizar Fable 5
El modelo más caro continúa siendo realmente mejor. Y en algunas situaciones, la diferencia es considerable.
En la comparación directa realizada por Kilo Code, Fable resolvió correctamente las diez tareas en el primer intento, con un promedio de aproximadamente dos minutos por tarea.
Qwen, en cambio, necesitó repetir tres de esas tareas y tardó casi ocho minutos de media.
Esto significa que el modelo más económico resultó ser 3,6 veces más lento por cada tarea completada.
Además, en la única prueba que incluía restricciones estrictas, solo Fable respetó completamente las especificaciones.
Qwen ignoró una limitación explícita que establecía un radio máximo de ocho píxeles para las esquinas.
Las evaluaciones de referencia indicaban que Qwen seguía mejor las instrucciones, pero las pruebas prácticas mostraron lo contrario.
Si una persona del equipo de ingeniería está sentada frente a la pantalla, supervisando lo que ocurre en la terminal, su tiempo se convierte en el recurso más caro.
En ese escenario, el modelo que termina correctamente en el primer intento puede ser la opción más económica, independientemente de cuánto cuesten los tokens.
Esa razón, por sí sola, puede justificar utilizar Fable.
Sin embargo, existe un principio de escalabilidad que cambia por completo el análisis.
Los monos tienen un estudio científico
En 2024, un grupo de investigadores publicó un trabajo titulado Large Language Monkeys, en el que analizaron qué ocurre cuando generamos muchas respuestas diferentes utilizando el mismo modelo.
Descubrieron que el rendimiento mejora siguiendo una relación aproximadamente logarítmica-lineal a medida que aumenta el número de intentos.
DeepSeek-Coder-V2-Instruct consiguió resolver el 15,9 % de los problemas de SWE-bench Lite en el primer intento.
Pero cuando se le permitieron 250 intentos, alcanzó una tasa de resolución del 56 %, superando los mejores resultados de un solo intento disponibles en aquel momento.
Incluso con apenas cinco muestras, el modelo más económico conseguía superar a un único intento de algunos modelos de frontera, y lo hacía con un coste menor.
Investigaciones posteriores continuaron confirmando este patrón: un modelo más pequeño que dispone de mayor capacidad de procesamiento durante la fase de resolución puede superar a otro 14 veces más grande cuando ambos trabajan con presupuestos equivalentes.
Además, pasar de uno a cuatro intentos puede aumentar las tasas de éxito aproximadamente un 50 %.
Ese es el verdadero secreto: un mismo modelo que genera múltiples soluciones para un problema.
Y cuando puedes obtener tres respuestas de Qwen por el precio de una de Fable, entras directamente en un escenario especialmente interesante.
Imagina dos personas jugando a los dardos.
Una tiene una puntería excelente, pero solo dispone de un lanzamiento.
La otra tiene una puntería algo peor, pero puede lanzar tres veces.
En muchos casos, quien dispone de tres oportunidades terminará consiguiendo un mejor resultado, porque puede conservar los aciertos y descartar los errores.
Pero hay un detalle importante.
Necesitas poder ver dónde han caído los dardos.
Lo que dicen las condiciones de este enfoque
La mejora de rendimiento mediante múltiples intentos solo funciona cuando existe algún mecanismo independiente capaz de evaluar los resultados.
Por ejemplo, una batería de pruebas automatizadas, un compilador o un error que pueda reproducirse de manera consistente.
Si eliminas esas comprobaciones, toda la teoría pierde su fundamento.
Y las investigaciones son bastante claras al respecto: aumentar la capacidad de procesamiento sin verificar los resultados es una forma de desperdiciar dinero.
Además, cuando el sistema de verificación tiene errores, los falsos positivos terminan acumulándose.
Tener infinitos monos escribiendo con un árbitro incapaz de distinguir la calidad solo significa que acabarás aceptando cualquier resultado como si fuera una obra de Shakespeare.
Existe un segundo problema.
Los errores de un mismo modelo suelen estar correlacionados.
Si un modelo tiene dificultades para comprender una determinada categoría de problemas, realizar 250 intentos no garantiza que consiga resolverlos.
Y la distancia entre «uno de mis intentos fue correcto» y «entregué la solución correcta» depende completamente de la calidad del sistema de verificación.
Una batería de pruebas poco fiable no solo deja pasar errores. También puede descartar soluciones que realmente funcionaban.
Por tanto, realizar tres intentos resulta ventajoso cuando se cumplen determinadas condiciones: la tarea dispone de una comprobación objetiva y económica, el modelo tiene capacidad para comprender el problema y el tiempo total de ejecución no es una limitación importante.
Las limitaciones que debes conocer
Hay varios aspectos adicionales que los precios de las API no muestran.
Fable 5 te hace esperar.
Su tiempo mediano hasta generar el primer token es de 126 segundos, porque realiza un proceso de razonamiento interno antes de comenzar a escribir.
Qwen, en cambio, empieza a generar respuestas en aproximadamente 2,7 segundos.
Así que el modelo más inteligente puede dejarte mirando una terminal vacía durante dos minutos y luego terminar antes.
Mientras tanto, el modelo más económico empieza casi inmediatamente, pero genera respuestas más largas y necesita más tiempo para completar el trabajo.
Tú decides qué tipo de espera prefieres.
Alibaba también establece un límite de 15.000 solicitudes por minuto para toda la cuenta, no para cada clave de API.
Esto significa que una estrategia basada en generar múltiples respuestas y seleccionar la mejor (best-of-N) puede alcanzar ese límite rápidamente.
Otro aspecto importante es la ubicación de la infraestructura.
El endpoint funciona desde Singapur, en infraestructura propiedad de una empresa china.
Esto introduce consideraciones regulatorias y de cumplimiento normativo que pueden impedir utilizar esta alternativa en sectores como las finanzas, la salud o la administración pública.
También hay que tener cuidado con la expresión pesos abiertos (open weights).
Alibaba publicó los pesos del modelo de 2,4 billones de parámetros, pero el lanzamiento incluye algunas condiciones.
El modelo utiliza una licencia personalizada, solo admite texto y necesita aproximadamente un terabyte de memoria para cargarse.
No estamos hablando de algo que puedas ejecutar fácilmente en una MacBook.
Por último, hay una limitación técnica importante: Claude Code fue diseñado para trabajar con Claude.
Cuando lo conectas a Qwen, pierdes algunas capacidades, como la posibilidad de forzar el uso de determinadas herramientas. El almacenamiento en caché también se comporta de manera diferente.
En general, muchas funciones siguen trabajando correctamente, pero la experiencia no es exactamente la misma.
Cómo organizo mis tareas entre ambos modelos
A septiembre de 2026, esta es la manera en que distribuyo personalmente mis tareas.
Qwen se encarga de los trabajos en los que puedo comprobar fácilmente el resultado.
Por ejemplo, refactorizaciones por lotes respaldadas por pruebas automatizadas, scripts de migración, iteraciones de interfaces de usuario en las que puedo verificar visualmente el resultado y cualquier proceso que pueda ejecutarse durante la noche.
En estos casos, el tiempo de ejecución no representa un problema importante y disponer de un presupuesto tres veces más eficiente significa poder realizar tres intentos para cada dificultad relevante.
Fable 5, en cambio, se encarga de los trabajos donde una decisión incorrecta puede pasar desapercibida hasta que corregirla resulta costoso.
Aquí incluyo tareas de ingeniería que abarcan varios repositorios, decisiones de arquitectura sin pruebas capaces de detectar errores, especificaciones complejas y cualquier situación donde una persona deba identificar manualmente un fallo antes de que pueda iniciarse un nuevo intento.
Elegir un modelo diferente para cada tarea es, en esencia, una forma de enrutamiento.
Y anteriormente he defendido que un sistema de enrutamiento que toma decisiones equivocadas puede terminar siendo peor que pagar directamente por el mejor modelo.
Pero aquí existe una diferencia fundamental.
No necesitas adivinar.
Solo tienes que observar la tarea y preguntarte si dispone de una batería de pruebas capaz de verificar el resultado.
La auditoría que deberías realizar
Antes de cambiar de modelo, conviene revisar algunos aspectos de tu trabajo.
- Cuenta tus pruebas. Revisa las ejecuciones de tus agentes durante el último mes y calcula cuántas terminaron con una batería de pruebas superada correctamente. Esa proporción representa el tipo de tareas que podrías asignar a Qwen.
- Supervisa los tokens de salida. Si Qwen genera más del doble de tokens que Fable para tu carga de trabajo, el ahorro puede desaparecer.
- Calcula cuánto vale tu tiempo. Las sesiones interactivas necesitan modelos capaces de resolver correctamente los problemas en el primer intento. Los procesos desatendidos tienen otras prioridades.
- Comprueba los requisitos de cumplimiento normativo. ¿Puedes procesar tus datos en Singapur? Si la respuesta es negativa, no tiene sentido continuar con esta alternativa.
- Realiza una comparación práctica. Prueba ambos modelos con tres tareas reales de tu propio repositorio antes de migrar cualquier proceso.
La analogía de los dardos resume perfectamente la decisión.
Tres intentos económicos para resolver un módulo que cuenta con buenas pruebas automatizadas pueden representar una excelente oportunidad de ahorro.
Pero tres intentos económicos para diseñar una arquitectura que nadie puede verificar no son más que tres suposiciones.
¿Cómo distribuirías tus tareas entre estos dos modelos?
Cuenta cuántas de tus tareas tienen resultados que puedes verificar objetivamente y comparte ese número.
Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.
