Gemini 3.1 Pro Preview vs Customtools : quelle version choisir ?

Les deux noms de Gemini 3.1 Pro sont des ID de modèle officiels de Google. gemini-3.1-pro-preview est le modèle standard. gemini-3.1-pro-preview-customtools est une variante conçue pour mieux utiliser les outils personnalisés lorsqu’un agent a aussi accès à bash. Le suffixe ne signifie pas « davantage de raisonnement », et le modèle standard prend déjà en charge les appels de fonctions.^[1]

Pour le développement courant, l’analyse de documents et les questions multimodales, la version Preview standard est un point de départ raisonnable. Envisagez de comparer Customtools lorsque votre agent choisit régulièrement une commande shell plutôt que la fonction personnalisée prévue. Cette recommandation découle de la distinction documentée ; cet article ne présente pas de nouveau benchmark A/B.

Les deux ID de modèle Gemini 3.1 Pro

Copiez l’identifiant complet dans votre configuration. Les deux ID contiennent preview ; Customtools est un choix distinct dans cette famille de versions.

Google répertorie les deux noms sur la page du modèle. Il prévient aussi que la qualité de la version Customtools peut varier pour les requêtes qui ne bénéficient pas de ce workflow d’outils. Un suffixe différent justifie donc l’évaluation d’un comportement précis, sans prouver une amélioration générale.^[1]

La spécification commune du modèle indique une limite d’entrée de 1 048 576 tokens, une limite de sortie de 65 536 tokens, une entrée multimodale et une sortie textuelle. Ces limites principales n’indiquent pas quel outil un agent choisira dans une conversation donnée. Distinguez l’identifiant du modèle, les définitions d’outils et le résultat de la tâche lorsque vous comparez les résultats.

Ce que change Customtools

Google décrit une préférence pour les fonctions personnalisées telles que view_file et search_code lorsque bash est également disponible. Cela compte si votre application a déjà défini des outils ciblés aux sorties et permissions prévisibles.^[1]

Imaginez un assistant de programmation disposant de trois possibilités : une fonction qui lit un fichier, une autre qui recherche les symboles du dépôt et un outil shell général. La tâche consiste à trouver la définition d’une fonction. Une fonction de recherche dans le dépôt comme une commande shell pourraient aider. La question utile est de savoir si le modèle choisit l’outil le plus adapté au workflow prévu par votre application.

Il s’agit d’un scénario illustratif, pas d’une réponse enregistrée de l’un des modèles. Customtools ne garantit pas un appel précis, ne supprime pas la nécessité de déclarer les fonctions et ne prend pas en charge les contrôles de permissions de votre application. Celle-ci décide toujours d’exécuter ou non un appel et du résultat à renvoyer.

La distinction est surtout pertinente après l’observation d’un problème de sélection d’outil. Si le modèle standard choisit déjà la fonction prévue et accomplit la tâche, changer de variante ajoute une variable sans avoir d’abord identifié une amélioration à mesurer.

Customtools n’est pas un niveau de raisonnement

Gemini 3.1 Pro possède des niveaux de raisonnement distincts : low, medium et high. La valeur par défaut du generateContent natif est high ; minimal n’est pas pris en charge pour ce modèle. Ce sont des paramètres de génération, pas des ID de modèle alternatifs.^[2]

Passer de low à high peut modifier le budget de raisonnement utilisé pour une tâche. Changer l’ID du modèle pour Customtools cible le comportement de sélection d’outils. Si vous modifiez les deux à la fois, une réponse différente ne permet pas de savoir quel changement a compté.

Pour une comparaison utile, conservez le même prompt, les mêmes déclarations d’outils, le même historique, le même niveau de raisonnement et la même limite de sortie. Google recommande aussi de garder temperature à 1.0 pour Gemini 3. Comparez si le travail demandé a été accompli, quels outils ont été appelés, si les arguments étaient valides et quelle consommation la réponse a déclarée. Ce sont des suggestions d’évaluation, pas des avantages mesurés de l’une ou l’autre variante.

Les fonctions sont utilisables avec Preview standard

La spécification officielle du modèle standard indique que les appels de fonctions sont pris en charge. Vous n’avez pas besoin du suffixe Customtools pour déclarer une fonction, recevoir un appel, l’exécuter dans votre application et renvoyer le résultat.^[1]

Utilisez les tools[].functionDeclarations natifs pour l’interface de fonction. Conservez les parties de contenu et les signatures de pensée renvoyées lorsque vous poursuivez la conversation. Un échec dû à une signature manquante, un schéma d’arguments invalide ou une réponse d’outil mal assemblée est un problème de protocole ; changer le nom du modèle ne prouve pas qu’il est résolu.

La référence API Gemini 3.1 Pro répertorie les champs natifs et leurs contraintes. Commencez par une petite fonction et un résultat vérifiable avant d’ajouter toute une collection d’outils.

Choisir selon votre workflow réel

Choisissez d’abord Preview standard lorsque le travail consiste surtout à générer du texte, expliquer du code, extraire des documents ou effectuer une analyse multimodale. C’est aussi un point de départ valable pour une application qui utilise des outils. Définissez ce qu’est un résultat réussi avant de l’évaluer.

Comparez Customtools lorsque l’application combine bash et outils personnalisés et que vous avez un problème concret de sélection à reproduire. Gardez un petit ensemble de cas représentatifs : un où la fonction ciblée convient, un qui nécessite réellement le shell et un où aucun outil ne devrait être appelé. Examinez l’action sélectionnée comme le résultat final.

Ne jugez pas une variante uniquement à la fréquence d’appel de votre outil préféré. Un appel de fonction inutile reste inutile. Un modèle utile doit choisir une action appropriée, fournir des arguments valides, interpréter le résultat et répondre à la demande initiale.

La page tarifaire de Google regroupe les deux ID dans le même tableau de prix du modèle. Cela ne rend pas interchangeables le raisonnement, les choix de niveau de traitement ou la consommation de tokens. Consultez les tarifs actuels applicables et examinez la consommation réelle lorsque vous comparez des requêtes.^[3]

Quelle version SeedRouter intègre-t-il ?

La page Gemini 3.1 Pro utilise gemini-3.1-pro-preview. La variante Customtools n’est pas intégrée ici. La page fournit le Playground du modèle standard et les tarifs actuels des groupes ; la référence API consigne les limites actuelles des vérifications.

Utilisez l’ID exact du modèle standard dans votre application. Définissez explicitement les réglages de traitement pour une évaluation contrôlée et vérifiez le résultat sur votre propre tâche avant de considérer une configuration comme adaptée à la production.

Questions fréquentes

Les deux noms de modèle Gemini 3.1 Pro sont-ils officiels ?

Oui. Google documente gemini-3.1-pro-preview et gemini-3.1-pro-preview-customtools sur la même page de modèle. Le second est une variante spécialisée, pas une graphie non officielle.

Customtools remplace-t-il les appels de fonctions habituels ?

Non. Les appels de fonctions habituels sont déjà disponibles dans Preview standard. Customtools modifie la préférence du modèle dans un workflow mêlant outils personnalisés et bash ; votre application continue de déclarer et d’exécuter les fonctions.

Customtools est-il toujours meilleur pour le code ?

Google ne fait pas cette affirmation générale. La distinction documentée concerne la sélection d’outils, et sa page de modèle prévient que la qualité peut varier hors du workflow prévu. Comparez le comportement dont votre application de programmation a réellement besoin.

Sources

Vérifié le 17 octobre 2026. La comparaison ci-dessus repose sur la documentation, pas sur un nouveau benchmark de qualité.

1. Google : spécification du modèle Gemini 3.1 Pro — ID officiels, limites d’entrée/sortie, appels de fonctions et distinction Customtools.
2. Google : guide natif du développeur Gemini 3 — niveaux de raisonnement, paramètres des requêtes natives et recommandations pour temperature.
3. Google : tarifs de l’API Gemini — tableau tarifaire officiel commun aux deux ID de modèle.