Gemini 3.6 Flash : la molette de réflexion qui fait varier le coût par 30 (mesuré)

Gemini 3.6 Flash vous facture des tokens de réflexion en plus de la réponse, et leur nombre est une molette que vous réglez par requête. Sur la même tâche de rédaction de 120 mots, le réglage par défaut a coûté 0,03316 $ et le réglage minimal 0,00110 $, soit un facteur 30 pour un résultat qu’un lecteur ne saurait distinguer. C’est la décision de coût la plus importante sur ce modèle, et elle a un tranchant. Gemini 3.6 Flash est passé en disponibilité générale le 2026-07-21 à 1,50 $ par million de tokens d’entrée et 7,50 $ par million de sortie, contre 9 $ en sortie sur 3.5 Flash. Il est sorti en même temps que Gemini 3.5 Flash-Lite et un 3.5 Flash Cyber optimisé pour la sécurité ; cet article mesure les deux tiers 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 défaut (un facteur 30 sur une tâche de 120 mots), gratuit sur les tâches en une étape, à sortie structurée et à appel d’outils, mais casse les maths multi-étapes 3/3 → 0/3.
• Les « 17 % de tokens de sortie en moins » annoncés par Google dépendent de la charge : nos tâches à forte réflexion ont tourné 19 % plus léger (32 % moins cher), notre suite agent 9 % plus lourd (6 % moins cher).
• Le contexte de 1M est réel (une aiguille rappelée à 972K tokens) et le prompt cache respecte exactement le plancher de 4 096 tokens publié par Google, une correspondance nette avec les specs, contrairement à certains modèles « contexte 1M » qui restent en deçà de ce qu’ils annoncent.

Tout ce qui suit a été mesuré le 2026-07-24 via le gateway Synthorai, avec des prompts répétés salés pour déjouer les caches ; les enregistrements bruts d’usage justifient chaque chiffre.

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

Le raisonnement domine la facture de sortie, et il est facturé que vous le voyiez ou non. Au niveau d’effort par défaut, le modèle dépense bien plus de tokens à réfléchir qu’à répondre, et ces tokens de raisonnement sont facturés au tarif plein de 7,50 $/M en sortie :

Le schéma à retenir : une réponse factuelle de deux tokens a quand même entraîné 69 tokens de raisonnement, et le paragraphe de 120 mots a dépensé 30x plus de tokens à réfléchir qu’à écrire. Les tokens de raisonnement sont détaillés dans completion_tokens_details.reasoning_tokens, donc vous voyez le décompte, mais jamais le contenu. Gemini ne renvoie aucun résumé ni aucune trace de sa réflexion, l’extrémité la plus fermée du spectre que nous avons cartographié dans notre étude anatomie de l’usage des tokens, où Kimi K3 renvoie l’intégralité de sa chaîne de raisonnement et GPT-5.6 un résumé. La section suivante porte sur la réduction de cette dépense.

À quoi sert vraiment le curseur de réflexion ?

C’est un véritable levier de coût monotone, et sur la plupart des types de tâches, il rapporte quasiment sans contrepartie. En réglant reasoning_effort (ou le natif thinking_config.thinking_level) sur minimal, on a fait tomber les reasoning tokens à zéro et réduit le coût de 91 à 97 % par tâche :

Le curseur est bien réel et accepte les valeurs minimal, low, medium (la valeur par défaut) et high ; chaque cran a fait grimper la quantité de réflexion de façon monotone dans nos tests (minimal 0 token, low ~180, medium ~530, high ~650). La seule chose que minimal ne peut pas faire, c’est réfléchir, et l’arithmétique multi-étapes en a besoin : contraint de répondre de façon laconique au problème des crayons et des sacs, le modèle s’est trompé les trois fois, avec des réponses erronées dispersées plutôt qu’une erreur systématique unique. Sur la recherche d’information, la classification, le formatage et les questions à une seule étape, minimal a maintenu la précision et divisé la facture par dix.

La règle pratique reflète ce qu’on a constaté sur Kimi K3 : minimal est un choix par défaut défendable pour l’extraction, la recherche et le formatage, et un piège pour tout ce qui exige des étapes intermédiaires. Réglez-le par route, pas globalement, et vérifiez la précision sur vos propres tâches avant de l’appliquer à une tâche à forte composante de raisonnement.

Deux cas d’usage à fort volume en production le démontrent concrètement : la sortie structurée et le function calling consomment tous deux de la réflexion par défaut, et tous deux peuvent tourner sans risque en minimal. Une extraction contrainte par un schéma (response_format avec un schéma JSON) a facturé 337 reasoning tokens par défaut et renvoyé du JSON valide ; en minimal, elle n’a facturé aucun reasoning token, a quand même renvoyé un JSON valide et conforme au schéma, pour 9x moins cher. Un function call s’est comporté de la même manière : 74 reasoning tokens et un appel get_weather(city) correct par défaut, contre zéro reasoning token et le même appel correct en minimal, 4x moins cher. Ce sont des tâches à une seule étape déguisées en « structuré », et le modèle n’a pas besoin de réfléchir pour remplir un champ qu’on lui a indiqué de remplir. Donc si votre trafic est de l’extraction ou du routage d’outils, minimal rapporte quasiment sans contrepartie.

Est-ce que le « 17 % de tokens de sortie en moins » tient la route ?

Ça dépend de la charge de travail, et la ventilation est parlante. Au lancement, Google présentait 3.6 Flash comme dépensant environ 17 % de tokens de sortie en moins que 3.5 Flash sur l’Artificial Analysis Index (jusqu’à 65 % sur certains évals agentiques individuels). Nous avons fait tourner les deux modèles sur deux de nos propres bancs d’essai et obtenu des signes opposés :

Sur les tâches courtes axées raisonnement, non seulement l’affirmation se reproduit, mais elle dépasse le chiffre annoncé : la sortie totale chute de 19 %, proche des 17 % de Google, et cette baisse vient presque entièrement du thinking, pas de la réponse. En séparant les tokens de sortie lors d’une reprise appariée des deux modèles, la réponse visible ne diminue que de 4 % tandis que le raisonnement chute de 19 %, concentré sur les tâches de maths et de rédaction où 3.6 arrive au même résultat avec moins de délibération. Voilà le mécanisme derrière le benchmark : sur du travail qui s’appuie sur le budget de thinking, 3.6 est réellement plus efficace pour une même réponse.

Sur le trafic agentique multi-tours, le signe s’inverse : 3.6 a dépensé environ 9 % de sortie en plus que 3.5 sur l’ensemble de la suite. Le gain d’efficacité se situe dans la phase de raisonnement, et les boucles d’agent y consacrent proportionnellement une part plus faible de leur budget ; il y a donc moins à économiser, et les tours légèrement plus longs de 3.6 l’emportent. Dans les deux cas, la facture baisse, parce que les deux effets se combinent différemment : les tâches axées raisonnement économisent à la fois sur les tokens et sur la baisse de tarif de 9 $ → 7,50 $ (−32 %), tandis que le trafic agentique n’économise que sur le prix (−6 %). Le résumé honnête : « 17 % de tokens de sortie en moins » est réel là où le thinking domine la sortie, et s’inverse là où ce n’est pas le cas. Mesurez donc votre propre mix plutôt que de vous fier au chiffre annoncé, et rappelez-vous que le réglage de la section précédente pèse bien plus lourd que le changement de version.

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

Oui, et elle échoue de façon bruyante plutôt que silencieuse. Nous avons placé une aiguille de recall en tête de prompts de taille croissante : elle était encore correctement retrouvée à 972K tokens d’entrée, et un prompt dépassant la limite renvoyait un 400 input token count exceeds the maximum propre, sans écarter de contenu en silence. Ça mérite d’être dit, car tous les modèles « contexte 1M » du marché ne servent pas réellement la fenêtre qu’ils annoncent. Une remarque de test pour ceux qui reproduisent l’expérience : remplissez avec du filler varié en forme de phrases, car un prompt construit à partir d’un seul token répété a poussé le modèle vers un charabia dégénéré bien avant la limite de taille.

Le prompt caching est automatique et respecte la spec sur le chiffre qui compte. Google documente un minimum de 4 096 tokens pour le context caching sur les modèles Flash, et notre balayage est tombé exactement là : les préfixes à environ 2,1K ou moins ne se mettaient jamais en cache, les hits commençaient autour de 4,1K tokens, et chaque hit laissait à peu près les derniers 2,1K non mis en cache, après un préchauffage de 5 à 8 appels. L’entrée en cache se lit à 0,15 $/M, une remise de 10x par rapport au tarif frais de 1,50 $. Ça mérite d’être dit clairement parce que c’est le cas rassurant : contrairement à certains modèles que nous avons mesurés, dont les chiffres annoncés surestiment ce que l’endpoint livre réellement, le plancher de cache de Gemini 3.6 Flash et sa fenêtre de 1M font tous deux ce que la doc dit. Le caching ne rentabilise toujours que des préfixes vraiment longs et stables, et notez que les paliers Flash ne prennent en charge que le caching automatique (implicite), pas l’API de cached-content explicite ; vous ne pouvez donc pas épingler manuellement un gros document pour le réutiliser sous le plancher.

Où se situe Gemini 3.5 Flash-Lite ?

Flash-Lite, c’est le palier au coût prévisible. Il ne dépense jamais de reasoning tokens en douce, donc sa facture suit à l’unité près la sortie visible. Sur le même problème de maths en plusieurs étapes, Flash-Lite a facturé 0,00057 $ contre 0,00368 $ pour 3.6 Flash en mode par défaut, soit environ 6x moins cher, et il a déroulé la réponse à découvert plutôt que dans un champ de raisonnement caché. À 0,30 $/M en entrée et 2,50 $/M en sortie, c’est le bon choix par défaut pour du travail à fort volume, sensible à la latence et en une seule étape ; passez à 3.6 Flash quand une tâche a besoin du raisonnement que la molette peut réinjecter. Le tokenizer est inchangé, pas seulement sur les trois nouveaux modèles mais jusqu’à Gemini 2.5 Flash : mêmes décomptes de tokens en anglais, chinois, japonais, coréen et Python sur toutes les générations vérifiées. Les budgets par langue calés sur la 2.5 se reportent donc sur la 3.6 sans devoir refaire le calibrage.

FAQ

Peut-on couper complètement le raisonnement sur Gemini 3.6 Flash ?

reasoning_effort: "minimal" (ou thinking_level: "minimal") a ramené les reasoning tokens à zéro dans nos tests et constitue le plancher de la molette ; les paliers acceptés sont minimal, low, medium et high. Il n’y a pas d’état « désactivé » distinct, et toute tentative de forcer l’arrêt du raisonnement est rejetée en amont. Minimal est donc le plus bas possible, et pour des tâches en une seule étape c’est bien assez bas.

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

Parce que les reasoning tokens sont facturés au plein tarif de sortie et ne font pas partie du texte que vous récupérez. Une réponse de deux tokens peut porter de quelques dizaines à plusieurs milliers de reasoning tokens facturés ; lisez completion_tokens_details.reasoning_tokens (ou recalculez total_tokens − prompt − completion) pour voir le vrai coût de sortie, et baissez la molette là où la tâche le permet.

Gemini 3.6 Flash ou Claude Haiku 4.5 ?

Ils occupent le même créneau de palier rapide à des prix voisins, et le partage se fait par charge de travail, pas par un vainqueur unique. Côté coût, c’est la molette de réflexion de 3.6 Flash qui fait la différence : minimal le rend un ordre de grandeur moins cher sur du trafic en une seule étape, tandis que son mode par défaut dépense du raisonnement que Haiku 4.5, à 1 $/5 $, ne dépense pas. Les benchmarks publiés donnent l’avantage à Haiku 4.5 sur la profondeur en code, et à 3.6 Flash sur les maths et le prix brut du token ; 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 mesurées, même si l’écart dépend de la forme du travail. La sortie est passée de 9 $/M à 7,50 $/M, et sur les tâches courtes à fort raisonnement, la 3.6 a aussi dépensé moins de tokens de sortie, d’où une baisse de coût d’environ 32 % ; sur le trafic d’agents, elle a dépensé un peu plus de tokens et l’économie vient uniquement de la baisse de tarif, environ 6 %. Dans les deux cas c’est moins cher ; migrez et mesurez à nouveau sur votre propre mix. Pour la décomposition du coût par token entre familles de modèles, voyez notre étude sur l’anatomie de l’usage des tokens.

Mesuré le 2026-07-24 sur gemini-3.6-flash, gemini-3.5-flash et gemini-3.5-flash-lite via le gateway Synthorai ; décomptes de tokens de la matrice de tâches et de la suite d’agents issus des enregistrements d’usage par appel, résultats de la molette d’effort issus d’une ablation salée de cinq tâches (n=3 par cellule), sondes de contexte et de cache issues de tests needle-recall et de balayages de préfixes. Les taux de réussite portent sur des tâches à réponse unique vérifiable. Les prix et les comportements peuvent changer ; vérifiez sur vos propres enregistrements d’usage.

← Retour au blog