Controles de raciocínio em LLMs: teste com 13 modelos

O mesmo parâmetro de controle de raciocínio significa três coisas diferentes dependendo de qual modelo você o envia: thinking_budget: 16 consome exatamente 16 tokens de raciocínio no Qwen 3.8 Max, GLM 5.2 e em ambas as builds do DeepSeek V4, é silenciosamente ignorado no Kimi K3 e no MiniMax M3, e é rejeitado com um 400 pelo GPT-5.6. Sondamos 13 modelos de nove fornecedores com cada grafia de controle que a superfície compatível com OpenAI aceita, e então medimos quanto cada posição do seletor custa em tokens de raciocínio e o que ela quebra em precisão, nas mesmas quatro tarefas com salt, três execuções por célula.

TL;DR

• thinking: {"type": "disabled"} zera o raciocínio em 11 de 13 modelos; as duas exceções (Gemini pro, GPT-5.6) o rejeitam.
• Qwen, GLM e DeepSeek consomem thinking_budget: 16 como exatamente 16; Kimi e MiniMax aceitam o campo e não mudam nada: Kimi consumiu de 8 a 97 contra esse limite, nunca 16.
• Desativar o raciocínio derrubou a aritmética de 5 passos de 3/3 para 0-1/3 em oito modelos; DeepSeek V4 Pro e Claude mantiveram 3/3 escrevendo os passos na resposta visível.
• A extração de JSON pontuou 3/3 com o raciocínio desativado em todos os 12 modelos que suportam a desativação.

Quais controles de raciocínio cada API aceita?

Há três famílias de controles nas interfaces compatíveis com OpenAI, mas nenhum modelo respeita todas. reasoning_effort recebe um enum (none a max), thinking_budget recebe uma quantidade de tokens e thinking: {"type": "disabled"} — assim como sua variante enable_thinking: false — solicita a desativação completa. Este é o mapa de aceitação que medimos, com uma pergunta simples e um salt diferente por célula:

Duas linhas merecem um alerta. O Google divide sua própria linha: a camada flash desliga de forma limpa, enquanto a camada pro rejeita toda grafia de desligamento com um 400, condizente com a posição do Google de que o raciocínio de classe pro não pode ser desativado. E as duas células claude-fable-5 marcadas como “accepted” diferem do contrato publicado pela Anthropic para esse modelo, que especifica que o raciocínio não pode ser desativado; considere essas células como em fluxo.

“Aceito” significa “aplicado”?

Não, e essa diferença aparece na fatura. Uma resposta 200 apenas confirma que o parâmetro passou pelo parser, não que chegou ao modelo. O teste para distinguir os dois casos é simples: envie um budget de 16 e consulte o medidor.

Qwen, GLM e as duas versões do DeepSeek consumiram exatamente 16. Kimi consumiu 8, 19, 79 e 97 contra o mesmo limite em quatro execuções, nunca 16, e o MiniMax se comportou da mesma forma em 18-44, cobrado como de costume, sem nada na resposta sugerindo que o limite havia sido descartado. O Gemini traduz orçamentos em seu controle nativo com granularidade grosseira: no flash, limites de 0 a 64 se comportaram como um desligamento completo, enquanto 1.024 permitiu o raciocínio (mediana de 141 em nossa tarefa de 5 etapas); o nível pro reduziu seu consumo sob um limite, mas estabeleceu um piso em torno de 200 contra os 64 solicitados e não consegue chegar a zero. GPT-5.6 e Claude estão na extremidade honesta do espectro: orçamentos numéricos são rejeitados com um 400 e você sabe imediatamente onde está.

A regra prática é simples: depois de configurar qualquer controle de raciocínio, consulte completion_tokens_details.reasoning_tokens na resposta seguinte e confirme que o valor mudou. Um controle que falha de forma explícita custa uma repetição da chamada. Um controle que falha silenciosamente cobra, em todas as chamadas, o raciocínio que deveria estar limitado.

Existe uma forma universal de desativar o raciocínio?

thinking: {"type": "disabled"} é o mais próximo possível: ele zerou o raciocínio em 11 dos 13 modelos, abrangendo Kimi, Qwen, ambos os DeepSeeks, GLM, Gemini flash, MiniMax, a linha Seed da ByteDance e todos os três modelos Claude. Seu semelhante enable_thinking: false corresponde a ele em quase todos os lugares, com uma exceção silenciosa: o MiniMax o aceita e mantém o raciocínio (31 tokens de raciocínio em nossa sonda).

As duas exceções falham de forma ruidosa em vez de silenciosa: o Gemini pro retorna um 400 para cada erro de escrita (o tier não pode desativar o raciocínio), e o GPT-5.6 também rejeita o campo. O GPT-5.6 não precisa de um botão de desligar no mesmo sentido: gpt-5.6-luna consome zero tokens de raciocínio em consultas e extrações simples por padrão (o padrão de duas alavancas dessa família), e reasoning_effort: "none" fixa esse comportamento também para entradas com formato matemático.

Qual é o impacto de desativar o raciocínio na precisão?

Em uma cadeia aritmética de 5 etapas, o impacto foi total: oito modelos caíram de 3/3 para 0/3 ou 1/3 assim que o raciocínio foi desativado. Em um problema textual de 2 saltos, a diferença foi bem menor: a maioria manteve 3/3 sem raciocínio. Apenas Kimi e MiniMax caíram para 0/3, repetindo o mesmo estado frágil sem raciocínio identificado no estudo da versão de lançamento do K3. A queda ocorre quando a quantidade de etapas ultrapassa o que o modelo consegue processar em uma única resposta visível.

Os três modelos que mantiveram a precisão usam o mesmo recurso: com o raciocínio desativado, escrevem as etapas intermediárias na resposta visível. A mediana das respostas do DeepSeek V4 Pro subiu de 115 para 142 tokens; no Sonnet 5, passou de 70 para 139. A cobrança deixa de ser por raciocínio oculto e passa a ser por raciocínio visível, normalmente pela mesma tarifa de saída. O controle de desativação muda mais o rótulo do custo do que reduz o consumo. Já os modelos que, sem raciocínio, retornam obedientemente respostas de 1-4 tokens são os que perdem precisão.

Quando ocorre essa queda, um budget pequeno recupera a precisão: thinking_budget: 256 restaurou o resultado de 3/3 no Qwen e nas duas versões do DeepSeek, com mediana de 77-128 tokens de raciocínio. É o mesmo padrão de recuperação com um limite mínimo que medimos no retreino do DeepSeek e nos limites ocultos do Qwen 3.8.

Uma célula da matriz não produziu nenhum número: claude-fable-5 retornou stop_reason: "refusal" (categoria cyber) para a formulação exata da nossa pergunta aritmética nas 12 execuções, em todas as configurações de esforço. Uma reformulação semanticamente idêntica passou nas 12 execuções. A Anthropic documenta a recusa como um motivo de interrupção de primeira classe, com um mecanismo opcional de fallback. Se modelos da categoria fable fizerem parte da sua rotação, trate esse motivo de interrupção antes que ele apareça em produção.

O que os níveis de esforço realmente entregam?

Cada fornecedor apresenta uma curva diferente, e somente a do Google cresce de forma consistente. Executamos todo o enum aceito por cada modelo na mesma tarefa de 5 etapas, três vezes por posição, e colocamos as medianas na mesma escala:

As linhas assumem quatro formatos. Controles reais: os dois Geminis crescem de forma monotônica, de 137 para 390 tokens de raciocínio no flash e de 180 para 387 no pro, que satura em high. A configuração low manteve precisão de 3/3 consumindo entre um terço e metade dos tokens das posições mais altas, tornando-se um bom padrão fixo para pipelines com Gemini. Linhas estáveis: DeepSeek (78 em low, 54 em max, com tendência de queda), Kimi (94 em minimal, 67 em max) e MiniMax (61-93, sem ordem aparente) expõem um controle com várias posições que não alteram o comportamento. O próprio model card do DeepSeek publica benchmarks com “max reasoning effort”, uma configuração que já consideramos indistinguível do padrão. Limites que não são atingidos: os níveis do Qwen funcionam como tetos de budget e não aparecem em uma tarefa desse tamanho (85-156, sem tendência). Só fazem diferença em tarefas profundas, como medimos isoladamente. Não monotônicos: o high do GLM consumiu 116 tokens, contra 184 do low e 345 do max. Enquanto esse mapeamento não se estabilizar, trate as posições intermediárias como não ordenadas. Os dois modelos adaptativos praticamente dispensam o controle: o gpt-5.6-luna varia de 32 a 41 tokens em todo o enum, enquanto o output_config.effort do Opus 5 alterou a saída visível apenas dentro da margem de ruído (54-63 tokens; no Sonnet 5, 71-92). Quem toma a decisão real é o raciocínio adaptativo.

A regra operacional decorre desses formatos: no Gemini, escolha o nível de forma intencional, porque cada posição afeta o custo. No Qwen, GLM e DeepSeek, use thinking_budget, que é exato, e o controle de desativação, não o enum. Nos demais, o enum é apenas decorativo entre o estado desativado e o padrão. A única forma de identificar o comportamento é repetir o teste acima: mesma tarefa, todas as posições e leitura do medidor.

O formato da tarefa também importa. Na extração de JSON em uma única etapa, o raciocínio ativado gerou as maiores contagens de toda a matriz: 377 tokens de raciocínio no GLM e 332 no Gemini flash. Isso não trouxe nenhum benefício, pois todos os 12 modelos que permitem desativar o raciocínio alcançaram 3/3 sem ele. A extração estruturada paga o maior imposto desnecessário de raciocínio e é justamente o tipo de carga em que a desativação é segura.

É possível ver pelo que você pagou?

O medidor de cobrança é universal, mas o raciocínio em si não. Seis modelos de famílias com pesos abertos retornam o texto de raciocínio em reasoning_content: GLM 5.2 e DeepSeek V4 Pro retornaram o que parece ser a cadeia completa, com 508 e 312 caracteres para 167 e 100 tokens de raciocínio. Kimi, Qwen, DeepSeek Flash, MiniMax e Seed retornaram traces mais curtos, aproximadamente proporcionais ao baixo consumo. GPT-5.6 e os dois Geminis não retornam nada: os tokens de raciocínio são cobrados, mas permanecem invisíveis. O Claude retorna blocos thinking cujo conteúdo é omitido por padrão na interface que medimos. É possível saber que houve raciocínio, mas não ver seu conteúdo.

Essa diferença de visibilidade afeta a depuração do comportamento dos budgets: nos modelos que não retornam nada, reasoning_tokens nos detalhes de uso é o único instrumento disponível. A regra continua a mesma: confie no medidor, não no status 200.

Perguntas frequentes

Como desativar o raciocínio em uma API compatível com OpenAI?

Envie thinking: {"type": "disabled"}; em nossa matriz de 13 modelos, isso zerou o raciocínio em 11 (Kimi, Qwen, DeepSeek x2, GLM, Gemini flash, MiniMax, Seed e a família Claude). O Gemini pro não pode ser desativado e retorna um 400; o GPT-5.6 rejeita o campo, mas por padrão mal pensa em tarefas simples. Verifique lendo reasoning_tokens na próxima resposta.

thinking_budget: 0 desativa o raciocínio?

Depende do modelo. No Gemini flash e no ByteDance Seed, 0 se comporta como um desligamento limpo; Qwen e DeepSeek rejeitam 0 com um 400; Kimi e MiniMax aceitam qualquer orçamento e o ignoram. Onde os orçamentos são aplicados até o token (Qwen, GLM, DeepSeek), o valor mínimo útil é um pequeno número positivo: 256 manteve 3/3 no Qwen e em ambas as builds do DeepSeek em nossa tarefa de 5 etapas, enquanto o GLM oscilou para 2/3 na mesma configuração.

É seguro desativar o raciocínio na extração de JSON?

Em nossos testes, sim: a extração em uma única etapa alcançou 3/3 sem raciocínio em todos os modelos que permitem desativá-lo. Com o raciocínio ativado, o mesmo resultado consumiu até 377 tokens de raciocínio. O limite está na quantidade de etapas, não no formato da saída: tarefas com várias etapas perderam precisão sem raciocínio em 8 dos 11 modelos. Há uma ressalva identificada em nosso estudo do DeepSeek: no retreino 0731, ativar o raciocínio corrompeu valores em JSON estrito. Nesse caso, desativá-lo também corrige a resposta.

Quais modelos aplicam budgets de raciocínio com exatidão?

Qwen 3.8 Max, GLM 5.2 e ambas as versões DeepSeek V4: solicite 16, o medidor lê 16. Kimi K3 e MiniMax aceitam o mesmo campo e o ignoram; Gemini o traduz de forma grosseira (valores baixos funcionam como desligado no flash, o pro estabelece um piso alto); GPT-5.6 e os modelos da geração Claude 5 rejeitam orçamentos numéricos completamente (o budget_tokens do Claude retorna um 400 apontando para o pensamento adaptativo).

Medido em 2026-08-11/12 através do gateway Synthorai: sondagens de aceitação para reasoning_effort (7 valores), thinking_budget (0/16/1024), enable_thinking e thinking:{"type":"disabled"} em 13 modelos, reverificadas horas antes da publicação; depois uma matriz de custo de 552 chamadas (quatro formatos de tarefa com sal x 3 execuções por braço, braços limitados aos controles verificados como funcionais de cada modelo), uma escada de enumeração completa de 183 chamadas na tarefa de 5 etapas (os dados do gráfico), células de reforço e uma sondagem de visibilidade de raciocínio por modelo. Precisão avaliada a partir de respostas brutas; medianas de tokens de n=3; tokens de raciocínio lidos de completion_tokens_details.reasoning_tokens (modelos Claude reportam apenas tokens de saída). Prompts com sal por chamada. A semântica dos controles e os enums são a superfície que medimos nesta data e podem mudar; sonde novamente antes de confiar em qualquer célula individual.

← Voltar ao blog