Qwen 3.8 Max: 16 tokens de raciocínio vencem o modo off

O Qwen 3.8 Max cobra $2 por milhão de tokens de entrada e $6 por milhão de tokens de saída, mas a configuração confiável mais barata não é a que a API parece oferecer. Desativar o raciocínio com reasoning_effort: "none" derrubou a precisão da nossa tarefa aritmética em duas etapas de 4/4 para 1/6. Ao definir um orçamento rígido de apenas 16 tokens de raciocínio, a precisão voltou para 6/6, com uma média de tokens de saída 20% menor que a configuração padrão. Na semana de lançamento, houve muitas alegações sobre a capacidade do modelo e pouco material para verificá-las: nenhum model card, nenhuma tabela pública de benchmarks e apenas avaliações internas, algo que o Hacker News apontou rapidamente. O comportamento da cobrança é diferente, pois qualquer pessoa com uma chave de API pode medi-lo. No primeiro dia, medimos o qwen3.8-max pelo gateway da Synthorai: todos os controles de raciocínio aceitos pela interface, o custo adicional de reasoning em cada configuração, o piso e o tempo de criação do cache implícito, a alegação de contexto de 1M e o que foi mantido do Qwen 3.7.

TL;DR

• Os sete valores de reasoning_effort do qwen3.8-max resultam em quatro comportamentos observáveis: desligado, limite de 4.096 tokens, limite de 16.384 e sem limite.
• thinking_budget é exato: ao solicitar 16 tokens, o medidor registra 16; o teto é 262.144.
• Com o raciocínio desligado, a precisão em matemática de duas etapas caiu para 1/6; um orçamento de 16 tokens alcançou 6/6 por um custo menor.
• O cache implícito fica pronto em menos de 0,3 segundo e as leituras custam $0.25/1M, mas prompts com menos de aproximadamente 4.300 tokens não entram no cache.
• Os limites de entrada são exatos e geram erro explícito: 991.808 com o raciocínio desligado e 983.616 com ele ativado.

O que os controles de raciocínio do Qwen 3.8 Max realmente fazem?

Três parâmetros funcionam, mas não são os mesmos três listados na documentação. Documentações de terceiros descrevem reasoning_effort com três valores: low, medium e xhigh, sendo xhigh o padrão. A interface que medimos aceita sete: none, minimal, low, medium, high, xhigh e max. Um valor inválido é rejeitado com essa lista exata de opções permitidas. Além dele, os parâmetros nativos thinking_budget — um inteiro positivo de até 262.144 — e enable_thinking — booleano — são repassados ao provedor, que faz a própria validação. Um orçamento de 0 ou 262.145 retorna um erro 400 informando o limite.

Em tarefas comuns, não há diferença perceptível entre os níveis de esforço. Em perguntas e respostas triviais, matemática de duas etapas e um problema médio de combinatória, low, medium, high, xhigh e a configuração padrão consumiram tokens de raciocínio dentro da mesma faixa de variação. Nenhum nível se destacou. A diferença só aparece quando a tarefa exige dezenas de milhares de tokens de raciocínio. Em um problema de contagem de números primos cuja execução sem restrição consumiu 45.129 tokens de raciocínio, os limites finalmente entraram em ação:

O modelo mental que explica todas as observações é simples: cada nível de esforço corresponde a um limite predefinido de orçamento de raciocínio, e os sete nomes resultam em quatro comportamentos. O primeiro é desligado: none e enable_thinking: false se comportam da mesma forma. Minimal e low compartilham o limite de 4.096 tokens. Medium quadruplica esse valor para 16.384. High, xhigh, max e a configuração padrão formam o quarto nível. Nenhum deles impôs limite nessa tarefa, com consumo entre 35K e 45K tokens nas diferentes execuções, uma variação normal nessa profundidade. Se os três níveis superiores diferem entre si, a divisão está acima de 45K tokens de raciocínio, muito além do que a maior parte do tráfego de produção alcança. A afirmação da documentação de que xhigh é o padrão condiz com tudo o que medimos. A divisão é clara: todas as execuções limitadas erraram, e todas as não limitadas acertaram. Abaixo do limite, o comportamento é igual entre os níveis. Por isso, o seletor parece não fazer nada no tráfego cotidiano. Acima dele, o raciocínio é interrompido no meio da tarefa. Para definir um teto específico, ignore os presets e configure thinking_budget diretamente. A próxima seção detalha esse parâmetro.

Como thinking_budget realmente funciona?

O limite é aplicado token por token, funciona como teto e não como cota, e um valor intermediário pode encarecer a tarefa em relação a não definir limite algum. thinking_budget é um parâmetro inteiro nativo do DashScope, de 1 a 262.144, com padrão documentado de 131.072 e herdado da família open-weight Qwen3. Ele define o número máximo de tokens de raciocínio de uma chamada. Solicitações com 0 ou 262.145 são rejeitadas com um erro 400 que informa o intervalo válido. Abaixo do teto, nada muda: um orçamento de 8.192 em uma tarefa que naturalmente usa algumas centenas de tokens consumiu 331 e 485, como aconteceria sem orçamento definido. Quando o teto é atingido, a aplicação é exata: orçamentos de 16, 64 e 256 interromperam o raciocínio precisamente em 16, 64 e 256 tokens em todas as execuções.

O mais interessante é o que acontece quando o limite é atingido. O modelo não abandona a tarefa. Ele para de raciocinar e conclui o trabalho na resposta visível. Em uma tarefa média de combinatória — contar os revestimentos com dominós de uma grade 2x12 —, todos os orçamentos produziram a resposta correta, mas os totais não são os esperados:

A curva não é monotônica. Um orçamento de 256 tokens custou 2,5 vezes mais que nenhum orçamento: o modelo usou a cota para iniciar uma cadeia de raciocínio, foi interrompido no meio e refez a resposta passo a passo no canal visível. O orçamento mais restrito superou os intermediários porque 16 tokens não bastam para começar o raciocínio, então o modelo parte diretamente para um cálculo visível e compacto. Três regras surgem desses resultados. Primeiro, orçamentos mínimos são um controle efetivo para tarefas de complexidade baixa a média: 16 tokens alcançaram 6/6 no nosso lote de matemática em duas etapas, com 98-161 tokens no total, contra 126-207 da configuração padrão. Segundo, não use limites intermediários em tráfego de profundidade desconhecida. Eles caem na faixa problemática em que o raciocínio é interrompido de fato e você paga pelo trabalho duas vezes. As linhas da tarefa complexa acima, com 4.096 e 16.384, mostram a mesma falha em outra escala, além de produzirem respostas erradas. Terceiro, um orçamento atingido muda o formato da saída: as execuções limitadas exibem o desenvolvimento do cálculo, o que importa quando o parser espera apenas o resultado.

Quanto da documentação do primeiro dia resiste às medições?

Aproximadamente metade. Vale publicar essa diferença porque, por enquanto, nenhum outro aspecto do lançamento pode ser verificado de forma independente. Todos os números abaixo vêm das nossas próprias medições e sondagens:

O padrão favorece a camada de cobrança: tudo o que determina o valor pago é preciso e aplicado de forma transparente, enquanto a documentação dos parâmetros está defasada em relação ao comportamento real da interface.

Desligar o raciocínio economiza dinheiro?

Economiza tokens, mas reduz a precisão, e há uma opção melhor a duas linhas de distância. No nosso lote reproduzível de aritmética em duas etapas — 1.850 caixas com 24 peças cada, 75% enviadas e 3.120 entregues —, a configuração padrão acertou 4/4, usando de 126 a 207 tokens de conclusão por chamada. reasoning_effort: "none" produziu respostas de 4 a 5 tokens e acertou 1/6. O mesmo prompt com thinking_budget: 16 acertou 6/6, usando de 98 a 161 tokens de conclusão. Para essa classe de tarefa, foi mais barato e tão preciso quanto o padrão. A aritmética de uma etapa continuou em 3/3 mesmo com none. Portanto, desligar o raciocínio é seguro para consultas e transformações de uma única etapa; o desempenho despenca em tarefas com várias etapas. Isso não é uma regressão da versão 3.8: o qwen3.7-max com o raciocínio desligado acertou 3/6 no mesmo lote.

Em tarefas difíceis, a faixa problemática descrita na seção sobre orçamento tem impacto financeiro concreto. Na execução complexa de contagem de primos, o preset low consumiu os 4.096 tokens de raciocínio, gerou mais 13.882 tokens visíveis verificando candidatos e ainda respondeu errado: $0.11 por uma resposta incorreta, contra $0.27 pela resposta correta da configuração padrão. Desativar o raciocínio produz o mesmo efeito em tarefas difíceis: com ele totalmente desligado, tanto o 3.8 quanto o 3.7 despejaram uma enumeração de 13-15K tokens na resposta visível. Em uma única execução de cada modelo, um encontrou a contagem correta e o outro errou por um único primo. Um orçamento atingido durante o raciocínio pode aumentar o gasto total e reduzir a qualidade. Limite o raciocínio em tarefas reconhecidamente simples; deixe tarefas complexas raciocinarem.

A janela de contexto de 1M tokens é real?

Na prática, sim, com limites exatos e transparentes. A API aceita até 991.808 tokens de entrada com o raciocínio desligado e 983.616 com ele ativado. Os dois limites geram erro explícito: uma solicitação acima do máximo é rejeitada com um 400 que informa o valor exato, em vez de truncar o documento silenciosamente. A recuperação de informação pontual funcionou em todos os tamanhos testados — 161K, 677K e 919K tokens —, retornando literalmente o código de substituição inserido em 11 a 63 segundos. Uma solicitação de 919K tokens custa cerca de $1.84 pelo preço de tabela. Portanto, a janela existe, mas usar sua capacidade total deve ser uma decisão arquitetural, não o padrão.

O que o cache implícito entrega e qual é o piso?

É a criação de cache mais rápida que já medimos, mas exige um prompt inicial incomumente grande. Ao repetir um prompt com salt de 6.103 tokens, obtivemos um hit já na chamada seguinte, 0,3 segundo depois. Não há janela de aquecimento a considerar na arquitetura, ao contrário dos dezenas de segundos necessários para criar o cache do Gemini. Os hits continuaram em +5 e +15 minutos sem renovar a entrada. Em +45 minutos, ela já havia expirado. Assim, o tempo de vida útil fica entre 15 e 45 minutos sem acesso. As leituras custam $0.25 por milhão, ou 0,125x o preço da entrada, sem custo adicional de gravação. O desconto foi aplicado automaticamente no campo cached_tokens e no custo medido.

O problema é o piso. Um prompt de 4.221 tokens nunca produziu hit; um de 4.360 produziu, e todo primeiro hit teve exatamente 4.096 tokens. Para prompts com menos de aproximadamente 4,3K tokens, esse cache simplesmente não existe. É uma diferença grande em relação ao mínimo de 1.024 tokens do Claude e ao cache automático em blocos pequenos do Kimi K3. Acima do piso, os hits são quantizados em blocos de 128 tokens. Observamos 4.096, 8.320, 12.544 e 16.768. Porém, a cobertura do prefixo carregado variou de 51% a 96%. Ao estimar os custos, considere o desconto sobre a maior parte de um prefixo longo, não sobre sua totalidade.

Saídas estruturadas e chamadas de ferramentas pagam o custo do raciocínio?

Por padrão, sim, e são os casos mais seguros para eliminá-lo. Saídas estritas com json_schema funcionam e a validação é real: a mesma extração sem schema retornou envolvida em blocos de código Markdown. Com a configuração padrão, a extração de quatro campos de uma fatura consumiu 252 tokens de raciocínio antes de emitir 57 tokens de JSON. Com reasoning_effort: "none", produziu um JSON válido e correto em 54 tokens totais, uma redução de 5,7 vezes. thinking_budget: 16 ficou entre os dois. A seleção de ferramentas teve o mesmo comportamento: com o raciocínio desligado, o modelo chamou a função correta usando um terço dos tokens da configuração padrão. Extrações e roteamentos de uma única etapa têm exatamente o formato em que desligar o raciocínio é seguro. A $6/1M de saída, essa prática gera economia acumulada.

Há mais um detalhe de cobrança para quem cria agentes: a API retorna toda a cadeia de pensamento em reasoning_content, e a documentação orienta clientes multi-turno a reenviá-la sem alterações. Essa exigência não é aplicada. Repetimos os turnos incluindo o raciocínio, omitindo-o e adulterando-o de propósito. Os três casos foram aceitos, sem impacto na precisão de cadeias curtas. O raciocínio reenviado é cobrado como tokens de entrada normais. Omiti-lo reduz de fato o custo do tráfego multi-turno, a menos que você observe perda de qualidade.

O que foi mantido do Qwen 3.7 e o que mudou?

O tokenizer não mudou, então seus orçamentos de tokens podem ser reaproveitados diretamente. Corpora idênticos em inglês, chinês, japonês e código resultaram nas mesmas contagens no qwen3.8-max, qwen3.7-max, qwen3.7-plus, qwen3.6-flash e qwen3.5-flash. O planejamento de custo por idioma do nosso estudo de tokenizers por idioma continua válido sem alterações.

Duas coisas mudaram. Primeiro, o 3.8-max tem um overhead fixo de prompt ausente nos outros modelos da família: a mesma mensagem de um caractere contou como 49 tokens de prompt no 3.8-max, contra 11 em todos os outros Qwen testados. É um acréscimo constante de 38 tokens por chamada. Em prompts longos, isso é irrelevante; nos curtos e frequentes, representa uma porcentagem mensurável. Segundo, o raciocínio está sempre disponível, em vez de funcionar como uma alternância de modo, com o seletor de sete níveis e o parâmetro de orçamento exato descritos acima. Os controles do 3.7 eram menos granulares. Também é preciso esclarecer os preços, pois dois modelos de cobrança circularam durante a prévia: as assinaturas Token Plan, de $6 a $68 mensais e com descontos elevados fora do horário de pico, valem para os próprios aplicativos da Alibaba, não para a API. Pela API, o preço é de $2/$6, e o medidor do nosso gateway coincidiu com ele até a quarta casa decimal em todas as chamadas do estudo.

Perguntas frequentes

É possível desligar o raciocínio no Qwen 3.8 Max?

Sim, totalmente: reasoning_effort: "none" ou enable_thinking: false elimina todos os tokens de raciocínio. Use essa opção apenas em tarefas de uma etapa. No nosso lote de aritmética em duas etapas, ela acertou 1/6, enquanto um thinking_budget de 16 tokens alcançou 6/6 com uma contagem de tokens semelhante ou menor. Para tráfego com várias etapas, a configuração mínima deve ser um orçamento pequeno, não o raciocínio desligado.

Qual é o tamanho mínimo do prompt para o cache do Qwen 3.8 Max?

Cerca de 4.300 tokens nos nossos testes: um prompt de 4.221 tokens nunca produziu hit, enquanto um de 4.360 produziu, e os primeiros hits têm sempre exatamente 4.096 tokens. Abaixo desse piso, não há desconto. Acima dele, as leituras custam $0.25/1M, sem custo adicional de gravação, e a entrada pode ser lida 0,3 segundo depois de carregada.

O Qwen 3.8 Max aceita reasoning_effort?

São aceitos sete valores — none, minimal, low, medium, high, xhigh e max —, mas os níveis funcionam como limites do orçamento de raciocínio e só se diferenciam quando a tarefa ultrapassa esses limites. Para um controle determinístico, defina thinking_budget diretamente: o limite é aplicado token por token, 0 é rejeitado e o máximo é 262.144. Atualmente, as ferramentas de clientes discordam sobre os níveis disponíveis. A lista acima contém os valores aceitos pela interface no primeiro dia.

É necessário reenviar reasoning_content em conversas multi-turno?

A documentação diz que sim, mas a API não verifica. Nos nossos testes, históricos de raciocínio omitidos ou até adulterados foram aceitos sem erro nem perda de precisão em cadeias curtas. O raciocínio reenviado é cobrado como entrada normal. Deixar de reenviá-lo é uma forma válida de reduzir custos, até que suas próprias avaliações mostrem perda de qualidade em cadeias longas.

Medido em 2026-08-03 pelo gateway da Synthorai com qwen3.8-max e comparações em qwen3.7-max, qwen3.7-plus, qwen3.6-flash e qwen3.5-flash: testes de valores aceitos pelo seletor, valores inválidos e limites de max_tokens; uma tarefa complexa com consumo natural de 45K tokens para acionar os limites de esforço; um lote fixo e reproduzível para medir a queda de precisão (n=4-6 por configuração, com salt); pares de cache com salt, intervalos de 2-3s e uma sequência progressiva de pausas; testes de recuperação pontual e overflow entre 161K e 919K tokens; e contagens idênticas do tokenizer em quatro corpora. Os valores em dólares são leituras de custo faturado pelo medidor do gateway, usando os preços de tabela ($2/$6 por 1M). Descontos, preços e comportamento do período de prévia podem mudar; confirme com seus próprios registros de uso.

← Voltar ao blog