Gemini 3.6 Flash: o controle de raciocínio que altera o custo em 30x (medido)

O Gemini 3.6 Flash cobra pelos tokens de raciocínio além da resposta, e você controla quanto ele gasta em cada requisição. Na mesma tarefa de escrita com 120 palavras, a configuração padrão custou $0.03316, enquanto minimal custou $0.00110. É uma diferença de 30x para resultados que um leitor não conseguiria distinguir. Esse controle é a decisão de custo mais importante nesse modelo, mas tem uma armadilha séria. O Gemini 3.6 Flash ficou disponível para todos em 2026-07-21, por $1.50 por milhão de tokens de entrada e $7.50 por milhão de tokens de saída, abaixo dos $9 cobrados pela saída no 3.5 Flash. O lançamento ocorreu junto com o Gemini 3.5 Flash-Lite e o 3.5 Flash Cyber, ajustado para segurança. Este artigo mede os dois modelos de uso geral: 3.6 Flash e Flash-Lite.

TL;DR

• reasoning_effort: "minimal" reduziu o custo por chamada em 91-97% em relação à configuração padrão, chegando a uma diferença de 30x em uma tarefa de 120 palavras. Não houve perda em tarefas de etapa única, saída estruturada e chamada de ferramentas, mas a precisão em matemática com várias etapas caiu de 3/3 para 0/3.
• A afirmação do Google de “17% menos tokens de saída” depende da carga de trabalho: nossas tarefas com bastante raciocínio usaram 19% menos tokens e custaram 32% menos; nossa suíte de agentes usou 9% mais tokens, mas custou 6% menos.
• A janela de contexto de 1M é real: o modelo recuperou uma informação inserida em 972K tokens. O prompt cache também corresponde exatamente ao mínimo publicado pelo Google, de 4,096 tokens. É uma aderência clara à especificação, ao contrário de alguns modelos com “contexto de 1M” que entregam menos do que anunciam.

Todas as medições abaixo foram feitas em 2026-07-24 pelo gateway da Synthorai. Adicionamos variações aos prompts repetidos para evitar caches, e cada número está respaldado pelos registros brutos de uso.

Quanto custa cada tarefa no Gemini 3.6 Flash com as configurações padrão?

O raciocínio domina a cobrança de saída, mesmo sem aparecer na resposta. Com o nível padrão, o modelo gasta muito mais tokens pensando do que respondendo. Esses tokens de raciocínio são cobrados pela tarifa integral de saída, de $7.50/M:

Este é o padrão que importa: uma resposta factual de dois tokens ainda consumiu 69 tokens de raciocínio, e o parágrafo de 120 palavras gastou 30x mais tokens pensando do que escrevendo. Os tokens de raciocínio aparecem discriminados em completion_tokens_details.reasoning_tokens, então você vê a quantidade, mas nunca o conteúdo. O Gemini não retorna resumo nem rastro do raciocínio. É o extremo mais fechado do espectro que mapeamos em nosso estudo sobre a anatomia do uso de tokens, no qual o Kimi K3 retorna toda a cadeia de raciocínio e o GPT-5.6 retorna um resumo. A próxima seção mostra como reduzir esse gasto.

O que o controle de raciocínio realmente faz?

É um controle de custo real e monotônico. Na maioria dos tipos de tarefa, a economia vem praticamente sem contrapartida. Definir reasoning_effort ou o parâmetro nativo thinking_config.thinking_level como minimal zerou os tokens de raciocínio e reduziu o custo de cada tarefa em 91-97%:

O controle funciona de fato e aceita os valores minimal, low, medium (o padrão) e high. Em nossos testes, cada nível aumentou progressivamente o raciocínio: minimal com 0 tokens, low com ~180, medium com ~530 e high com ~650. O problema de minimal é justamente não raciocinar, e a aritmética com várias etapas precisa disso. Quando forçamos o modelo a responder de forma sucinta ao problema textual sobre lápis e sacolas, ele errou nas três tentativas. As respostas erradas variaram, em vez de apontarem para uma única falha sistemática. Em recuperação, classificação, formatação e perguntas de etapa única, minimal manteve a precisão e reduziu a conta em uma ordem de grandeza.

A regra prática é a mesma que encontramos no Kimi K3: minimal é um padrão defensável para extração, consulta e formatação, mas uma armadilha em qualquer tarefa que exija etapas intermediárias. Configure por rota, não globalmente. Antes de usar em produção para tarefas com bastante raciocínio, valide a precisão em seus próprios casos.

Dois padrões comuns em produção deixam isso claro: saída estruturada e chamada de funções consomem raciocínio na configuração padrão, mas podem usar minimal com segurança. Uma extração limitada por schema, usando response_format com um JSON schema, cobrou 337 tokens de raciocínio na configuração padrão e retornou JSON válido. Com minimal, não cobrou nenhum token de raciocínio, continuou retornando JSON válido de acordo com o schema e custou 9x menos. A chamada de função se comportou da mesma forma: 74 tokens de raciocínio e uma chamada correta de get_weather(city) no padrão, contra zero tokens de raciocínio e a mesma chamada correta com minimal, por um custo 4x menor. São tarefas de etapa única com uma camada “estruturada”. O modelo não precisa raciocinar para preencher um campo indicado explicitamente. Se seu tráfego é composto por extração ou roteamento de ferramentas, minimal oferece economia quase sem contrapartida.

A afirmação de “17% menos tokens de saída” se confirma?

Depende da carga de trabalho, e a diferença entre os cenários é esclarecedora. No lançamento, o Google afirmou que o 3.6 Flash usa cerca de 17% menos tokens de saída do que o 3.5 Flash no Artificial Analysis Index, chegando a 65% em avaliações específicas de agentes. Executamos os dois modelos em dois ambientes de teste próprios e obtivemos resultados em direções opostas:

Nas tarefas curtas com bastante raciocínio, o resultado não só confirmou a afirmação como superou o número divulgado: a saída total caiu 19%, perto dos 17% do Google, e quase toda a redução veio do raciocínio, não da resposta. Em uma nova execução pareada dos dois modelos, separamos os tokens de saída. A resposta visível caiu apenas 4%, enquanto o raciocínio caiu 19%. A redução se concentrou nas tarefas de matemática e escrita, nas quais o 3.6 chega ao mesmo resultado com menos deliberação. Esse é o mecanismo por trás do benchmark: quando a tarefa depende do orçamento de raciocínio, o 3.6 é realmente mais eficiente para a mesma resposta.

No tráfego de agentes com vários turnos, o resultado se inverte: o 3.6 consumiu cerca de 9% mais tokens de saída do que o 3.5 em toda a suíte. O ganho de eficiência está na fase de raciocínio, e loops de agentes gastam proporcionalmente menos do orçamento nessa etapa. Há menos espaço para economizar, e os turnos um pouco mais longos do 3.6 acabam predominando. Mesmo assim, a conta cai, porque os dois efeitos se combinam de formas diferentes. Tarefas com bastante raciocínio economizam tanto em tokens quanto na redução da tarifa de $9 para $7.50, totalizando −32%. No tráfego de agentes, a economia vem apenas do preço, totalizando −6%. Em resumo, os “17% menos tokens de saída” são reais quando o raciocínio domina a saída e se invertem quando isso não acontece. Meça sua própria combinação de tráfego em vez de assumir que o número divulgado se aplica a tudo. E lembre que o controle da seção anterior tem muito mais impacto do que a mudança de versão.

A janela de contexto de 1M é real?

Sim, e o modelo falha de forma explícita, não silenciosa. Inserimos uma informação a ser recuperada no início de prompts cada vez maiores. Ela ainda foi recuperada corretamente com 972K tokens de entrada. Ao passar do limite, o prompt retornou claramente 400 input token count exceeds the maximum, em vez de descartar conteúdo sem aviso. Isso importa porque nem todo modelo de “contexto de 1M” disponível no mercado realmente entrega a janela anunciada. Para quem quiser reproduzir o teste: use conteúdo variado, composto por frases. Um prompt criado pela repetição de um único token fez o modelo produzir texto degenerado e sem sentido muito antes de atingir o limite.

O prompt cache é automático e corresponde à especificação no ponto mais importante. O Google documenta um mínimo de 4,096 tokens para o context cache nos modelos Flash, e nossa varredura chegou exatamente a esse valor. Prefixos de até ~2.1K nunca foram armazenados em cache; os acertos começaram por volta de 4.1K tokens; e, após um aquecimento de 5 a 8 chamadas, aproximadamente os últimos 2.1K continuaram fora do cache a cada acerto. Leituras de entrada em cache custam $0.15/M, um desconto de 10x em relação à tarifa de $1.50 para entradas novas. O resultado é tranquilizador: ao contrário de alguns modelos que medimos, cujos números anunciados superam o que o endpoint realmente entrega, tanto o mínimo do cache quanto a janela de 1M do Gemini 3.6 Flash funcionam como descrito na documentação. Ainda assim, o cache só compensa para prefixos realmente longos e estáveis. Os modelos Flash aceitam apenas cache automático, ou implícito, e não a API explícita de conteúdo em cache. Portanto, não é possível fixar manualmente um documento grande e reutilizá-lo abaixo do limite mínimo.

Onde o Gemini 3.5 Flash-Lite se encaixa?

O Flash-Lite é a opção de custo previsível. Ele nunca consome tokens de raciocínio de forma invisível, então a cobrança acompanha diretamente a saída visível. No mesmo problema matemático com várias etapas, o Flash-Lite custou $0.00057, contra $0.00368 do 3.6 Flash na configuração padrão. É cerca de 6x mais barato, e desenvolveu a solução na própria resposta, em vez de usar um campo oculto de raciocínio. Com entrada a $0.30/M e saída a $2.50/M, é a escolha padrão adequada para tarefas de etapa única, com alto volume e sensíveis à latência. Use o 3.6 Flash quando a tarefa precisar do raciocínio adicional que o controle pode fornecer. O tokenizer não mudou entre os três modelos novos nem em relação ao Gemini 2.5 Flash. Em todas as gerações que verificamos, as contagens de tokens foram idênticas para inglês, chinês, japonês, coreano e Python. Portanto, orçamentos por idioma criados para o 2.5 continuam válidos no 3.6, sem recalibrar a linha de base.

Perguntas frequentes

É possível desativar completamente o raciocínio no Gemini 3.6 Flash?

reasoning_effort: "minimal" ou thinking_level: "minimal" zerou os tokens de raciocínio em nossos testes e é o menor nível disponível. Os valores aceitos são minimal, low, medium e high. Não existe um estado separado de “desativado”, e tentativas de desabilitar o raciocínio à força são rejeitadas pelo provedor. Portanto, minimal é o limite inferior e, para tarefas de etapa única, é baixo o suficiente.

Por que minha conta do Gemini é maior do que a resposta visível sugere?

Porque os tokens de raciocínio são cobrados pela tarifa integral de saída e não fazem parte do texto retornado. Uma resposta de dois tokens pode incluir de dezenas a milhares de tokens de raciocínio cobrados. Consulte completion_tokens_details.reasoning_tokens ou calcule total_tokens − prompt − completion para identificar a cobrança real de saída. Reduza o nível de raciocínio quando a tarefa permitir.

Gemini 3.6 Flash ou Claude Haiku 4.5?

Os dois ocupam a mesma faixa de modelos rápidos, com preços parecidos. A escolha depende da carga de trabalho; não há um único vencedor. Sob a ótica de custo, o diferencial do 3.6 Flash é o controle de raciocínio. Com minimal, ele fica uma ordem de grandeza mais barato no tráfego de etapa única. Na configuração padrão, porém, consome raciocínio que o Haiku 4.5, a $1/$5, não consome. Benchmarks publicados colocam o Haiku 4.5 à frente em profundidade de programação e o 3.6 Flash à frente em matemática e preço bruto por token. Escolha de acordo com a composição do seu tráfego e meça os dois em suas próprias tarefas antes de decidir.

O Gemini 3.6 Flash é mais barato do que o 3.5 Flash?

Sim, em todas as cargas de trabalho que medimos, embora a diferença dependa do formato da tarefa. A saída caiu de $9/M para $7.50/M. Nas tarefas curtas com bastante raciocínio, o 3.6 também consumiu menos tokens de saída, reduzindo o custo em cerca de 32%. No tráfego de agentes, ele consumiu um pouco mais de tokens, e a economia veio apenas da redução da tarifa, ficando em cerca de 6%. Nos dois casos, é mais barato. Migre e repita as medições com sua própria combinação de tráfego. Para uma decomposição do custo por token entre famílias de modelos, consulte nosso estudo sobre a anatomia do uso de tokens.

Medições realizadas em 2026-07-24 com gemini-3.6-flash, gemini-3.5-flash e gemini-3.5-flash-lite pelo gateway da Synthorai. As contagens de tokens da matriz de tarefas e da suíte de agentes vieram dos registros de uso de cada chamada. Os resultados do controle de raciocínio vieram de uma ablação com cinco tarefas e prompts variados (n=3 por célula). Os testes de contexto e cache usaram recuperação de informação inserida e varreduras de prefixos. As contagens de precisão consideram tarefas com uma única resposta verificável. Preços e comportamentos podem mudar; valide com seus próprios registros de uso.

← Voltar ao blog