Gemini 3.7 Flash vs 3.6 Flash: o que mudou em preço, código e agentes — e quando vale migrar

Para quem já roda Gemini 3.6 Flash, o 3.7 Flash merece prioridade de teste em código, agentes e fluxos multi-etapa, mas não há motivo técnico para migrar tudo às cegas. Em 28 de agosto de 2026, a diferença de preço por token não é um argumento a favor do novo modelo: o Google aplica a mesma tarifa promocional aos dois, de US$ 0,75 por 1 milhão de tokens de entrada e US$ 3,75 por 1 milhão de tokens de saída no modo Standard até 31 de dezembro. A decisão passa a ser outra: qual modelo conclui seu trabalho com menos falhas, retries, intervenção humana e tempo total?

O lançamento do Gemini 3.7 Flash em 13 de agosto veio apenas três semanas depois do 3.6 Flash. O Google o posiciona como seu Flash mais capaz para coding e agentes, e a Reuters também destacou esse foco no anúncio. A documentação o considera GA e pronto para produção, com janela de contexto de 1.048.576 tokens, saída máxima de 65.536 tokens e a mesma suíte de ferramentas embutidas do 3.6 Flash.

O que realmente mudou do Gemini 3.6 Flash para o 3.7 Flash

Dimensão	Gemini 3.6 Flash	Gemini 3.7 Flash	O que isso muda na decisão
Preço Standard até 31/12/2026	US$ 0,75 input / US$ 3,75 output por 1M tokens	US$ 0,75 input / US$ 3,75 output por 1M tokens	Hoje, o preço de tabela por token é igual. O 3.7 não é mais barato que o 3.6 no uso Standard atual.
Preço Standard a partir de 01/01/2027	US$ 1,50 / US$ 7,50	US$ 1,50 / US$ 7,50	A promoção termina para ambos; o comparativo precisa ser revisto quando a tabela mudar.
Contexto	1.048.576 tokens	1.048.576 tokens	Não há ganho de capacidade de contexto apenas por trocar de versão.
Saída máxima	65.536 tokens	65.536 tokens	O teto de resposta não é o motivo para migrar.
Ferramentas	Function calling, code execution, computer use em preview, grounding, file search e outras	Mesma suíte de ferramentas embutidas do 3.6	O ganho está mais na qualidade de execução do que em uma ferramenta nova exclusiva.
Foco declarado	Velocidade, agentes, código e tarefas reais	Código complexo, agentes, execução multi-etapa e aderência a design	Workloads com muitos passos e possibilidade de loop são o alvo mais claro da atualização.
Thinking no 3.7	Suporta reasoning	Níveis low, medium e high; medium é o padrão	É possível trocar qualidade por latência/custo de forma explícita no 3.7; comparar modelos exige também fixar a política de thinking.

Há uma nuance importante no preço. Quando o 3.6 Flash foi lançado, em 21 de julho, sua tarifa Standard era de US$ 1,50 por milhão de tokens de entrada e US$ 7,50 por milhão de saída. O 3.7 estreou com preço introdutório equivalente à metade disso, mas o Google estendeu a mesma promoção ao 3.6. Portanto, a frase “o 3.7 custa metade do 3.6” descreve a comparação com o preço original do 3.6, não a diferença entre os dois modelos em 28 de agosto.

Onde os benchmarks mostram ganho relevante

Os números mais úteis para esta decisão não são testes genéricos de perguntas e respostas, e sim avaliações que se aproximam de software engineering, uso de ferramentas e trabalhos longos. Na model card do Gemini 3.7 Flash, o Google publica os dois modelos lado a lado.

Benchmark	O que tenta medir	3.6 Flash	3.7 Flash	Leitura prática
FrontierCode 1.1 Main	Qualidade de código de produção	34,4%	43,6%	Ganho material para geração e correção de código, mas ainda longe de indicar acerto garantido.
DeepSWE v1.1	Engenharia de software de horizonte longo	48,6%	65,3%	É um dos sinais mais fortes para agentes que precisam investigar, editar e validar ao longo de vários passos.
Code Arena	Desenvolvimento web	1538 Elo	1588 Elo	Melhora consistente, especialmente relevante se o workload gera interfaces ou implementa designs.
Terminal-bench 2.1	Coding agentic em terminal	78,0%	85,8%	Favorece migração em automações de desenvolvimento que chamam ferramentas e executam comandos.
AutomationBench	Automação de workflows empresariais	17,0%	30,4%	Salto grande, porém o próprio quadro do Google identifica esse conjunto como privado; trate-o como evidência orientativa, não como prova reproduzível do seu caso.
GDP.pdf	Compreensão de documentos PDF complexos	22,0%	34,0%	É um argumento para piloto em fluxos de análise documental densa.
GDM-MRCR v2, 128k	Recuperação em contexto longo	91,8%	97,0%	Há ganho, mas a janela máxima continua igual; contexto maior não deve ser confundido com raciocínio melhor.
CharXiv, sem ferramentas	Síntese a partir de gráficos complexos	85,2%	84,5%	Nem toda avaliação melhora. Uma troca de versão continua exigindo teste de regressão.

O quadro evita uma leitura seletiva: o 3.7 melhora bastante em vários trabalhos para os quais foi otimizado, mas não vence o antecessor em absolutamente todas as métricas. Benchmark é um sinal de direção; não é uma promessa de taxa de sucesso em produção.

Latência: o 3.7 parece mais rápido, mas “velocidade” depende do que você mede

Em medição independente da Artificial Analysis, comparando os dois modelos com reasoning alto, o 3.7 Flash marcou 56 no Intelligence Index contra 52 do 3.6, gerou cerca de 324 tokens por segundo contra 181 e teve tempo até o primeiro token de aproximadamente 9,93 segundos contra 17,63 segundos no recorte consultado. A mesma organização calculou custo por tarefa 30% menor para o 3.7 em seu conjunto do Intelligence Index.

Isso é útil porque preço por token não conta a história inteira. Um modelo com a mesma tarifa pode sair mais barato por tarefa se precisar de menos tentativas ou chegar à resposta correta com um perfil de tokens mais eficiente. Mas a metodologia também mostra por que não se deve transformar esses números em SLA: tempo até o primeiro token, velocidade de geração, tempo de thinking e tempo total de resposta são métricas diferentes, e variam com prompt, região, carga, nível de reasoning e tamanho da saída. A metodologia da Artificial Analysis mede essas dimensões separadamente.

No 3.7, o Google recomenda low para tarefas sensíveis à latência, como chat em tempo real e análise rápida; medium, que é o padrão, para a maior parte dos usos complexos; e high para problemas difíceis, com maior consumo de tokens e custo. Por isso, um teste “3.6 high versus 3.7 high” responde uma pergunta diferente de “qual configuração entrega meu SLA com menor custo?”.

Matriz de migração: quando a melhora tende a pagar a troca

Workload	Decisão sugerida	Por quê	O que medir no piloto
Agentes de coding que abrem issue, editam arquivos, rodam testes e iteram	Migrar via canário	DeepSWE e Terminal-bench apontam ganho claro em tarefas longas e uso de terminal.	Taxa de resolução, loops por tarefa, retries, chamadas de ferramenta, tempo até testes verdes e custo por issue resolvida.
Agentes de negócio com várias ferramentas e etapas	Migrar via canário	O foco declarado do 3.7 e os ganhos em avaliações agentic favorecem execução multi-etapa.	Conclusão sem intervenção, chamadas redundantes, erros de ferramenta, custo e p95 de duração.
Geração de front-end a partir de mockups ou screenshots	Prioridade alta de teste	O Google destaca aderência a design e o Code Arena melhora.	Diferença visual, número de correções humanas, funcionalidade e bugs regressivos.
Análise de PDFs e documentos densos	Pilotar	GDP.pdf sobe de 22% para 34%, mas o ganho precisa sobreviver ao formato e ao domínio dos seus documentos.	Extração correta, citações internas, omissões, alucinações e tempo por documento.
Chat curto, classificação, reescrita e resumo simples	Sem urgência	Os maiores ganhos publicados se concentram em tarefas complexas; se o 3.6 já atende qualidade e SLA, a troca pode ter pouco retorno.	Qualidade em amostra real, latência de primeiro token e custo total por mil tarefas.
Workload de alto volume com teto rígido de custo	Decidir por custo por tarefa, não por token	A tarifa Standard atual é igual, mas thinking e comprimento da resposta podem mudar o consumo efetivo.	Tokens de input/output/thinking, retries, taxa de sucesso e custo por tarefa concluída.
Fluxos com formato rígido, ferramentas sensíveis ou golden tests	Pilotar antes de trocar o default	Mudança de modelo pode alterar sequência de tool calls, estilo e decisão de raciocínio mesmo quando a API é compatível.	Conformidade de schema, ordem de chamadas, taxa de erro e regressões nos golden tests.

O ponto de corte mais útil: custo por trabalho concluído

Se o seu sistema já está em 3.6 Flash, compare os modelos com o mesmo conjunto de tarefas reais e uma definição explícita de sucesso. Para agentes, “respondeu” é um critério fraco: o que importa é concluir o objetivo sem ficar preso em loop, sem chamar ferramenta desnecessária e sem exigir correção humana que anule a economia.

Uma avaliação de migração deve registrar pelo menos:

• qualidade final: passou ou falhou no critério de negócio, e quanto trabalho humano restou;
• confiabilidade: retries, loops, chamadas de ferramenta inválidas, schemas quebrados e falhas de execução;
• tempo: p50 e p95 de primeira resposta e de conclusão do fluxo inteiro;
• consumo: input, output e tokens de reasoning quando aplicável;
• custo real: dólares por tarefa concluída com sucesso, não apenas dólares por milhão de tokens.

Esse último número é o que pode inverter uma comparação. Um modelo que “pensa” mais pode gastar mais tokens, mas ainda ser mais barato se reduzir falhas e retrabalho. O contrário também é possível em tarefas simples, nas quais o ganho de inteligência não acrescenta valor mensurável.

A migração técnica tende a ser pequena para quem já está no 3.6, mas o comportamento precisa ser revalidado

A documentação de migração do Gemini 3.7 Flash orienta trocar o identificador do modelo para gemini-3.7-flash e revisar o contrato atual de reasoning, turnos e function calling. Parte das mudanças de compatibilidade citadas pelo Google — como a remoção de temperature, top_p e top_k — já valia no 3.6 Flash. Para integrações já atualizadas para o contrato recente do Gemini 3.x, isso reduz a quantidade de código novo, mas não elimina a necessidade de teste funcional.

O 3.7 usa thinking_level com os valores low, medium e high. O checklist também pede atenção a conversas multi-turn, prefilled model turns e respostas de function calling. Se sua aplicação usa a API generateContent, a documentação especifica que objetos FunctionResponse precisam incluir call_id e name.

Então, vale migrar do Gemini 3.6 Flash para o 3.7 Flash?

Para coding, agentes e automações multi-etapa, sim: os dados justificam colocar o 3.7 Flash no caminho de migração. Os maiores ganhos aparecem exatamente em tarefas nas quais uma falha custa mais do que alguns tokens extras: engenharia de software longa, terminal, workflows de negócio, web development e análise documental complexa. Como o preço Standard atual é igual ao do 3.6, não existe hoje uma penalidade de tarifa por token para testar o novo modelo.

Para chat simples, classificação, resumos curtos e workloads já estáveis, a resposta é “não necessariamente”. O 3.6 continua GA, não tem data de desligamento anunciada e compartilha a mesma promoção de preço. Se ele já cumpre qualidade, latência e custo, uma migração imediata pode gerar mais trabalho de regressão do que benefício.

A recomendação prática é trocar o default primeiro onde o 3.7 tem evidência forte de ganho, manter o 3.6 como referência durante o canário e só ampliar depois de comparar custo por tarefa concluída, taxa de sucesso e latência de ponta a ponta. Essa abordagem transforma benchmarks em uma decisão de produção, sem tratar o leaderboard como promessa.