Gemini 3.8 Flash : Niveaux de réflexion Faible, Moyen, Élevé

Gemini 3.8 Flash est livré avec trois niveaux de réflexion : low, medium et high. Ce réglage contrôle la quantité de raisonnement interne effectuée par le modèle avant qu'il ne réponde, et sur ce modèle, il impacte trois métriques à la fois : la latence, les jetons de sortie et votre facture. Google a conçu 3.8 Flash pour « travailler plus dur » sur les tâches complexes, de sorte que le niveau que vous choisissez est plus important que sur 3.7 Flash. Si vous découvrez le modèle, l'aperçu de Gemini 3.8 Flash couvre son lancement. Ce guide ne concerne que le cadran.

Deux détails surprennent les équipes dès la première heure. Le niveau par défaut sur 3.8 Flash est medium, et non high (Gemini 3 Pro est par défaut à high, d'où la confusion). De plus, minimal, que les configurations écrites pour Gemini 3.7 Flash envoient toujours, n'est plus accepté : la requête échoue à la validation avant qu'un seul jeton ne soit généré. Google documente ces deux points sur la page Nouveautés de Gemini 3.8 Flash.

Ci-dessous : ce que fait chaque niveau, son coût par tâche, comment le définir dans les deux formes d'API, une stratégie par route, et un test reproductible qui montre la différence de jetons et de latence avant le déploiement.

Niveaux de réflexion en un coup d'œil

Niveau	Recommandations de Google	Coût par tâche (AA)	Temps par tâche (AA)	À utiliser lorsque
`low`	Minimise la latence et le coût ; suivi d'instructions simples, chat, routes à haut débit	0,24 $	0,8 min	la latence côté utilisateur est importante ; recherche de transcription ; classification
`medium` (par défaut)	Le niveau par défaut pour le code complexe et le travail agentique	0,41 $	non publié dans le texte	la plupart des routes ; questions-réponses vidéo générales
`high`	Profondeur de raisonnement maximale pour les problèmes multi-étapes les plus difficiles	0,58 $	2,5 min	QA visuelle dense ; vidéo de plus de 60 minutes ; étapes de planification qui conditionnent tout le reste
`minimal`	Non pris en charge sur 3.8 Flash	n/a	n/a	jamais ; le mapper à `low`

Les colonnes de coût et de temps sont des moyennes d'Artificial Analysis obtenues en exécutant leur Intelligence Index à chaque niveau, aux prix d'introduction de Google par jeton. Ce sont des chiffres indépendants, et non ceux de Google, et ils mesurent une charge de travail de référence, pas vos propres prompts. Utilisez-les pour les ratios, puis mesurez vos propres routes.

Ce que fait chaque niveau

Chaque réponse de 3.8 Flash peut inclure des jetons de réflexion : le raisonnement que le modèle génère avant la réponse visible. Vous les payez comme jetons de sortie (3,75 $ par million au taux d'introduction jusqu'au 31/12/2026, 7,50 $ à partir du 01/01/2027), et l'API les signale séparément sous la forme usageMetadata.thoughtsTokenCount. Le niveau de réflexion indique au modèle la quantité de raisonnement à effectuer.

low garde la réflexion courte. Le premier jeton arrive le plus rapidement et la facture de sortie reste faible. Google le positionne pour les tâches sensibles à la latence : suivi d'instructions simples, chat et endpoints à haut débit.
medium est le point d'équilibre et le niveau par défaut. Google le désigne comme le réglage pour le code complexe et les tâches agentiques, ce qui représente la majeure partie des utilisations d'un modèle de classe Flash.
high indique au modèle de raisonner aussi profondément que possible. Google le réserve pour les problèmes multi-étapes les plus difficiles.

Ce qui rend cela différent sur 3.8 Flash est le nouveau comportement par défaut du modèle. Sur les tâches complexes, il « exécute des étapes de raisonnement supplémentaires et appelle des outils de manière itérative » et « vérifie son travail en cours de route ». Google affirme clairement qu'il « peut utiliser plus de jetons sur les tâches plus longues et complexes, par conception » et que « le modèle pourrait utiliser plus de jetons pour maximiser les performances, en particulier à des niveaux d'effort plus élevés ». Le niveau de réflexion est le régulateur de ce comportement. Le réduire est la première suggestion de Google lorsque l'utilisation de jetons augmente ; la seconde est de rester sur 3.7 Flash, qui reste entièrement pris en charge.

Une contrainte à intégrer : thinking_level est une énumération, pas un budget. L'entier thinking_budget des modèles précédents a disparu sur Gemini 3, vous ne pouvez donc pas demander « au maximum 2 000 jetons de réflexion ». Vous choisissez un niveau et vous vérifiez ensuite ce qu'il coûte sur vos prompts, c'est pourquoi le test à la fin de ce guide est important.

Le niveau par défaut est medium, pas high

Omettez le champ et 3.8 Flash s'exécute en medium. Cela concerne deux groupes.

Les équipes qui ont prototypé sur Gemini 3 Pro s'attendent à high par défaut et obtiennent des réponses de profondeur moyenne sans s'en rendre compte. Les équipes qui ont supprimé thinking_budget lors d'une mise à niveau de 3.7 Flash et ne l'ont pas remplacé par un niveau se retrouvent partout en medium, y compris sur les routes de chat qui devraient être en low.

La solution pour les deux est la même : définissez thinking_level explicitement sur chaque requête, par route, dans la configuration, et non dans le code. Les valeurs par défaut sont celles que Google peut modifier ; votre profil de coût ne devrait pas changer lorsqu'ils le font.

Pourquoi minimal a disparu et comment corriger l'erreur

minimal fonctionnait sur Gemini 3.7 Flash. Sur 3.8 Flash, il ne fait pas partie des niveaux pris en charge, et la page du modèle ne répertorie que les niveaux de réflexion low, medium et high. Si vous l'envoyez via REST, la requête est rejetée avant l'exécution du modèle avec un 400 INVALID_ARGUMENT et le message « Thinking level MINIMAL is not supported for this model. Please retry with other thinking level. » (vérifié lors d'un appel en direct le 3 septembre 2026). Les SDK enveloppent cela dans leur propre classe d'exception, donc faites correspondre le statut 400 ou le code INVALID_ARGUMENT, et non la chaîne de message.

Avant :

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "minimal" }
}

Après :

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "low" }
}

Le guide de migration de Google est un mappage direct : minimal devient low. Deux tentations à éviter pendant que vous êtes dans cette configuration. Ne cherchez pas thinking_budget pour obtenir un plancher plus petit ; il n'est pas pris en charge sur les modèles Gemini 3. Et ne diminuez pas la temperature pour « calmer le modèle » ; Google dit de la laisser à la valeur par défaut de 1.0 sur tous les modèles Gemini 3 car la baisser peut entraîner des boucles ou une dégradation de la sortie. La liste de contrôle complète, y compris les signatures de pensée et l'exigence call_id sur les réponses de fonction, se trouve dans le guide de migration de 3.7 vers 3.8 Flash.

Étant donné que l'erreur se déclenche au moment de la validation, une requête de test planifiée à chaque niveau détecte gratuitement une régression de la configuration vers minimal.

Coût de chaque niveau par tâche

La tarification par jeton ne change pas avec le niveau. La page de tarification de Google indique que chaque appel 3.8 Flash coûte 0,75 $ en entrée et 3,75 $ en sortie par million de jetons au taux d'introduction, doublant à 1,50 $ et 7,50 $ le 01/01/2027. L'écart entre les niveaux est purement lié au nombre de jetons, c'est ce qu'Artificial Analysis a mesuré.

Modèle et niveau	Coût par tâche	Temps par tâche
Gemini 3.8 Flash `low`	0,24 $	0,8 min
Gemini 3.8 Flash `medium`	0,41 $	non publié dans le texte
Gemini 3.8 Flash `high`	0,58 $	2,5 min
Gemini 3.7 Flash `high`	0,40 $	2,2 min

Source : Artificial Analysis, exécutions de l'Intelligence Index aux prix d'introduction. Trois ratios ressortent du tableau.

low s'exécute à environ 41% du coût de high et environ un tiers de son temps réel. C'est le plus grand levier que vous ayez sur ce modèle.

medium sur 3.8 Flash coûte environ ce que high coûtait sur 3.7 Flash (0,41 $ contre 0,40 $). Si vous étiez satisfait de 3.7 Flash en high, 3.8 Flash en medium est la ligne budgétaire équivalente.

high sur 3.8 Flash coûte 45 % de plus par tâche que high sur 3.7 Flash, avec des prix par jeton identiques, car le modèle émet environ 30 % de jetons de sortie en plus (48k en moyenne par tâche d'index). C'est la conception « travaille plus dur » qui se manifeste sur la facture. Que les jetons supplémentaires soient rentables dépend de la charge de travail ; la comparaison 3.8 Flash vs 3.7 Flash explique où les gains de qualité ont été réalisés.

Une mise en garde sur la qualité : le score de 59 de l'Intelligence Index d'AA pour 3.8 Flash est basé sur une exécution en high. Ils n'ont pas publié les scores d'index pour medium ou low dans le texte, ne supposez donc pas que la courbe de qualité est linéaire avec le coût. Testez vos propres évaluations à chaque niveau avant de réduire un chemin. Pour l'exemple détaillé de 1 000 tâches par jour à chaque niveau et le palier de prix du 31 décembre, consultez la tarification de Gemini 3.8 Flash.

Définir thinking_level dans l'API Interactions

L'API Interactions est la principale interface de Google pour Gemini 3.x. Le niveau se trouve dans generation_config sous forme de chaîne en snake_case :

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"gemini-3.8-flash","input":"Explain HTTP caching in 3 sentences.","generation_config":{"thinking_level":"low"}}'

En Python :

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Explain HTTP caching in 3 sentences.",
    generation_config={"thinking_level": "low"},
)
print(interaction.output_text)

C'est un champ au niveau de la requête, donc définissez-le sur chaque appel, y compris les tours de suivi qui transmettent previous_interaction_id. La réponse est renvoyée sous forme de liste d'étapes d'exécution (réflexions, appels d'outils) se terminant par model_output, et le SDK expose le texte final sous output_text. Pour un aperçu complet du premier appel, y compris l'état multi-tours et le streaming, consultez comment utiliser l'API Gemini 3.8 Flash.

Le définir dans l'ancienne méthode generateContent

La plupart du code Gemini existant appelle toujours generateContent. Google le qualifie de legacy mais affirme qu'il reste entièrement pris en charge sans date de fin de vie, il n'y a donc pas d'urgence. Le champ est imbriqué un niveau plus profond et en camelCase :

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" -H 'Content-Type: application/json' -X POST \
  -d '{"contents":[{"parts":[{"text":"Explain HTTP caching in 3 sentences."}]}],
       "generationConfig":{"thinkingConfig":{"thinkingLevel":"low","includeThoughts":true}}}'

En Python :

from google.genai import types

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Explain HTTP caching in 3 sentences.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)
print(response.usage_metadata.thoughts_token_count)

includeThoughts: true ajoute des résumés de réflexion à la réponse sous forme de parties marquées thought: true : utile lors du calibrage d'un niveau, du bruit une fois terminé. Le nombre qui vous intéresse est usageMetadata.thoughtsTokenCount, le compte exact facturé en sortie et le champ que vos tests devraient surveiller.

Une stratégie par route

Considérez le niveau comme une décision de routage, et non comme un réglage global. Une répartition réalisable :

Chat, autocomplétion et tout ce qu'une personne attend : low. C'est là que réside la latence du premier jeton.
Classification, extraction et recherche de transcription : low, avec votre propre évaluation effectuée une fois pour confirmer la précision. L'exemple vidéo de Google place la recherche de transcription à low.
Agents de codage et boucles d'outils : medium, le niveau par défaut. Faites passer une seule étape de planification à high si sa sortie conditionne toutes les étapes ultérieures, puis revenez en arrière. Sur 3.8 Flash, les boucles d'outils exécutent déjà plus de tours par conception, donc high sur une boucle entière s'accumule rapidement.
Workflows gourmands en documents et à long terme : high, et faites-les passer par l'API Batch avec une réduction de 50 % lorsqu'ils ne sont pas interactifs.
Vidéo : La documentation de Google donne trois exemples. high pour les QA visuelles denses ou les vidéos de plus de 60 minutes, medium pour les questions-réponses vidéo générales, low pour la recherche dans une transcription.

Si low sur 3.8 Flash est toujours un modèle trop lourd pour une route, la gamme Flash-Lite existe pour cette tâche ; notre guide Gemini 3.1 Flash-Lite précédent couvre le compromis, et Gemini 3.5 Flash-Lite est l'entrée actuelle à 0,30 $ en entrée et 2,50 $ en sortie.

Gardez le niveau dans la configuration par route et gemini-3.7-flash derrière un flag. Si le nombre de jetons d'une route augmente après la mise à niveau, vous pouvez réduire le niveau ou le modèle sans déploiement.

Tester les trois niveaux côte à côte dans Apidog

La lecture du tableau d'AA vous donne les ratios. Seuls vos prompts vous donnent les chiffres. Voici un scénario de test dans Apidog qui envoie un prompt "golden" à chaque niveau et vérifie ce qui a été renvoyé. Il fonctionne avec les deux formes d'API ; l'endpoint legacy est montré car usageMetadata y est un champ de premier niveau.

Stockez la clé comme variable d'environnement. Créez GEMINI_API_KEY dans un environnement Apidog et référencez-la comme {{GEMINI_API_KEY}} dans l'en-tête x-goog-api-key. Ajoutez une deuxième variable, THINKING_LEVEL, afin qu'une seule requête sauvegardée serve les trois étapes.
Enregistrez une requête. Faites une requête POST vers /v1beta/models/gemini-3.8-flash:generateContent avec votre prompt "golden" et "thinkingConfig": {"thinkingLevel": "{{THINKING_LEVEL}}"}.
Construisez un scénario de test en trois étapes. Importez la même requête trois fois et remplacez THINKING_LEVEL par low, medium et high à chaque étape.
Vérifiez les champs qui varient. À chaque étape : le statut est 200 et usageMetadata.thoughtsTokenCount existe. À l'étape low, assurez-vous que thoughtsTokenCount et le temps de réponse restent sous le plafond que la route peut tolérer (définissez la base de référence après votre première exécution). Un script de post-traitement peut stocker le compte de chaque étape dans une variable afin que l'étape high puisse affirmer qu'elle a raisonné au moins autant que low. Si cet ordre est inversé, le modèle ou la valeur par défaut a changé sans votre intervention.
Ajoutez une étape de garde. Envoyez thinkingLevel: "minimal" et assurez-vous que la réponse n'est pas un 200. Lorsque vous échangerez ultérieurement les ID de modèle, cette étape vous indiquera si le nouveau modèle le rejette toujours.
Planifiez-le. Exécutez le scénario quotidiennement afin qu'une régression de la configuration ou un changement de comportement silencieux apparaisse comme une exécution rouge, et non comme une facture surprise. Les mécanismes sont décrits dans comment planifier des tests d'API dans Apidog.

Pour les réponses en streaming, le même scénario s'applique avec le rendu SSE ; comment tester les API LLM qui diffusent en streaming via SSE couvre la configuration. Téléchargez Apidog pour suivre ; le plan gratuit couvre tout ce scénario.

FAQ

Le niveau de réflexion modifie-t-il le prix par jeton ?

Non. L'entrée est de 0,75 $ et la sortie de 3,75 $ par million de jetons sur 3.8 Flash au taux d'introduction, quel que soit le niveau. Le niveau modifie le nombre de jetons de sortie que le modèle génère en tant que réflexion, et ceux-ci sont facturés au prix de sortie. La répartition des prix couvre la mise en cache, le traitement par lots et l'augmentation du 1er janvier.

Puis-je définir un budget exact de jetons de réflexion à la place ?

Pas sur les modèles Gemini 3. thinking_budget a été remplacé par l'énumération thinking_level, et 3.8 Flash n'accepte que low, medium et high. Si vous avez besoin d'un plafond, appliquez-le dans les tests et les alertes plutôt que dans la requête.

Quel niveau utilise le score de 59 d'Artificial Analysis ?

high. AA a exécuté l'Intelligence Index à high pour le score principal et a également publié le coût et le temps pour low et medium, mais pas les scores d'index à ces niveaux. Considérez les niveaux inférieurs comme non testés sur ce benchmark jusqu'à ce que vous exécutiez vos propres évaluations.

Dois-je baisser la température pour réduire la réflexion ?

Non. La recommandation de Google pour tous les modèles Gemini 3 est de maintenir la temperature à sa valeur par défaut de 1.0. La baisser peut entraîner des boucles ou une dégradation de la sortie. Utilisez thinking_level pour contrôler la profondeur du raisonnement.

Que faire si même le niveau low est trop lent ou trop cher ?

Restez sur Gemini 3.7 Flash, que Google déclare entièrement pris en charge sans date de dépréciation, ou déplacez la route vers un modèle Flash-Lite. La comparaison 3.8 vs 3.7 Flash montre où les jetons supplémentaires apportent une qualité mesurable et où ils ne le font pas.

Choisissez le niveau par route, puis mesurez-le

Trois niveaux, une énumération et un modèle qui raisonne plus que son prédécesseur par défaut. Définissez thinking_level explicitement sur chaque route, mappez tout minimal restant à low, et surveillez usageMetadata.thoughtsTokenCount pour voir où chaque niveau se situe. Les chiffres par tâche d'AA (0,24 $, 0,41 $, 0,58 $) vous donnent la forme de la courbe ; un scénario en trois étapes dans Apidog vous donnera vos propres chiffres avant que le changement de prix du 31 décembre ne les rende deux fois plus importants.