- Como sucesor de Qwen3.6-Plus, mejora frente a la versión anterior en codificación agéntica, además de ofrecer un conocimiento del mundo más sólido y mejor desempeño en seguimiento de instrucciones
- Registró la puntuación más alta en 6 benchmarks principales de codificación, confirmando una gran mejora en el rendimiento como agente de código
- Compatible con la función preserve_thinking, que en tareas agénticas utiliza un método para conservar en los mensajes el proceso de pensamiento de los turnos anteriores
- En benchmarks de conocimiento del mundo, mejoró con SuperGPQA +2.3 y QwenChineseBench +5.3, entre otros; y en seguimiento de instrucciones registró +2.8 en ToolcallFormatIFBench
- Se puede probar de forma interactiva en Qwen Studio y estará disponible mediante la API de Alibaba Cloud Model Studio con el nombre
qwen3.6-max-preview
Mejoras principales
- Gran mejora en capacidad de codificación agéntica frente a Qwen3.6-Plus: SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
- Refuerzo del conocimiento del mundo (world knowledge): SuperGPQA +2.3, QwenChineseBench +5.3
- Mejora en seguimiento de instrucciones (instruction following): ToolcallFormatIFBench +2.8
- Logró la puntuación más alta en 6 benchmarks principales de codificación: SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode
Características del modelo y enfoque
- Modelo exclusivo hospedado ofrecido a través de Alibaba Cloud Model Studio
- Mejoras en el rendimiento de agentes reales (real-world agent) y en la confiabilidad del conocimiento (knowledge reliability)
- Puede probarse de inmediato de forma interactiva en Qwen Studio
- El nombre del modelo en la API es
qwen3.6-max-previewy pronto podrá usarse en la API de Alibaba Cloud Model Studio
Uso de la API y funciones
- Compatible con protocolos estándar de la industria, como OpenAI-compatible chat completions y responses API, así como interfaces compatibles con Anthropic
- Mediante la función
preserve_thinking, es posible conservar el proceso de razonamiento (reasoning content) de turnos anteriores, recomendado para tareas agénticas - Al configurar
enable_thinking: True, se puede recibir por streaming de forma separada el contenido de razonamiento y la respuesta - Se ofrecen Base URL regionales para la API: Beijing, Singapur y Estados Unidos (Virginia)
Estado de desarrollo
- Actualmente está en fase de preview release y continúa mejorando de forma iterativa; se prevén mejoras adicionales en versiones posteriores
1 comentarios
Comentarios de Hacker News
Me parece un poco gracioso que la gente se obsesione solo con las comparaciones de SOTA. Yo he visto casos en los que glm 5.1 logró cosas que Opus no pudo, y también lo he visto escribir mejor código. Aún no he probado qwen max, pero también he visto que el modelo local 122b lee mejor la documentación y la procesa con más precisión. Al final, los benchmarks son solo una parte; en la práctica, cada modelo tiene fortalezas distintas, así que no creo que tenga sentido hablar de ellos como si estuviéramos comparando un martillo y una llave inglesa en una escala simple de superioridad
Llevo varios meses usando Claude Code de forma constante en la empresa y hace poco también lo aproveché bien en un pequeño proyecto personal de sitio web. El fin de semana pasado intenté por primera vez hacer self-hosting. Me pregunto si alguien, después de usar bastante CC o Codex y quedar razonablemente satisfecho, encontró una configuración self-hosted que valga la pena. Yo probé varias combinaciones con 32GB DDR5, AMD 7800X3D, RTX 4090, Windows y WSL, usando ollama, docker desktop model runner, pi-coding-agent, opencode y Gemma 4, Qwen, GLM-5.1. Como el uso base de RAM ya era alto, no pude correr buenos modelos como Gemma4-31B. En Windows puro, el manejo de rutas de archivos se rompía seguido, y la modalidad de correr pi u opencode en WSL mientras el modelo corría en docker desktop tuvo cierto éxito. Aun así, el rendimiento percibido era demasiado lento comparado con CC, y el nivel de acabado de las herramientas me pareció muy superior del lado de CC harness. Gasté demasiado tiempo en la configuración y no pude usarlo mucho en la práctica, pero igual fue un experimento interesante
Me preocupa que este sector parezca ir hacia sacar primero algo gratis para hacerse conocido y luego volverlo todo propietario. Aun así, ojalá sigan saliendo open weights. El día que nadie publique open weights va a ser realmente amargo. Si llegamos a ese mundo, a la gente común le va a resultar más difícil poseer su propio compute
Hoy también salió Kimi K2.6, así que me parece bastante natural compararlos. Solo viendo el precio, Qwen cuesta 1.3 dólares de entrada y 7.8 dólares de salida, mientras que Kimi cuesta 0.95 de entrada y 4 de salida, así que Qwen se ve más caro. Además, en el post de anuncio solo coinciden dos benchmarks, y tanto en SWE-Bench Pro como en Terminal-Bench 2.0 Kimi quedó un poco por encima de Qwen. Claro, cada modelo tiene sus fortalezas y los benchmarks no lo son todo, pero si uno mira solo los números, Kimi se siente más atractivo
La ironía de este anuncio, para mí, está en el nombre mismo. Max-Preview es proprietary y solo en la nube. Para mí, el Qwen que realmente importa es la serie open weights que la gente corre en su propio hardware. Yo corro 32B y 72B en local con dual A4000. Todavía hay una diferencia respecto al Max hosted, pero se nota que con cada release esa brecha se acorta. Por eso, la pregunta realmente interesante no es cómo se compara Max con Opus, sino cuándo el tier open-weight va a volver irrelevante al tier cloud para la mayoría de las cargas de trabajo
Mientras todos persiguen solo el SOTA, yo resuelvo todo mi trabajo de programación con varias sesiones paralelas en MiniMax M2.5 por 10 dólares al mes, y casi nunca me topo con límites
Yo también revisé la documentación de context caching de Qwen e hice pruebas con Opus, Codex y Qwen, y sí siento que Qwen es fuerte en muchas tareas de programación. Pero lo que más me importa es cómo se comporta en sesiones largas. Qwen presume una ventana de contexto grande, pero en la práctica la eficiencia en contexto largo parece depender mucho de cómo funciona el context caching. Según la documentación oficial, ofrece tanto caching implícito como explícito, pero el TTL dura solo unos minutos y además hay restricciones como matching por prefijo y una cantidad mínima de tokens. Por esas limitaciones, en flujos de trabajo donde el contexto sigue creciendo, como los agentes de programación, puede que la reutilización de caché no funcione tan bien como uno esperaría. Entonces, aunque el precio por token se vea bajo, en sesiones largas el cache hit rate puede caer y aumentar el recálculo, haciendo que el costo percibido se sienta mayor. Aun así, en tareas de seguridad personalmente hubo casos en los que Qwen me fue mejor que Opus. En mi experiencia, Qwen funciona muchísimo mejor que Opus en tareas cortas como métodos o funciones individuales, pero visto como experiencia de programación integral, me parece más un generador a nivel de función que un asistente de programación autónomo end-to-end como Claude
Viendo que Qwen se compara con Opus 4.5, me cuesta un poco tomarlo como algo de buena fe. Entiendo que no incluyan Opus 4.7 porque es muy reciente, pero Opus 4.6 salió hace ya bastante tiempo
Últimamente, viendo a los proveedores chinos, siento que hay un patrón. Primero, que están yendo hacia mantener los modelos como closed source; segundo, que están subiendo bastante los precios. En algunos casos, casi un 100 por ciento
Lo curioso es que puedes conocer toda la familia de modelos Qwen que se pueden correr en local y aun así no saber absolutamente nada de los modelos en la nube. Yo solo conocía las series 3.5 y quizá uno de 3.6, y el nombre Plus fue la primera vez que lo vi ahora