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

O Gemini 3.6 Flash cobra os thinking tokens além da resposta, e a quantidade que ele gasta é um dial que você controla por requisição. Na mesma tarefa de escrita de 120 palavras, a configuração padrão custou $0.03316 e a configuração minimal custou $0.00110: uma variação de 30x para um resultado que o leitor não conseguiria distinguir. Esse dial é a decisão de custo mais importante nesse modelo, e tem um porém sério. O Gemini 3.6 Flash entrou em disponibilidade geral em 21/07/2026, a $1.50 por milhão de tokens de input e $7.50 por milhão de output, contra $9 de output no 3.5 Flash. Foi lançado junto do Gemini 3.5 Flash-Lite e de um 3.5 Flash Cyber ajustado para segurança; este post mede os dois tiers de uso geral, o 3.6 Flash e o Flash-Lite.

TL;DR

• reasoning_effort: "minimal" reduziu o custo por chamada em 91–97% em relação ao padrão (uma variação de 30x numa tarefa de 120 palavras), sem custo em trabalho de etapa única, output estruturado e tool-calling, mas quebrando a matemática de múltiplas etapas de 3/3 → 0/3.
• Os “17% a menos de output tokens” do Google dependem da carga: nossas tarefas pesadas em raciocínio rodaram 19% mais leves (32% mais baratas), enquanto a suíte de agentes ficou 9% mais pesada (6% mais barata).
• O contexto de 1M é real (uma agulha em 972K tokens foi recuperada) e o prompt caching bate exatamente com o piso de 4.096 tokens publicado pelo Google — uma correspondência limpa com a spec, ao contrário de alguns modelos “com contexto de 1M” que ficam abaixo do que anunciam.

Tudo abaixo foi medido em 24/07/2026 através do gateway da Synthorai, com prompts repetidos e salteados para burlar os caches; os registros de uso brutos sustentam cada número.

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

O raciocínio domina a conta do output, e é cobrado quer você o veja ou não. No effort padrão, o modelo gasta muito mais tokens pensando do que respondendo, e esses reasoning tokens são cobrados à tarifa cheia de $7.50/M de output:

O padrão a internalizar é este: uma resposta factual de dois tokens ainda carregou 69 tokens de raciocínio, e o parágrafo de 120 palavras gastou 30x mais tokens pensando do que escrevendo. Os reasoning tokens ficam discriminados em completion_tokens_details.reasoning_tokens, então você vê a contagem, mas nunca o conteúdo. O Gemini não retorna nenhum resumo ou trace do raciocínio, o extremo mais fechado do espectro que mapeamos no nosso estudo de anatomia do uso de tokens, onde o Kimi K3 devolve toda a cadeia de raciocínio e o GPT-5.6 um resumo. A próxima seção é sobre como baixar esse gasto.

O que o dial de raciocínio faz na prática?

É uma alavanca de custo real e monotônica, e na maioria dos tipos de tarefa é praticamente dinheiro de graça. Configurar reasoning_effort (ou o nativo thinking_config.thinking_level) para minimal zerou os tokens de raciocínio e cortou o custo em 91–97% por tarefa:

O dial é real e os valores aceitos são minimal, low, medium (o padrão) e high; cada passo comprou monotonicamente mais raciocínio nos nossos testes (minimal 0 tokens, low ~180, medium ~530, high ~650). A única coisa que minimal não consegue fazer é pensar, e aritmética de várias etapas precisa disso: forçado a responder o problema dos lápis e das sacolas de forma sucinta, o modelo errou nas três tentativas, com respostas erradas dispersas em vez de um único erro sistemático. Em recuperação, classificação, formatação e perguntas de uma única etapa, minimal manteve a acurácia e cortou a conta em uma ordem de magnitude.

A regra prática é a mesma que encontramos no Kimi K3: minimal é um padrão defensável para extração, consulta e formatação, e um tiro no pé para qualquer coisa que precise de etapas intermediárias. Defina isso por rota, não globalmente, e verifique a acurácia nas suas próprias tarefas antes de aplicá-lo em algo que exige raciocínio pesado.

Dois formatos de produção de alto volume tornam o caso concreto: saída estruturada e function calling gastam raciocínio no padrão, e ambos rodam com segurança em minimal. Uma extração restrita por schema (response_format com um JSON schema) faturou 337 tokens de raciocínio no padrão e retornou JSON válido; em minimal faturou zero raciocínio, ainda retornou JSON válido e em conformidade com o schema, e custou 9x menos. Um function call se comportou da mesma forma: 74 tokens de raciocínio e uma chamada get_weather(city) correta no padrão, contra zero raciocínio e a mesma chamada correta em minimal, 4x mais barato. São tarefas de uma única etapa disfarçadas de “estruturadas”, e o modelo não precisa raciocinar para preencher um campo que já lhe foi indicado. Se o seu tráfego é extração ou roteamento de ferramentas, minimal é quase dinheiro de graça.

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

Depende da carga de trabalho, e a divisão é instrutiva. No lançamento, o Google posicionou o 3.6 Flash como gastando cerca de 17% menos tokens de saída que o 3.5 Flash no Artificial Analysis Index (até 65% em avaliações agênticas individuais). Rodamos os dois modelos em dois dos nossos próprios testbeds e obtivemos sinais opostos:

Nas tarefas curtas e intensivas em raciocínio, a alegação não só se confirmou como superou o número anunciado: a saída total caiu 19%, perto dos 17% do Google, e veio quase toda do thinking, não da resposta. Separando os tokens de saída num rerun pareado dos dois modelos, a resposta visível encolheu só 4%, enquanto o raciocínio caiu 19%, concentrado nas tarefas de matemática e escrita, onde o 3.6 chega ao mesmo resultado deliberando menos. Esse é o mecanismo por trás do benchmark: em trabalho que depende do orçamento de thinking, o 3.6 é genuinamente mais eficiente para a mesma resposta.

No tráfego agêntico, multi-turno, o sinal se inverte: o 3.6 gastou cerca de 9% mais saída que o 3.5 ao longo da suíte. O ganho de eficiência vive na fase de raciocínio, e os loops de agente gastam proporcionalmente menos do orçamento ali, então há menos a economizar e os turnos um pouco mais longos do 3.6 acabam vencendo. De qualquer forma a conta cai, porque os dois efeitos se somam de formas diferentes: tarefas intensivas em raciocínio economizam tanto em tokens quanto no corte de tarifa de $9→$7.50 (−32%), enquanto o tráfego de agente economiza só no preço (−6%). O resumo honesto é que “17% menos tokens de saída” é real onde o thinking domina a saída e se inverte onde não domina. Meça sua própria mistura em vez de assumir o número anunciado, e lembre que o botão da seção anterior mexe nisso muito mais do que a mudança de versão.

A janela de contexto de 1M é real?

Sim, e ela falha de forma barulhenta, não silenciosa. Colocamos uma agulha de recall no início de prompts de tamanho crescente: ela ainda foi recuperada corretamente com 972K tokens de entrada, e um prompt acima do limite retornou um 400 input token count exceeds the maximum limpo, em vez de descartar conteúdo em silêncio. Vale dizer isso porque nem todo modelo “1M-context” no mercado realmente serve a janela que anuncia. Uma nota de teste para quem for reproduzir: preencha com filler variado, em formato de frase, porque um prompt construído com um único token repetido empurrou o modelo para gibberish degenerado bem antes do limite de tamanho.

O prompt caching é automático e bate com a spec no número que importa. O Google documenta um mínimo de 4.096 tokens para context caching nos modelos Flash, e nosso sweep caiu exatamente ali: prefixos de ~2.1K ou menos nunca cacheiam, os hits começaram por volta de 4.1K tokens, e cada hit deixou aproximadamente os últimos 2.1K sem cache, após um aquecimento de 5 a 8 chamadas. A entrada cacheada é lida a $0.15/M, um desconto de 10x sobre a tarifa fresca de $1.50. Vale dizer isso de forma direta porque é o caso tranquilizador: diferente de alguns modelos que medimos, cujos números anunciados superestimam o que o endpoint entrega de fato, o piso de cache do Gemini 3.6 Flash e sua janela de 1M fazem o que a documentação diz. O caching ainda só compensa para prefixos genuinamente longos e estáveis, e note que os tiers Flash suportam apenas caching automático (implícito), não a API explícita de cached-content, então você não consegue fixar manualmente um documento grande e reutilizá-lo abaixo do piso.

Onde entra o Gemini 3.5 Flash-Lite?

O Flash-Lite é o tier de custo previsível. Ele nunca gasta reasoning tokens de forma silenciosa, então a conta acompanha o output visível na proporção de um para um. No mesmo problema de matemática com múltiplos passos, o Flash-Lite cobrou US$ 0,00057 contra os US$ 0,00368 do 3.6 Flash no modo padrão — cerca de 6x mais barato —, e resolveu a questão à vista, não em um campo de reasoning oculto. A US$ 0,30/M de input e US$ 2,50/M de output, é o padrão certo para trabalho de alto volume, sensível a latência e de passo único; suba para o 3.6 Flash quando a tarefa precisar do reasoning que o dial pode acrescentar. O tokenizer não mudou, não só entre os três modelos novos, mas desde o Gemini 2.5 Flash: contagens de token idênticas em inglês, chinês, japonês, coreano e Python em todas as gerações que checamos. Ou seja, orçamentos por idioma feitos para o 2.5 valem para o 3.6 sem precisar refazer a base.

FAQ

Dá para desligar o reasoning por completo no Gemini 3.6 Flash?

reasoning_effort: "minimal" (ou thinking_level: "minimal") zerou os reasoning tokens nos nossos testes e é o piso do dial; os passos aceitos são minimal, low, medium e high. Não existe um estado “disabled” separado, e tentativas de desativar o reasoning à força são rejeitadas no upstream. Então minimal é o mínimo possível — e para tarefas de passo único é baixo o bastante.

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

Porque os reasoning tokens são cobrados na tarifa cheia de output e não fazem parte do texto que você recebe de volta. Uma resposta de dois tokens pode carregar de dezenas a milhares de reasoning tokens cobrados. Leia completion_tokens_details.reasoning_tokens (ou reconcilie total_tokens − prompt − completion) para ver o custo real de output, e baixe o dial onde a tarefa permitir.

Gemini 3.6 Flash ou Claude Haiku 4.5?

Ocupam a mesma vaga de tier rápido com preços parecidos, e a divisão é por carga de trabalho, não por um vencedor único. Na nossa ótica de custo, o thinking dial do 3.6 Flash é o diferencial: minimal o deixa uma ordem de magnitude mais barato em tráfego de passo único, enquanto o padrão gasta reasoning que o Haiku 4.5, a US$ 1/US$ 5, não gasta. Os benchmarks publicados dão ao Haiku 4.5 vantagem em profundidade de código e ao 3.6 Flash a liderança em matemática e preço bruto por token. Escolha conforme o que compõe seu tráfego, e meça os dois nas suas próprias tarefas antes de decidir.

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

Sim, em toda carga de trabalho que medimos, embora o tamanho da economia dependa do formato. O output caiu de US$ 9/M para US$ 7,50/M, e em tarefas curtas com muito reasoning o 3.6 também gastou menos output tokens, então o custo caiu cerca de 32%; em tráfego de agente ele gastou um pouco mais de tokens e a economia veio só do corte de tarifa, cerca de 6%. De qualquer forma sai mais barato; migre e meça o seu próprio mix. Para a decomposição de custo por token entre famílias, veja nosso estudo de anatomia do uso de tokens.

Medido em 2026-07-24 em gemini-3.6-flash, gemini-3.5-flash e gemini-3.5-flash-lite via gateway Synthorai; contagens de token da matriz de tarefas e da suíte de agentes vieram de registros de uso por chamada, resultados do effort-dial de uma ablação salgada de cinco tarefas (n=3 por célula), sondas de contexto e cache de needle-recall e varreduras de prefixo. As contagens de acurácia usam tarefas com uma única resposta verificável. Preços e comportamento podem mudar; verifique contra os seus próprios registros de uso.

← Voltar ao blog