Qwen3.6-Max-Preview: modelo de próxima geração com codificação agêntica e conhecimento de mundo aprimorados

• Sucessor do Qwen3.6-Plus, com melhorias em relação à versão anterior em codificação agêntica, conhecimento de mundo mais robusto e capacidade de seguir instruções
• Registrou a maior pontuação em 6 benchmarks principais de código, confirmando um grande avanço no desempenho de agentes de codificação
• Suporta o recurso preserve_thinking, que preserva no histórico de mensagens o processo de raciocínio dos turnos anteriores durante tarefas agênticas
• Nos benchmarks de conhecimento de mundo, houve melhora de SuperGPQA +2.3 e QwenChineseBench +5.3; em seguimento de instruções, registrou ToolcallFormatIFBench +2.8
• Pode ser testado de forma interativa no Qwen Studio e será chamado como qwen3.6-max-preview via API do Alibaba Cloud Model Studio

---

Principais melhorias

• Em comparação com o Qwen3.6-Plus, a capacidade de codificação agêntica melhorou significativamente: SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
• Conhecimento de mundo (world knowledge) aprimorado: SuperGPQA +2.3, QwenChineseBench +5.3
• Melhoria em execução de instruções (instruction following): ToolcallFormatIFBench +2.8
• Alcançou a maior pontuação em 6 benchmarks principais de código: SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode

Características do modelo e abordagem

• Modelo hospedado exclusivo fornecido via Alibaba Cloud Model Studio
• Melhorias no desempenho de agentes reais (real-world agent) e na confiabilidade do conhecimento (knowledge reliability)
• Pode ser testado imediatamente de forma interativa no Qwen Studio
• O nome do modelo na API é qwen3.6-max-preview e estará disponível em breve na API do Alibaba Cloud Model Studio

Uso da API e recursos

• Suporte a protocolos padrão do setor, como APIs OpenAI-compatíveis de chat completions e responses, além de interfaces compatíveis com Anthropic
• Com o recurso preserve_thinking, é possível preservar o processo de raciocínio (reasoning content) dos turnos anteriores, sendo recomendado para tarefas agênticas
• Ao definir enable_thinking: True, é possível receber separadamente, em streaming, o conteúdo de raciocínio e a resposta
• Base URLs da API disponíveis por região: Pequim, Singapura e EUA (Virgínia)

Estado de desenvolvimento

• Atualmente em fase de preview release, com melhorias iterativas contínuas, e mais aprimoramentos estão previstos para versões futuras

[GN⁺]

Comentários do Hacker News

• Acho meio engraçado como as pessoas ficam obcecadas só com comparações de SOTA. Já vi casos em que o glm 5.1 conseguiu fazer coisas que o Opus não conseguia, e também passei por situações em que ele programou melhor. Ainda não usei o qwen max, mas também já vi um modelo local 122b ler documentação melhor e processá-la com mais precisão. No fim, benchmark é só uma parte da história; na prática, cada modelo tem seus próprios pontos fortes, então acho que não faz sentido falar disso como se fosse comparar martelo e chave inglesa em termos de superioridade simples

  • Estou usando GLM-5.1 no pi.dev da Ollama Cloud em um projeto pessoal e estou bem satisfeito. No trabalho, usamos pi.dev junto com Claude Sonnet e Opus 4.6. Claude Code também é bom, mas depois da atualização recente ficou incômodo ter que dar compact com frequência demais. Quando usei o pi.dev, a integração com API funcionou bem mesmo sem MCP tool calling, então isso não fez tanta falta. Na verdade, tive a impressão de que o GLM-5.1 faz sites melhor que o Claude Opus e ele também está indo muito bem na plataforma de desenvolvimento full-stack que estou construindo agora
  • GLM 5.1 foi o primeiro modelo que realmente me fez sentir que os modelos chineses tinham alcançado os demais. Por isso também cancelei minha assinatura do Claude Max e, sinceramente, não senti falta nenhuma. Vendo como as opiniões divergem de pessoa para pessoa, acho que agora estamos em uma fase em que a diferença de domínio e padrão de uso importa mais do que uma hierarquia absoluta de SOTA
  • O motivo quase único de eu continuar usando Claude e ChatGPT é o tool calling. Eles também têm recursos úteis como skills. Já usei qwen e deepseek, mas às vezes eles nem conseguiam gerar documentação direito. Tenho curiosidade de saber como todo mundo lida com documentos ou Excel com essas ferramentas, e, se der, eu também gostaria de migrar
  • Alguns meses atrás, o Qwen3-Coder gerou código Rust muito melhor que Claude Opus ou Google Gemini. Fiquei especialmente impressionado porque ele produziu código que até aproveitava extensões vetoriais x86-64 do Rust. Eu o chamava por harnesses como Zed editor ou trae CLI, e fiquei realmente muito surpreso
  • As pontuações de benchmark dos modelos são em geral parecidas e as diferenças são pequenas, então, numa situação dessas, acho razoável escolher com base em outros critérios. No meu caso, se o plugin do JetBrains sair decente, eu mudo de fornecedor na hora

• Estou usando Claude Code de forma constante na empresa há alguns meses e, há pouco tempo, também aproveitei bem em um pequeno projeto pessoal de site. No último fim de semana, tentei self-hosting pela primeira vez. Gostaria de saber se alguém, depois de usar bastante CC ou Codex e ficar razoavelmente satisfeito, encontrou alguma configuração self-hosted que prestasse. Eu testei várias combinações de ollama, docker desktop model runner, pi-coding-agent, opencode e Gemma 4, Qwen, GLM-5.1 num ambiente com 32GB DDR5, AMD 7800X3D, RTX 4090, Windows e WSL. O uso base de RAM já era alto, então não consegui rodar modelos bons como o Gemma4-31B. Em Windows puro, o tratamento de caminhos de arquivo quebrava com frequência, e rodar pi ou opencode no WSL com os modelos no docker desktop funcionou até que razoavelmente. Mesmo assim, a sensação de desempenho real era lenta demais comparada ao CC, e a qualidade das ferramentas também pareceu muito melhor no lado do harness do CC. Acabei gastando tempo demais na configuração e não consegui usar por muito tempo de verdade, mas ainda assim foi um experimento divertido

  • Seria bom testar um modelo MoE e tentar offload da inferência para a CPU. Exemplos seriam Gemma 4 26b-a4b ou qwen3.6 35b-a3b. Com 32GB de RAM fica um pouco apertado se você abrir outros apps, mas, se houver RAM de sistema suficiente, roda bem. Também dá para colocar algumas camadas na GPU, mas houve problemas com a combinação de modelos MoE e llama.cpp. Em vez disso, se você colocar o KV cache na GPU, a velocidade fica bem boa e ainda dá para manter uma janela de contexto razoável. Eu vi resultados muito impressionantes localmente. Também recomendo fortemente clonar o llama.cpp direto no WSL2 e deixar um modelo frontier como o Claude Code cuidar da instalação e do tuning. Os apps construídos sobre llama.cpp não expõem todas as opções e flags, então um único flag errado já pode destruir bastante o desempenho, por exemplo fazendo o cache de contexto não funcionar. Se você compilar direto do código-fonte, quando surgir algum problema pode verificar imediatamente o código real. Nessa máquina, acho que o Gemma 4 daria pelo menos uns 20~40tok/s, o que já deve ser suficiente para uso real, e o qwen3.6 talvez seja ainda mais rápido porque tem 3b de parâmetros ativos
  • O problema que você está enfrentando provavelmente vem de falta de VRAM, então o modelo não consegue ser carregado inteiro de uma vez. Vale testar também o llmfit

• Fico preocupado porque parece que esta área está indo na direção de liberar coisas grátis primeiro para ganhar nome e depois transformar tudo em proprietary. Mesmo assim, espero que open weights continue existindo. Vai ser realmente triste se chegar o dia em que ninguém mais lançar open weights. Se esse mundo chegar, acho que vai ficar mais difícil para as pessoas comuns terem seu próprio compute

  • Acho isso uma generalização exagerada. Muitos modelos dos EUA já começaram fechados desde o início e, em contrapartida, modelos de fora dos EUA, especialmente os modelos chineses, foram mais abertos desde cedo. Na verdade, do lado chinês houve até casos que começaram como proprietary e depois foram abertos, e alguns modelos grandes da Qwen se encaixaram nisso
  • Para mim, isso parece um movimento de estratégia nacional. Continuar lançando modelos gratuitos competitivos parece uma forma de enfraquecer o moat que empresas ocidentais tentam construir com modelos proprietary. Enquanto essa narrativa favorecer a China, acho improvável que haja uma volta total ao proprietary
  • Do ponto de vista dos fabricantes de chips, provavelmente também é vantajoso manter um ambiente em que possamos rodar modelos localmente
  • Sim. Acho que, para os laboratórios chineses, open source é uma espécie de estratégia comercial. Eles têm menos alternativas eficazes de marketing para divulgar seus modelos e serviços de inferência, então há esse lado também. Vale ler este texto relacionado
  • Para mim, a estrutura sempre foi mais ou menos essa. No fim, isso também é bem próximo de SaaS, com a diferença de que hoje os planos de entrada dos frontier labs parecem praticamente uma avaliação grátis

• Como o Kimi K2.6 também saiu hoje, acho bem natural comparar os dois. Só pelos preços, o Qwen parece mais caro: 1,3 dólar de entrada e 7,8 dólares de saída, enquanto o Kimi custa 0,95 dólar de entrada e 4 dólares de saída. O post de anúncio tem só dois benchmarks em comum, e em ambos — SWE-Bench Pro e Terminal-Bench 2.0 — o Kimi ficou ligeiramente acima do Qwen. Claro que cada modelo tem seus pontos fortes e benchmark não é tudo, mas, olhando só para os números, o Kimi parece mais atraente

  • Tenho a sensação de que os modelos chineses perderam um pouco do apelo com a alta de preços. E, depois que o Gemma-4 saiu, acho que já não sobraram muitos modelos na fronteira de Pareto. Minha percepção é parecida, e as estatísticas do leaderboard da arena também valem como referência

• A ironia deste anúncio, para mim, está no próprio nome. Max-Preview é proprietary e cloud-only. Na minha visão, o Qwen realmente importante é a linha de open weights que as pessoas rodam no próprio hardware. Eu rodo 32B e 72B localmente com dual A4000. Ainda existe uma diferença para o Max hospedado, mas dá para ver essa distância diminuindo a cada release. Então a pergunta realmente interessante não é tanto como o Max se compara ao Opus, e sim quando a camada open-weight vai tornar a camada cloud irrelevante para a maioria das cargas de trabalho

• Enquanto todo mundo corre atrás do SOTA, eu faço todo o meu trabalho de programação por 10 dólares por mês com várias sessões paralelas no MiniMax M2.5 e quase nunca bato nos limites

  • Se for trabalho sério, acho que a diferença entre 10 e 100 dólares por mês não é algo tão importante para a maioria dos desenvolvedores profissionais. Pode haver exceções, como estudantes ou usuários de países de baixa renda, mas sempre acho estranho ver desenvolvedores muito bem pagos economizando demais no custo de ferramentas. Eu já sinto que até os modelos SOTA atuais ainda não são confiáveis o bastante além de tarefas pontuais; então vigiar um modelo ainda mais fraco só para economizar 10~100 dólares por mês não me parece nada atraente. Estou me divertindo experimentando modelos self-hosted em tarefas leves e descartáveis, mas em trabalho realmente importante não quero desperdiçar meu tempo
  • Fiquei curioso para saber onde você paga esses 10 dólares por mês. Queria perguntar se é no OpenRouter
  • Também fiquei curioso sobre como você usa isso na prática. Queria saber se usa opencode ou algum outro frontend

• Li a documentação de context caching do Qwen e também testei Opus, Codex e Qwen juntos, e sinto que o Qwen realmente é forte em muitas tarefas de programação. Mas o que mais me importa é o comportamento em sessões longas. O Qwen destaca sua grande janela de contexto, mas a eficiência real em contexto longo parece depender muito da forma como o context caching funciona. Pela documentação oficial, ele oferece tanto implicit quanto explicit caching, mas o TTL é curto, de poucos minutos, e há restrições como correspondência baseada em prefixo e condição mínima de tokens. Por causa dessas limitações, em workflows como agentes de programação, em que o contexto cresce continuamente, o reaproveitamento de cache pode não funcionar tão bem quanto se espera. Então, mesmo que o preço por token pareça baixo, em sessões longas a cache hit rate pode cair, a recomputação aumenta e o custo percebido acaba parecendo maior. Ainda assim, em trabalhos ligados à segurança, pessoalmente já vi o Qwen se sair melhor que o Opus. Pela minha experiência, o Qwen é muito melhor que o Opus em tarefas curtas, como no nível de método ou função isolada, mas, olhando a experiência geral de programação, ele me parece mais um gerador em nível de função do que um assistente autônomo de programação end-to-end como o Claude

  • Mesmo assim, acho que interromper sessões longas e começar novas sessões curtas continua sendo best practice. O próprio Claude Code Best Practices da Anthropic diz que "uma sessão nova e limpa com um prompt melhor quase sempre é melhor do que uma sessão longa com muitas correções acumuladas"
  • Da última vez que verifiquei, context caching só reduzia custo e latência, sem mudar de fato quais tokens eram produzidos

• Quando vejo a Qwen comparando com Opus 4.5, acho difícil interpretar isso totalmente de boa-fé. Entendo não incluírem o Opus 4.7 por ser muito recente, mas o Opus 4.6 já existe há um bom tempo

  • Para mim, o Opus 4.5 foi o primeiro ponto em que senti que o modelo estava bom o bastante para uma variedade de problemas. Antes disso, usar IA em trabalho de desenvolvimento sempre acabava desperdiçando mais tempo por causa de alucinações, então não era uma escolha produtiva. Mas, mesmo que o progresso tivesse parado no Opus 4.5, acho que já teríamos conseguido acelerar uma quantidade enorme de trabalho real. Não me parece que o desenvolvimento de software vai voltar a ser centrado totalmente em código escrito à mão. Então, se alguém oferecer algo no nível do Opus 4.5 ou um pouco melhor por um décimo do preço, isso pode ser bem atraente para muita gente. Claro que, para desenvolvedores ocidentais, ainda vale muito a pena pagar mais de 100 dólares por mês no Opus 4.7. O tempo desperdiçado por modelos de nível inferior custa muito mais caro. Por enquanto, pretendo continuar pagando um prêmio por modelos que me façam perder menos tempo e entreguem resultados melhores com menos ajustes de prompt. Ao mesmo tempo, a velocidade das mudanças é realmente impressionante, e hoje sinto que até os modelos abertos já chegaram a um nível capaz de competir com modelos frontier de dois anos atrás. Qwen 3.6 MoE 35B A3B e os modelos grandes do Gemma 4 já conseguem rodar em hardware relativamente comum, como um Macbook potente, Strix Halo ou GPUs recentes de 24GB ou 32GB, sem custar muito mais do que um notebook de desenvolvedor do período pré-IA. Eles escrevem código, escrevem texto razoavelmente bem, usam ferramentas, e o tamanho de contexto já é suficiente para uso real. Ainda não estão no nível do Opus 4.5, mas são bem impressionantes. Eu já misturo vários modelos para segurança e code review e, embora ainda ache Claude Code com Opus a melhor opção para a maior parte do desenvolvimento, estou disposto a testar Qwen também. Os modelos menores já entregam muito pelo tamanho, então tenho expectativa alta para os maiores
  • Se dinheiro realmente não fosse problema, no fim bastaria olhar só para o topo de desempenho, como Codex 5.4 ou Opus 4.7. Mas, para muita gente, qualidade por custo é uma variável enorme. Até entre assinantes do Claude, muita gente não consegue usar sempre o Opus 4.7 por causa da pressão de custo e uso, e acaba ficando no Sonnet ou em versões antigas do Opus. Então, olhando a curva de valor por qualidade, esse tipo de comparação faz bastante sentido
  • Nos últimos meses, o desempenho do Opus 4.6 tem variado demais, então eu não queria gastar tokens à toa
  • Quando o Sonnet 4.6 saiu, troquei meu modelo padrão de Opus para Sonnet. Pela minha percepção, o Sonnet 4.6 parecia estar em um nível próximo do Opus 4.5. O 4.6 e o 4.7 são melhores, mas para a maioria das tarefas o salto já não é tão grande, então economizar custo virou uma escolha bastante razoável. Quando modelos mais baratos alcançarem esse nível, aí sim será algo ainda maior, e o GLM 5.1 já parece bem próximo, então estou usando bastante. Nesse sentido, acho válido comparar com Opus 4.5
  • Acho que a comparação deve ser feita entre os mais parecidos. E, quando os benchmarks são publicados pelo próprio fornecedor, é óbvio que ele tende a escolher frameworks em que seu modelo vai bem e deixar de fora os desfavoráveis. Por isso, no fim, o que dá para confiar de verdade são benchmarks independentes

• Olhando para os fornecedores chineses recentemente, sinto que existe um padrão. O primeiro é caminhar para manter os modelos como closed source, e o segundo é aumentar bastante os preços. Em alguns casos, a alta chega perto de 100%

  • Soa meio estranho falar disso como se fosse uma característica só de empresas chinesas. Tenho a impressão de que empresas de outros países não fazem nada diferente
  • O Qwen max sempre foi cloud only, e como é um modelo com mais de 1T, acho inevitável que o custo seja alto
  • Eu devolveria a pergunta: em que isso é diferente das empresas americanas?
  • Eu perguntaria se isso realmente se aplica a modelos como GLM 5.1, DeepSeek V3.2 ou o recém-lançado Kimi K2.6. Na prática, não parece combinar muito com esses casos
  • A primeira reação é: as empresas americanas também adoram fazer isso, não?

• O engraçado é que dá para conhecer toda a linha de modelos Qwen que rodam localmente e, ao mesmo tempo, não saber absolutamente nada da parte de modelos em nuvem. Eu conhecia só a linha 3.5 e talvez um 3.6, e o nome Plus foi a primeira vez que vi

  • Se bem me lembro, a linha Plus existe desde que o Qwen chat foi lançado. Tenho quase certeza de que usei um modelo Plus diretamente pelo menos no começo do ano passado