O Gemini 3.7 Flash chegou em 13 de agosto de 2026, apenas três semanas depois do 3.6 Flash, com uma promessa específica: melhorar coding e fluxos agênticos complexos sem trocar a família de ferramentas nem ampliar a janela de contexto. A mudança relevante, portanto, não é “mais recursos de API”, mas maior qualidade de execução em tarefas como depuração, resolução de issues, geração de aplicações web e automações de várias etapas. Há ainda uma nuance de preço: o valor introdutório anunciado para o 3.7 também foi aplicado ao 3.6 Flash, de modo que, durante a promoção, os dois têm a mesma tarifa por token nas superfícies documentadas pelo Google.
Gemini 3.7 Flash vs. 3.6 Flash: o que mudou de fato
O 3.6 Flash foi lançado em 21 de julho de 2026 como um modelo de trabalho para agentes, com foco em eficiência de tokens, coding, conhecimento e tarefas multimodais. O 3.7 Flash mantém essa base, mas o Google o posiciona como seu Flash mais capaz para coding e agentes, com ganhos em software engineering, web development e execução de workflows.
| Área | Gemini 3.6 Flash | Gemini 3.7 Flash | Leitura prática |
|---|---|---|---|
| Coding e resolução de issues | Já havia melhorado precisão e reduzido loops em relação ao 3.5 Flash. | No DeepSWE v1.1, o Google reporta 65,3% contra 49,0% do 3.6. No FrontierCode 1.1 Main, 43,6% contra 34,4%. | O ganho interessa mais quando o custo de uma resposta errada é um novo ciclo de edição, teste ou ferramenta. |
| Web e interface | Bom desempenho geral em coding e tarefas multimodais. | O Google relata layouts mais funcionais, apps mais completos em menos prompts e Elo 1588 contra 1538 no WebDev Arena. | É um candidato mais forte para geração a partir de mocks, revisão visual e tarefas em que fidelidade de design reduz retrabalho. |
| Documentos densos | Voltado também a knowledge work e análise multimodal. | No benchmark GDP.pdf, o Google reporta 34,0% contra 22,0%. | Pode ajudar em agentes que precisam extrair, raciocinar e agir sobre PDFs complexos, mas o ganho precisa ser validado no tipo de documento real. |
| Automação de workflows | Projetado para execução agêntica e uso de ferramentas. | No AutomationBench, 30,4% contra 17,0%, além de maior disciplina em planejamento, instruções e tool calls segundo o Google. | O benefício esperado é menos supervisão, menos tentativas e maior taxa de conclusão de tarefas com várias etapas. |
| Contexto e ferramentas | 1.048.576 tokens de entrada, 65.536 de saída e suporte a ferramentas como function calling, code execution, computer use, search grounding e URL context. | 1M de contexto, 64k de saída e a mesma suíte de ferramentas integradas do 3.6. | A escolha entre os dois não deve ser feita esperando uma nova ferramenta exclusiva no 3.7. |
Os números acima são benchmarks e medições divulgadas pelo próprio Google. Eles mostram a direção do ganho, mas não garantem a mesma diferença em um repositório, agente, stack de ferramentas ou conjunto de prompts específico.
O que “melhor para coding” significa na prática
O salto do 3.7 Flash é mais relevante em tarefas nas quais o modelo precisa manter contexto técnico, editar código existente e fechar o ciclo de execução, não apenas gerar um snippet isolado. O Google destaca depuração, resolução de issues, maior acurácia na primeira tentativa e geração de código mais próximo de produção.
- Bugs com reprodução e testes: peça ao modelo para localizar a causa, propor o patch e executar ou interpretar a suíte de testes. A métrica útil é quantos casos chegam a uma solução válida sem intervenção humana.
- Refatorações e migrações: compare a quantidade de arquivos alterados sem necessidade, regressões e loops de correção. O 3.6 já foi lançado com foco em reduzir edições indesejadas; o 3.7 tenta avançar nesse ponto.
- Aplicações web a partir de referência visual: o 3.7 foi explicitamente ajustado para aderência a mocks, screenshots e design systems. O teste deve avaliar funcionalidade e paridade visual, não só se o código compila.
- Repositórios com várias ferramentas: quando o fluxo inclui busca, execução de código, leitura de arquivos e funções externas, uma melhora pequena por etapa pode ter efeito grande na taxa de conclusão final.
Para agentes, a principal mudança é a execução — não uma nova lista de ferramentas
A documentação do 3.7 Flash diz que ele usa a mesma suíte de ferramentas integradas do 3.6. O diferencial declarado está no comportamento: adaptar-se melhor a bloqueios, pedir esclarecimentos quando necessário, seguir instruções com mais fidelidade e investir mais esforço em planejamento de várias etapas e chamadas de ferramentas. Isso importa porque o custo de um agente não é apenas o preço de uma resposta; é a soma de tokens, tool calls, latência, retries e eventual intervenção humana.
Há também uma diferença de configuração de raciocínio que vale observar. O 3.7 Flash suporta os níveis low, medium e high, com medium como padrão. A documentação atual lista o 3.6 Flash com minimal, low, medium e high. Para um A/B justo, use primeiro um nível comum, como medium, e só depois teste extremos de latência ou qualidade.
O preço introdutório: metade do preço original não significa metade do 3.6 hoje
Quando o 3.6 Flash foi anunciado em 21 de julho, o preço informado era de US$ 1,50 por 1 milhão de tokens de entrada e US$ 7,50 por 1 milhão de tokens de saída. Em 13 de agosto, o 3.7 Flash foi lançado a US$ 0,75/1M de entrada e US$ 3,75/1M de saída, descrito como metade do custo original do 3.6.
Mas a documentação de migração atual acrescenta um detalhe decisivo: essa nova tarifa promocional também foi aplicada ao 3.6 Flash. Até 31 de dezembro de 2026, 3.7 e 3.6 aparecem com a mesma tarifa introdutória nas superfícies documentadas. A partir de 1º de janeiro de 2027, a tarifa padrão indicada é de US$ 1,50/1M de entrada e US$ 7,50/1M de saída.
Na prática, a frase “metade do preço do 3.6” compara o 3.7 com o preço original de lançamento do 3.6, não com uma diferença de tarifa atual entre os dois. Durante a promoção, o custo por token não é o desempate. O que interessa é custo por tarefa concluída.
Uma conta simples é: custo de tokens = (tokens de entrada ÷ 1.000.000 × tarifa de entrada) + (tokens de saída ÷ 1.000.000 × tarifa de saída). Para agentes, acrescente custos de ferramentas, infraestrutura e repetições. Se o 3.7 usar mais raciocínio em uma tentativa, mas reduzir retries e tool calls, ele pode sair mais barato por tarefa; se o workload for simples e o 3.6 já acertar de primeira, a vantagem pode desaparecer.
Quais workloads tendem a se beneficiar mais do 3.7 Flash
- Software engineering com feedback de execução: bugs, issues, testes, migrations e refactors em que é possível verificar objetivamente o resultado.
- Agentes de várias etapas: tarefas com planejamento, chamadas de funções, pesquisa, leitura de documentos e necessidade de recuperar-se de erros intermediários.
- Web development orientado a design: geração de UI a partir de screenshot, mock ou design system e auditoria de paridade entre implementação e referência.
- Workflows de documentos complexos: análise de relatórios, PDFs, tabelas e conteúdo multimodal que termina em uma ação ou decisão estruturada.
- Processos em que retries são caros: quando cada falha dispara novas execuções, ferramentas ou revisão humana, maior precisão de primeira passagem pode valer mais que pequenas diferenças de latência.
Quando manter o 3.6 Flash ainda faz sentido
O 3.6 Flash continua GA e sem data de desligamento anunciada. Se o seu sistema já atende às metas de qualidade, latência e custo, não há um argumento econômico automático para migrar apenas por causa da promoção, porque a tarifa introdutória foi igualada. Manter o 3.6 pode ser racional enquanto você mede o 3.7, especialmente em fluxos simples, de alto volume ou já muito ajustados.
Outro ponto é o nível minimal documentado para o 3.6 e ausente da lista atual do 3.7. Para workloads extremamente sensíveis a latência e com baixa exigência de raciocínio, isso merece um teste separado em vez de assumir que a geração mais nova será sempre a melhor opção.
Um conjunto de testes para escolher entre 3.7 e 3.6
Evite decidir por um único benchmark público. Use tarefas reais e faça um A/B controlado.
- Congele o ambiente: mesmo commit, mesmos arquivos, mesmas ferramentas, mesmas permissões e mesmo prompt-base.
- Use um nível de raciocínio comparável: comece por medium, que é comum aos dois modelos.
- Separe categorias: bug fixing, refactor, geração de feature, UI a partir de mock, workflow com ferramentas e análise de documento.
- Repita tarefas: modelos generativos variam entre execuções; uma única tentativa pode esconder regressões ou ganhos.
- Meça sucesso de ponta a ponta: teste aprovado, issue resolvida, interface funcional, workflow finalizado ou documento processado corretamente.
- Registre eficiência: tokens de entrada e saída, latência total, número de tool calls, retries, erros de função e intervenções humanas.
- Calcule custo por sucesso: divida o custo total das execuções pela quantidade de tarefas concluídas dentro do critério de qualidade.
Se o 3.7 aumentar a taxa de sucesso e reduzir loops suficientemente para compensar qualquer consumo adicional de raciocínio, a migração faz sentido. Se o 3.6 já resolve o workload com baixa variância, manter o modelo pode ser a escolha mais eficiente.
