Gemini 3.6 Flash : le réglage qui fait varier le coût jusqu'à 30x

Gemini 3.6 Flash facture les tokens de raisonnement en plus de la réponse. Leur nombre se règle à chaque requête. Pour une même tâche de rédaction de 120 mots, le réglage par défaut a coûté $0.03316, contre $0.00110 avec minimal, soit un écart de 30x pour deux résultats qu’un lecteur ne saurait distinguer. Ce réglage est le principal levier de coût du modèle, mais il présente un risque bien précis. Gemini 3.6 Flash est disponible publiquement depuis le 2026-07-21, au tarif de $1.50 par million de tokens en entrée et $7.50 par million en sortie, contre $9 en sortie pour 3.5 Flash. Il est sorti avec Gemini 3.5 Flash-Lite et une version 3.5 Flash Cyber optimisée pour la sécurité. Cet article mesure les deux modèles généralistes, 3.6 Flash et Flash-Lite.

TL;DR

• reasoning_effort: "minimal" réduit le coût par appel de 91 à 97 % par rapport au réglage par défaut, avec un écart de 30x sur une tâche de 120 mots. Ce réglage n’a eu aucun impact sur les tâches simples, les sorties structurées et les appels d’outils, mais a fait chuter la réussite en calcul multi-étapes de 3/3 à 0/3.
• L’affirmation de Google sur les « 17 % de tokens de sortie en moins » dépend de la charge : nos tâches fortement axées sur le raisonnement ont consommé 19 % de tokens en moins pour un coût inférieur de 32 %, tandis que notre suite agentique en a consommé 9 % de plus pour un coût inférieur de 6 %.
• La fenêtre de contexte de 1M est bien réelle : une information placée à 972K tokens a été retrouvée. Le prompt caching respecte exactement le seuil minimal de 4,096 tokens publié par Google. Les spécifications sont donc respectées, contrairement à certains modèles annoncés avec un contexte de « 1M » mais qui restent en deçà en pratique.

Toutes les mesures ci-dessous ont été effectuées le 2026-07-24 via la gateway Synthorai. Les prompts répétés ont été salés pour éviter les caches, et chaque chiffre repose sur les données brutes d’usage.

Combien coûte une tâche avec les réglages par défaut de Gemini 3.6 Flash ?

Le raisonnement représente l’essentiel de la facture en sortie, qu’il soit visible ou non. Avec l’effort par défaut, le modèle consomme bien plus de tokens pour raisonner que pour répondre. Ces tokens de raisonnement sont facturés au plein tarif de sortie, soit $7.50/M :

Le point à retenir est simple : une réponse factuelle de deux tokens s’accompagne tout de même de 69 tokens de raisonnement, et le paragraphe de 120 mots consomme 30x plus de tokens pour réfléchir que pour écrire. Les tokens de raisonnement sont détaillés dans completion_tokens_details.reasoning_tokens. Leur nombre est donc visible, mais jamais leur contenu. Gemini ne renvoie ni résumé ni trace du raisonnement. C’est le fonctionnement le plus fermé parmi ceux recensés dans notre étude sur l’anatomie de la consommation des tokens, où Kimi K3 fournit sa chaîne de raisonnement complète et GPT-5.6 un résumé. Voyons maintenant comment réduire cette dépense.

Que fait réellement le réglage de raisonnement ?

C’est un véritable levier de coût, avec un effet progressif. Pour la plupart des tâches, l’économie ne présente quasiment aucune contrepartie. Régler reasoning_effort, ou son équivalent natif thinking_config.thinking_level, sur minimal a ramené les tokens de raisonnement à zéro et réduit le coût de chaque tâche de 91 à 97 % :

Les valeurs acceptées sont minimal, low, medium (par défaut) et high. Lors de nos tests, chaque niveau augmentait progressivement le nombre de tokens de raisonnement : 0 avec minimal, environ 180 avec low, environ 530 avec medium et environ 650 avec high. Le niveau minimal empêche toutefois le modèle de raisonner, ce qui pose problème pour les calculs en plusieurs étapes. Contraint de répondre brièvement à un problème portant sur des crayons et des sacs, le modèle s’est trompé trois fois sur trois, avec des réponses erronées différentes plutôt qu’une erreur systématique. Pour la recherche d’information, la classification, la mise en forme et les questions en une seule étape, minimal a conservé la même précision tout en divisant la facture par plus de dix.

La règle pratique rejoint nos observations sur Kimi K3 : minimal est un choix par défaut raisonnable pour l’extraction, la recherche et la mise en forme, mais devient dangereux dès qu’une tâche exige des étapes intermédiaires. Configurez-le par route plutôt que globalement. Avant de l’utiliser en production sur une tâche demandant du raisonnement, validez sa précision sur vos propres données.

Deux usages très courants en production illustrent bien ce point : les sorties structurées et les appels de fonctions consomment des tokens de raisonnement avec le réglage par défaut, alors que minimal suffit dans les deux cas. Une extraction contrainte par un schéma (response_format avec un schéma JSON) a consommé 337 tokens de raisonnement par défaut et renvoyé un JSON valide. Avec minimal, elle n’en a consommé aucun, a toujours produit un JSON valide conforme au schéma et a coûté 9x moins cher. Même constat pour un appel de fonction : 74 tokens de raisonnement et un appel correct à get_weather(city) par défaut, contre zéro token de raisonnement et le même appel correct avec minimal, pour un coût divisé par 4. Ce sont des tâches en une seule étape, même si elles sont dites « structurées ». Le modèle n’a pas besoin de raisonner pour renseigner un champ explicitement demandé. Si votre trafic consiste surtout en extraction ou en routage d’outils, minimal apporte donc une économie presque sans contrepartie.

L’affirmation des « 17 % de tokens de sortie en moins » se vérifie-t-elle ?

Tout dépend de la charge, et l’écart est révélateur. Lors du lancement, Google a présenté 3.6 Flash comme consommant environ 17 % de tokens de sortie en moins que 3.5 Flash sur l’Artificial Analysis Index, et jusqu’à 65 % de moins sur certaines évaluations agentiques. Nous avons soumis les deux modèles à nos deux bancs de test et obtenu des tendances opposées :

Sur les tâches courtes demandant beaucoup de raisonnement, nos résultats dépassent même le chiffre annoncé : le volume total en sortie baisse de 19 %, contre 17 % selon Google. Cette baisse vient presque entièrement du raisonnement, pas de la réponse. Lors d’une nouvelle exécution appariée des deux modèles, la réponse visible n’a diminué que de 4 %, alors que les tokens de raisonnement ont baissé de 19 %. L’écart se concentre sur les tâches de calcul et de rédaction, pour lesquelles 3.6 atteint le même résultat avec moins de délibération. Voilà ce qui explique les résultats du benchmark : lorsque la charge sollicite fortement le budget de raisonnement, 3.6 est réellement plus efficace à réponse équivalente.

La tendance s’inverse sur le trafic agentique et multi-tour : dans l’ensemble de la suite, 3.6 a consommé environ 9 % de tokens de sortie en plus que 3.5. Le gain d’efficacité se situe pendant le raisonnement. Or les boucles agentiques y consacrent une part plus faible de leur budget, ce qui réduit les économies possibles. Les réponses légèrement plus longues de 3.6 finissent alors par l’emporter. Dans les deux cas, la facture baisse, mais pour des raisons différentes. Les tâches fortement axées sur le raisonnement profitent à la fois de la réduction du nombre de tokens et du passage de $9 à $7.50, soit une baisse de 32 %. Le trafic agentique bénéficie seulement de la baisse tarifaire, soit 6 %. Les « 17 % de tokens de sortie en moins » se vérifient donc lorsque le raisonnement domine la sortie, mais la tendance s’inverse dans le cas contraire. Mesurez votre propre répartition au lieu d’extrapoler le chiffre annoncé. Le réglage décrit dans la section précédente a par ailleurs bien plus d’impact que le changement de version.

La fenêtre de contexte de 1M est-elle réelle ?

Oui, et le dépassement déclenche une erreur explicite plutôt qu’une troncature silencieuse. Nous avons placé une information à retrouver au début de prompts de taille croissante. Le modèle l’a encore rappelée correctement avec 972K tokens en entrée. Au-delà de la limite, il a renvoyé une erreur explicite 400 input token count exceeds the maximum au lieu d’ignorer silencieusement une partie du contenu. Cette distinction compte, car tous les modèles du marché annoncés avec un contexte de « 1M » ne fournissent pas réellement la fenêtre promise. Pour reproduire ce test, utilisez un remplissage varié composé de phrases. Un prompt construit à partir d’un seul token répété a fait dégénérer la réponse en texte incohérent bien avant d’atteindre la limite de taille.

Le prompt caching est automatique et respecte la valeur essentielle de la documentation. Google indique un minimum de 4,096 tokens pour le cache de contexte des modèles Flash, et nos mesures correspondent exactement à ce seuil : les préfixes d’environ 2.1K tokens ou moins n’ont jamais été mis en cache, tandis que les hits ont commencé autour de 4.1K tokens. Après une phase de chauffe de 5 à 8 appels, les quelque 2.1K derniers tokens restaient hors cache à chaque hit. Les lectures depuis le cache coûtent $0.15/M en entrée, soit 10x moins que le tarif normal de $1.50. Contrairement à certains modèles mesurés dont les chiffres annoncés dépassent les capacités réelles de l’endpoint, le seuil de cache et la fenêtre de 1M de Gemini 3.6 Flash correspondent à la documentation. Le cache ne devient rentable que pour des préfixes réellement longs et stables. Les versions Flash ne prennent en charge que le cache automatique, ou implicite, et non l’API explicite de contenu mis en cache. Il n’est donc pas possible d’épingler manuellement un gros document pour le réutiliser sous le seuil minimal.

Quel est le positionnement de Gemini 3.5 Flash-Lite ?

Flash-Lite est la version au coût prévisible. Il ne consomme jamais de tokens de raisonnement de manière invisible : la facture suit donc directement la sortie visible. Sur le même problème mathématique en plusieurs étapes, Flash-Lite a coûté $0.00057, contre $0.00368 pour 3.6 Flash avec ses réglages par défaut, soit environ 6x moins. Il a en outre détaillé le calcul dans la réponse au lieu de le placer dans un champ de raisonnement masqué. À $0.30/M en entrée et $2.50/M en sortie, c’est le meilleur choix par défaut pour les tâches simples, volumineuses et sensibles à la latence. Passez à 3.6 Flash lorsqu’une tâche nécessite le raisonnement que son réglage permet d’ajouter. Le tokenizer reste identique sur les trois nouveaux modèles, mais aussi depuis Gemini 2.5 Flash : nous avons obtenu exactement les mêmes nombres de tokens en anglais, chinois, japonais, coréen et Python pour toutes les générations testées. Les budgets par langue définis pour 2.5 restent donc valables avec 3.6, sans nouvelle mesure de référence.

FAQ

Peut-on désactiver complètement le raisonnement sur Gemini 3.6 Flash ?

Lors de nos tests, reasoning_effort: "minimal" ou thinking_level: "minimal" a ramené les tokens de raisonnement à zéro. C’est le niveau le plus bas du réglage, dont les valeurs acceptées sont minimal, low, medium et high. Il n’existe pas d’état distinct « désactivé », et toute tentative de désactivation forcée du raisonnement est rejetée en amont. Minimal est donc le niveau plancher, et il suffit pour les tâches en une seule étape.

Pourquoi ma facture Gemini est-elle plus élevée que ne le laisse penser la réponse visible ?

Les tokens de raisonnement sont facturés au plein tarif de sortie, sans apparaître dans le texte renvoyé. Une réponse de deux tokens peut s’accompagner de dizaines, voire de milliers, de tokens de raisonnement facturés. Consultez completion_tokens_details.reasoning_tokens, ou calculez total_tokens − prompt − completion, pour connaître le coût réel de la sortie. Réduisez ensuite le réglage lorsque la tâche le permet.

Gemini 3.6 Flash ou Claude Haiku 4.5 ?

Les deux occupent le même segment de modèles rapides, avec des tarifs proches. Le choix dépend de la charge plutôt que d’un vainqueur absolu. Du point de vue des coûts, le réglage de raisonnement distingue 3.6 Flash : minimal le rend plus de dix fois moins cher sur les tâches simples, tandis que son réglage par défaut consomme des tokens de raisonnement que Haiku 4.5, à $1/$5, ne facture pas. Les benchmarks publiés donnent l’avantage à Haiku 4.5 pour les tâches de programmation complexes, et à 3.6 Flash pour les mathématiques et le prix brut des tokens. Choisissez selon la composition de votre trafic et mesurez les deux sur vos propres tâches avant de vous engager.

Gemini 3.6 Flash est-il moins cher que 3.5 Flash ?

Oui, sur toutes les charges que nous avons mesurées, même si l’écart dépend du type de trafic. Le tarif en sortie est passé de $9/M à $7.50/M. Sur les tâches courtes fortement axées sur le raisonnement, 3.6 consomme aussi moins de tokens de sortie, ce qui réduit le coût d’environ 32 %. Sur le trafic agentique, il consomme légèrement plus de tokens et l’économie provient seulement de la baisse tarifaire, soit environ 6 %. Dans tous les cas, il revient moins cher. Migrez, puis mesurez à nouveau votre propre répartition. Pour une décomposition du coût par token entre les différentes familles, consultez notre étude sur l’anatomie de la consommation des tokens.

Mesures effectuées le 2026-07-24 sur gemini-3.6-flash, gemini-3.5-flash et gemini-3.5-flash-lite via la gateway Synthorai. Les nombres de tokens de la matrice de tâches et de la suite agentique proviennent des données d’usage de chaque appel. Les résultats des niveaux d’effort sont issus d’une ablation salée sur cinq tâches (n=3 par cellule). Les tests de contexte et de cache reposent respectivement sur la recherche d’une information ciblée et sur des balayages de préfixes. Les scores de précision concernent les tâches ayant une seule réponse vérifiable. Les tarifs et le comportement peuvent évoluer ; vérifiez-les dans vos propres données d’usage.

← Retour au blog