Gemini 3.1 Pro Preview vs Customtools: qual você deve usar?

Os dois nomes do Gemini 3.1 Pro são IDs oficiais de modelos do Google. gemini-3.1-pro-preview é o modelo comum. gemini-3.1-pro-preview-customtools é uma variante projetada para aproveitar melhor as ferramentas personalizadas quando um agente também tem acesso a bash. O sufixo não significa “mais raciocínio”, e o modelo comum já oferece suporte à chamada de função.^[1]

Para programação em geral, análise de documentos e perguntas multimodais, o Preview comum é um ponto de partida razoável. Considere comparar o Customtools quando seu agente escolher repetidamente um comando de shell em vez da função personalizada que você pretendia usar. Essa recomendação segue a distinção documentada; este artigo não apresenta um novo benchmark A/B.

Os dois IDs de modelo do Gemini 3.1 Pro

Copie o identificador completo para sua configuração. Ambos os IDs contêm preview; Customtools é uma opção separada dentro dessa família de lançamento.

O Google lista os dois nomes juntos na página do modelo. Também alerta que a versão Customtools pode apresentar variação de qualidade em consultas que não se beneficiam desse fluxo de trabalho com ferramentas. Um sufixo diferente é, portanto, motivo para avaliar um comportamento específico, não evidência de uma melhoria generalizada.^[1]

A especificação compartilhada do modelo lista um limite de entrada de 1.048.576 tokens, um limite de saída de 65.536 tokens, entrada multimodal e saída de texto. Esses limites principais não dizem qual ferramenta um agente selecionará em uma conversa específica. Separe o identificador do modelo, as definições das ferramentas e o resultado da tarefa ao comparar respostas.

O que o Customtools muda

O Google descreve uma preferência por funções personalizadas como view_file e search_code quando bash também está disponível. Isso importa quando seu aplicativo já definiu ferramentas específicas com saídas e permissões previsíveis.^[1]

Considere um assistente de programação hipotético com três opções: uma função que lê um arquivo, outra que pesquisa símbolos no repositório e uma ferramenta geral de shell. A tarefa é localizar a definição de uma função. Tanto uma função de busca no repositório quanto um comando de shell poderiam ajudar. A pergunta útil é se o modelo escolhe a ferramenta que melhor corresponde ao fluxo de trabalho pretendido do seu aplicativo.

Esse é um cenário ilustrativo, não uma resposta capturada de nenhum dos modelos. O Customtools não garante uma chamada específica, não elimina a necessidade de declarar funções nem assume as verificações de permissão do seu aplicativo. Seu aplicativo continua decidindo se executa uma chamada e qual resultado retorna.

A distinção é mais relevante depois que você observa um problema de seleção de ferramentas. Se o modelo comum já escolhe a função pretendida e conclui a tarefa, trocar de variante acrescenta outra variável sem antes identificar uma melhoria a medir.

Customtools não é um nível de raciocínio

O Gemini 3.1 Pro tem níveis separados de raciocínio low, medium e high. O padrão nativo de generateContent é high; minimal não é compatível com este modelo. Essas são configurações de geração, não IDs alternativos de modelo.^[2]

Mudar de low para high pode alterar o orçamento de raciocínio usado em uma tarefa. Mudar o ID do modelo para Customtools visa o comportamento de seleção de ferramentas. Se você mudar os dois ao mesmo tempo, uma resposta diferente não dirá qual alteração teve efeito.

Para uma comparação útil, mantenha o mesmo prompt, as mesmas declarações de ferramentas, o histórico da conversa, o nível de raciocínio e o limite de saída. O Google também recomenda manter a temperatura em 1.0 no Gemini 3. Compare se o trabalho solicitado foi concluído, quais ferramentas foram chamadas, se os argumentos eram válidos e quanto uso a resposta informou. Essas são sugestões de avaliação, não vantagens medidas de nenhuma das variantes.

Você pode usar funções com o Preview comum

A especificação oficial do modelo comum lista a chamada de função como compatível. Você não precisa do sufixo Customtools para declarar uma função, receber uma chamada de função, executá-la no seu aplicativo e devolver o resultado.^[1]

Use o campo nativo tools[].functionDeclarations para a interface da função. Preserve as partes de conteúdo e as assinaturas de raciocínio retornadas ao continuar a conversa. Uma falha causada por assinatura ausente, esquema de argumentos inválido ou resposta de ferramenta montada incorretamente é um problema de protocolo; trocar o nome do modelo não comprova que ele foi corrigido.

A referência da API do Gemini 3.1 Pro lista os campos nativos e suas restrições. Comece com uma função pequena e um resultado que possa conferir antes de adicionar uma coleção inteira de ferramentas.

Escolha para o fluxo de trabalho que você realmente tem

Escolha primeiro o Preview comum quando o trabalho for principalmente geração de texto, explicação de código, extração de documentos ou análise multimodal. Ele também é um ponto de partida válido para um aplicativo que usa ferramentas. Defina como é um resultado bem-sucedido antes de avaliá-lo.

Compare o Customtools quando o aplicativo combinar bash com ferramentas personalizadas e houver um problema concreto de seleção para reproduzir. Mantenha um conjunto curto de casos representativos: um em que a função específica seja apropriada, outro que realmente exija o shell e outro em que nenhuma ferramenta deva ser chamada. Revise tanto a ação selecionada quanto o resultado final.

Não avalie uma variante apenas pela frequência com que ela chama sua ferramenta preferida. Uma chamada de função desnecessária continua sendo desnecessária. Um modelo útil deve selecionar uma ação apropriada, fornecer argumentos válidos, interpretar o resultado e responder à solicitação original.

A página de preços do Google agrupa os dois IDs na mesma tabela de preços do modelo. Isso não torna o raciocínio, as escolhas de nível de processamento ou o consumo de tokens intercambiáveis. Confira as tarifas atuais aplicáveis e examine o uso real ao comparar requisições.^[3]

Qual versão o SeedRouter conecta?

A página do Gemini 3.1 Pro usa gemini-3.1-pro-preview. A variante Customtools não está conectada por esta integração. A página oferece o Playground do modelo comum e os preços dos grupos em tempo real; a referência da API registra os limites atuais da verificação.

Use o ID exato do modelo comum no seu aplicativo. Mantenha as configurações de processamento explícitas para uma avaliação controlada e confira o resultado na sua própria tarefa antes de considerar uma configuração adequada para produção.

Perguntas frequentes

Os dois nomes de modelo do Gemini 3.1 Pro são oficiais?

Sim. O Google documenta tanto gemini-3.1-pro-preview quanto gemini-3.1-pro-preview-customtools na mesma página de modelo. O segundo é uma variante especializada, não uma grafia não oficial.

O Customtools substitui a chamada de função normal?

Não. A chamada de função normal já está disponível no Preview comum. O Customtools altera a preferência do modelo em um fluxo de trabalho que mistura ferramentas personalizadas e bash; seu aplicativo continua declarando e executando funções.

O Customtools é sempre melhor para programação?

O Google não faz essa afirmação geral. A distinção documentada diz respeito à seleção de ferramentas, e a página do modelo alerta sobre variação de qualidade fora do fluxo de trabalho pretendido. Compare o comportamento de que seu aplicativo de programação realmente precisa.

Fontes

Conferidas em 17 de outubro de 2026. A comparação acima se baseia na documentação, não em um benchmark de qualidade executado agora.

1. Google: especificação do modelo Gemini 3.1 Pro — IDs oficiais, limites de entrada/saída, chamada de função e a distinção do Customtools.
2. Google: guia nativo do Gemini 3 para desenvolvedores — níveis de raciocínio, configurações de requisições nativas e orientação sobre temperatura.
3. Google: preços da API Gemini — a tabela oficial de preços compartilhada pelos dois IDs de modelo.