Gemini 3.7 Flash: tarefas custam de 2,5x a 8x menos

O Gemini 3.7 Flash cobra de 2,5x a 8x menos pelas mesmas tarefas que o Gemini 3.6 Flash, e apenas metade dessa redução vem do corte de preço anunciado. A tarifa promocional de $0.75 por milhão de tokens de entrada e $3.75 por milhão de tokens de saída é 50% menor que a do 3.6. Em nossa medição, o mesmo prompt com 6,9 mil tokens custou exatamente a metade ($0.00529 contra $0.01057). A outra metade aparece menos: o gemini-3.7-flash consumiu de 26% a 77% menos tokens de thinking que o 3.6 nas mesmas quatro tarefas medidas. Testamos o modelo no segundo dia após o lançamento: preços, controle de thinking (uma opção deixou de existir), incompatibilidades destacadas pela documentação do Google e outras tratadas com menos ênfase, além de cache, contexto e compatibilidade do tokenizer.

TL;DR

• O preço promocional de $0.75/$3.75 vale até 31 de dezembro de 2026; depois passa para $1.50/$7.50. Em nossa medição, o mesmo prompt custou exatamente a metade do valor no 3.6.
• O thinking padrão caiu de 26% a 77% em relação ao 3.6 (144 contra 384 tokens em uma tarefa com 5 etapas). Por isso, o custo por tarefa cai de 2,5x a 8x, não apenas 2x.
• Não dá mais para desligar o thinking: todas as formas de desativação retornam um erro 400 (“Thinking level is unsupported”); low agora é o mínimo.
• Em um loop de ferramentas com dois turnos, o 3.7 reduziu pela metade o processamento no turno que recebeu o resultado da ferramenta (32 contra 61 tokens). Recusar uma pergunta sem resposta custou 500 tokens nos dois modelos.

Quanto custa de fato o Gemini 3.7 Flash?

Metade da tarifa do 3.6 até 31 de dezembro de 2026 e menos da metade dos tokens usados pelo 3.6 em todas as tarefas que medimos. O preço de lançamento anunciado pelo Google é de $0.75 por milhão de tokens de entrada e $3.75 por milhão de tokens de saída. A partir de 1º de janeiro de 2027, volta para $1.50/$7.50, exatamente a mesma tabela do 3.6. Leituras de cache custam $0.075 por milhão, 10% do preço promocional da entrada. A medição confere com a tabela: o mesmo prompt com 6,9 mil tokens custou $0.0052875 no 3.7 e $0.0105675 no 3.6, exatamente a metade.

O efeito maior vem do que o modelo deixou de consumir. Executamos tarefas idênticas com salt, três vezes cada. A tabela mostra a mediana de tokens de reasoning e o custo de saída resultante:

Segundo a apresentação do Google, o 3.7 “raciocina com mais cuidado”. Em nossas tarefas, isso significou menos tokens, não mais. Os dois modelos mantiveram acerto de 3/3 em todos os casos. Combinando a tarifa pela metade com uma redução de pelo menos metade no thinking, a migração reduz na prática o custo por tarefa de 61% a 88%, antes do cache. Há uma ressalva de calendário: o orçamento precisa considerar a volta do preço em 1º de janeiro, seguindo o mesmo padrão do preço promocional do Sonnet 5.

Um tipo de tarefa foge dessa tendência e quase nunca entra no orçamento: recusar uma resposta. Perguntamos sobre cinco entidades inventadas — uma empresa, um instituto, uma carta municipal, uma liga metálica e um prêmio. Os dois modelos recusaram as cinco perguntas e gastaram mais thinking nisso do que em qualquer outra tarefa medida: mediana de 511 tokens de reasoning no 3.7 e 494 no 3.6. Dizer “não há registro disso” consumiu 3,5x mais thinking que resolver a cadeia aritmética de 5 etapas. Pipelines com geração aumentada por recuperação que frequentemente não encontram dados pagam esse custo em cada falha, e esse é o único caso em que a vantagem de eficiência do 3.7 desaparece. A medição também ajuda a delimitar uma preocupação da semana de lançamento: avaliadores apontaram uma taxa maior de alucinação no 3.7, mas, nas perguntas sobre entidades inventadas, ele expressou incerteza em 5 de 5 casos, exatamente como o 3.6.

Quais controles de thinking continuam funcionando no 3.7?

Três opções, sem possibilidade de desligar, exatamente como documentado: low, medium (padrão) e high. A documentação não deixa claro que as formas de desativação disponíveis no 3.6 deixaram de funcionar. Todas as que enviamos — reasoning_effort: "none", "minimal", thinking_budget: 0, thinking: {"type": "disabled"}, enable_thinking: false — retornaram o mesmo erro 400 do upstream: “Thinking level is unsupported: THINKING_LEVEL_MINIMAL”. Uma segunda rota de requisição, independente, foi mais direta: “Reasoning is mandatory for this endpoint and cannot be disabled”. Portanto, o comportamento vem do modelo, não da camada de conversão de um cliente. No 3.6-flash, medido no mesmo lote, none e minimal ainda zeram o consumo. A linha Flash adotou a política da categoria pro: não é possível desligar o thinking, e o 3.6 agora é o último Flash que permite isso.

Resultados do controle ainda disponível na tarefa de 5 etapas (mediana de 3 execuções, todas com 3/3 acertos):

Duas observações práticas. Confirmamos que o padrão é medium: execuções sem configuração consumiram 154 tokens na matriz de testes, um resultado equivalente aos 147 da opção medium explícita. E thinking_budget está mesmo obsoleto: todos os valores diferentes de zero que enviamos, de 16 a 1.024, foram aceitos e consumiram os mesmos 135-138 tokens. Na prática, não tiveram efeito. No 3.6, orçamentos pequenos ainda desativam o thinking, enquanto os maiores estabelecem limites. Se a sua integração com o 3.6 controla custos por orçamento, no 3.7 basta escolher um nível; essa é toda a interface. Para comparar quais controles têm efeito entre diferentes fornecedores, consulte nossa matriz de controles de thinking.

Quanto custa cada etapa de um agente?

A escolha de ferramentas não mudou em relação ao 3.6. O processamento entre as etapas ficou mais barato. Executamos um loop de dois turnos com duas funções — consultar um incidente e depois reiniciar o serviço indicado por ele —, três vezes por modelo:

Os dois modelos escolheram primeiro get_incident e depois restart_service, com 3/3 acertos e o mesmo número de tokens de prompt. A diferença está no segundo turno: o 3.7 usa cerca da metade do thinking antes de fazer a próxima chamada. É a etapa que o agente repete. Um loop de 20 etapas com essas medianas gera cerca de $0.0043 em custo de saída no 3.7, contra $0.0131 no 3.6. A proporção se mantém após o reajuste de janeiro porque vem da quantidade de tokens, não das tarifas. É assim que o salto do Google nos benchmarks de agentes se transforma em redução de custos: menos tokens de processamento a cada salto, multiplicados por muitos saltos.

A posição do modelo diante dos concorrentes depende do benchmark e precisa ser avaliada antes de migrar um agente de programação. Comparativos independentes colocam o 3.7 Flash à frente no FrontierCode (43,6% contra 42,7% do Sonnet 5) e perto de 3x o Sonnet 5 no AutomationBench. Já o GPT-5.6 Terra lidera o Terminal-bench, e o Sonnet 5 fica à frente no teste de tarefas de desktop, segundo o mesmo comparativo e a cobertura da semana de lançamento. No custo mínimo, a vantagem do 3.7 é clara.

O que deixa de funcionar ao migrar do 3.6?

Há dois erros 400 definitivos e vários comportamentos que falham de forma mais silenciosa do que a documentação sugere. A nota de migração do Google orienta remover temperature, top_p, top_k, candidate_count e turnos prefill do modelo. Nossas medições mostraram:

A diferença de comportamento merece atenção: o controle de thinking faz validação explícita — um nível não suportado gera um erro 400 claro, com o valor informado —, enquanto parâmetros de amostragem e limites de saída aceitam qualquer coisa enviada. Se sua biblioteca cliente define temperature por padrão, nada quebra hoje. Se ela usa turnos prefill do assistant para orientar a saída, já não funcionava antes da migração.

Cache, contexto e tokenizer continuam compatíveis?

Sim, mas com uma demora maior. O cache implícito acerta com a mesma distribuição do 3.6: na segunda chamada de um prompt idêntico, 4.076 dos 6.905 tokens vieram do cache, reduzindo o custo da chamada em 52%. As leituras custam 10% do preço promocional da entrada. Porém, a criação do cache ficou mais lenta: o 3.6 teve um acerto 4 segundos após a chamada inicial; no 3.7, não houve acerto após 4 segundos, apenas após 30. Tráfego duplicado em sequência rápida chega antes de o cache estar pronto. A economia da gravação permanece igual nos demais aspectos.

O contexto aceitou 708.912 tokens de entrada em uma única chamada e respondeu corretamente a uma pergunta do tipo needle, em linha com o limite anunciado de 1M e sem uma faixa de preço específica para contextos longos na tabela. O tokenizer de texto produz contagens idênticas em quatro gerações: gemini-3.1-pro-preview, 3.5-flash, 3.6 e 3.7 contaram o mesmo corpus misto de inglês, chinês e código em 50 tokens. Portanto, os orçamentos de tokens podem ser reutilizados sem alterações. Entradas de imagem continuam sendo cobradas pelos 1.089 tokens fixos em qualquer tamanho que medimos em toda a linha Gemini. Nenhuma das duas gerações retorna o texto de reasoning: reasoning_content veio vazio em todas as chamadas. Assim, o thinking cobrado permanece invisível nos dois modelos, uma reclamação recorrente nas discussões da semana de lançamento. A saída estruturada continua funcionando: o json_schema estrito retornou JSON válido e correto em 3/3 execuções, e reasoning_effort: "low" zerou o thinking da extração, a mesma faixa segura para tarefas de uma etapa que nossa matriz de controles encontrou em todos os modelos.

Perguntas frequentes

Quanto custa a API do Gemini 3.7 Flash?

$0.75 por milhão de tokens de entrada e $3.75 por milhão de tokens de saída como preço promocional até 31 de dezembro de 2026. A partir de 1º de janeiro de 2027, volta para $1.50/$7.50, a mesma tabela do Gemini 3.6 Flash. Leituras de cache custam $0.075 por milhão. Em prompts idênticos, nossa medição mostrou que o 3.7 custou exatamente a metade do 3.6.

É possível desligar o thinking no Gemini 3.7 Flash?

Não. Todas as formas de desativação retornam um erro 400 (“Thinking level is unsupported”). As opções são low, medium (padrão) e high. Mesmo em low, nossa tarefa de 5 etapas consumiu 133 tokens de reasoning. O Gemini 3.6 Flash continua sendo o Flash mais recente em que reasoning_effort: "none" funciona, pelo preço que o 3.7 terá após o período promocional.

O Gemini 3.7 Flash realmente custa menos por requisição que o 3.6?

A economia supera os 50% anunciados: o modelo também usa de 26% a 77% menos thinking nas mesmas tarefas. Em nossas medições, o custo por tarefa caiu de 61% a 88% — um problema verbal de 2 etapas passou de $0.0020 para $0.0002. Depois de 31 de dezembro, as tarifas voltam à paridade, e resta apenas a economia de thinking.

O código escrito para o Gemini 3.6 Flash funciona no 3.7?

Na maior parte dos casos. Parâmetros de amostragem (temperature, top_p, top_k) continuam sendo aceitos apesar de constarem na lista de remoção da documentação, e valores excessivos de max_tokens são limitados silenciosamente. Há duas incompatibilidades definitivas: turnos prefill do assistant retornam um erro 400 — como já ocorria no 3.6 — e todas as formas de desligar o thinking agora geram um 400. Portanto, o controle de custos precisa sair de thinking_budget e usar os três níveis disponíveis.

Medições realizadas em 2026-08-15 pelo gateway da Synthorai, dois dias após o lançamento: matriz de níveis e opções de desativação (7 valores de esforço, 5 orçamentos, 2 parâmetros de desativação, n=3, com nova execução do gemini-3.6-flash no mesmo lote para cada comparação), medição do custo de reasoning em quatro tarefas, saída estruturada com JSON estrito, testes de parâmetros obsoletos, aceitação do limite de saída e de um contexto de 708K, pares de cache implícito com dois tempos de espera, comparação de tokenizer com corpus fixo entre quatro gerações do Gemini, loop de chamada de funções com dois turnos (n=3 por modelo) e teste de recusa com cinco perguntas sobre entidades inventadas. Os valores em dólares por tarefa usam os tokens de conclusão medidos e a tarifa atual de saída de cada modelo. Duas afirmações foram verificadas em uma segunda rota de requisição independente: a aceitação de valores excessivos de max_tokens e a ausência de uma opção para desligar o thinking. Os preços e as datas promocionais são os termos publicados pelo Google; o comportamento pode mudar conforme o rollout avança.

← Voltar ao blog