Gemini 3.7 Flash : tâches facturées 2,5 à 8x moins que 3.6

À tâche identique, Gemini 3.7 Flash coûte 2,5 à 8x moins cher que Gemini 3.6 Flash, et la baisse tarifaire annoncée n’explique que la moitié de l’écart. Le tarif de lancement, fixé à $0.75 par million de tokens en entrée et $3.75 par million en sortie, est 50 % inférieur à celui de 3.6. Sur notre compteur, le même prompt de 6,9K tokens a bien coûté exactement deux fois moins cher ($0.00529 contre $0.01057). Le reste vient d’un changement moins visible : sur les quatre tâches mesurées, gemini-3.7-flash a consommé 26 à 77 % de tokens de réflexion en moins que 3.6. Nous avons testé le modèle deux jours après sa sortie : tarifs, réglage de la réflexion — avec une option disparue —, incompatibilités signalées par Google ou minimisées dans sa documentation, cache, contexte et continuité du tokenizer.

TL;DR

• Le tarif de lancement de $0.75/$3.75 reste valable jusqu’au 31 décembre 2026, puis passera à $1.50/$7.50. Sur notre compteur, le même prompt a coûté exactement deux fois moins cher qu’avec 3.6.
• La réflexion par défaut a baissé de 26 à 77 % par rapport à 3.6 (144 contre 384 tokens sur une tâche en 5 étapes). La facture par tâche est donc divisée par 2,5 à 8, et pas seulement par 2.
• La désactivation a disparu : toutes les syntaxes testées renvoient une erreur 400 (« Thinking level is unsupported »). low est désormais le minimum.
• Dans une boucle d’outils en deux tours, 3.7 a réduit de moitié sa réflexion au tour suivant le résultat de l’outil (32 contre 61 tokens). Refuser une question sans réponse a coûté environ 500 tokens aux deux modèles.

Combien coûte réellement Gemini 3.7 Flash ?

Jusqu’au 31 décembre 2026, son tarif est deux fois inférieur à celui de 3.6. Sur toutes les tâches mesurées, il consomme aussi moins de la moitié de ses tokens. Google a fixé le tarif de lancement à $0.75 par million de tokens en entrée et $3.75 par million en sortie. À partir du 1er janvier 2027, il repassera à $1.50/$7.50, soit exactement la grille de 3.6. Les lectures de cache coûtent $0.075 par million, soit 10 % du tarif d’entrée de lancement. Notre compteur confirme ces prix : le même prompt de 6,9K tokens a coûté $0.0052875 avec 3.7 et $0.0105675 avec 3.6, soit exactement deux fois moins.

L’écart principal vient des tokens que le modèle ne consomme plus. Pour chaque tâche identique et salée, nous avons effectué trois exécutions. Voici la médiane des tokens de raisonnement et le coût de sortie correspondant :

Google affirme au lancement que 3.7 « réfléchit avec plus de rigueur ». Sur nos tâches, cette rigueur se traduit par moins de tokens, et non davantage. Les deux modèles ont conservé une précision de 3/3 dans tous les cas. En combinant un tarif réduit de moitié et une réflexion au moins deux fois moins coûteuse, la facture réelle par tâche baisse de 61 à 88 %, hors cache. Attention toutefois à la date : les budgets doivent intégrer le retour au tarif normal le 1er janvier, comme pour le tarif de lancement de Sonnet 5.

Un type de tâche échappe à cette tendance, alors qu’il est rarement budgété : le refus. Nous avons interrogé les modèles sur cinq entités inventées — une entreprise, un institut, une charte municipale, un alliage et une récompense. Tous deux ont refusé les cinq demandes. Tous deux ont aussi dépensé plus de tokens de réflexion que pour n’importe quelle autre tâche mesurée : une médiane de 511 tokens avec 3.7 et de 494 avec 3.6. Répondre qu’« il n’existe aucune trace de cette entité » a demandé 3,5x plus de réflexion que la chaîne de calcul en 5 étapes. Les pipelines RAG qui rencontrent souvent des données absentes paient ce surcoût à chaque échec, et c’est le seul cas où l’avantage d’efficacité de 3.7 disparaît. Ces résultats apportent aussi une première mesure face à une inquiétude apparue la semaine du lancement : des testeurs ont signalé un taux d’hallucination supérieur pour 3.7, mais sur les questions portant sur des entités inventées, il a émis des réserves dans 5 cas sur 5, exactement comme 3.6.

Quels réglages de réflexion restent disponibles sur 3.7 ?

Trois niveaux, sans désactivation, conformément à la documentation : low, medium — la valeur par défaut — et high. En revanche, la documentation ne précise pas que les anciennes méthodes de désactivation de 3.6 ne fonctionnent plus. Toutes les syntaxes testées, reasoning_effort: "none", "minimal", thinking_budget: 0, thinking: {"type": "disabled"}, enable_thinking: false, ont renvoyé la même erreur 400 en amont : « Thinking level is unsupported: THINKING_LEVEL_MINIMAL ». Un second chemin de requête indépendant répond plus explicitement : « Reasoning is mandatory for this endpoint and cannot be disabled ». Le blocage vient donc du modèle, pas de la couche de traduction d’un client. Sur 3.6-flash, retesté dans le même lot, none et minimal ramènent toujours la consommation à zéro. La gamme Flash adopte ainsi la politique du niveau pro : la réflexion ne peut plus être désactivée, et 3.6 reste le dernier Flash à l’autoriser.

Résultats du réglage encore actif sur la tâche en 5 étapes — médiane de 3 exécutions, toutes correctes à 3/3 :

Deux points pratiques. Les mesures confirment que le niveau par défaut est bien medium : sans configuration, les exécutions ont consommé 154 tokens, un résultat comparable aux 147 tokens obtenus avec medium explicite. La dépréciation de thinking_budget est également réelle : toutes les valeurs non nulles testées, de 16 à 1 024, ont été acceptées mais ont produit la même consommation de 135 à 138 tokens. Le paramètre n’a donc aucun effet, alors que 3.6 convertit encore les petits budgets en désactivation et les plus grands en plafonds. Si votre intégration 3.6 pilote les coûts par budget, la migration vers 3.7 est simple : choisissez un niveau, aucune autre commande n’est disponible. Pour comparer l’efficacité des réglages entre fournisseurs, consultez notre matrice des réglages de réflexion.

Combien coûte chaque étape d’un agent ?

Le choix des outils ne change pas par rapport à 3.6. C’est la réflexion entre les étapes qui devient moins chère. Nous avons exécuté une boucle en deux tours avec deux fonctions — rechercher un incident, puis redémarrer le service indiqué — à raison de trois exécutions par modèle :

Les deux modèles ont d’abord choisi get_incident, puis restart_service, avec 3/3 réussites et un nombre identique de tokens de prompt. L’écart se trouve au second tour : 3.7 réfléchit environ deux fois moins avant de lancer l’appel suivant. C’est précisément l’étape répétée par un agent. Avec ces médianes, une boucle de 20 étapes coûte environ $0.0043 en sortie avec 3.7, contre $0.0131 avec 3.6. Cet écart restera le même après le retour au tarif normal de janvier, car il vient du nombre de tokens et non du prix unitaire. C’est ce qui permet à Google de présenter la progression sur les benchmarks agentiques sous l’angle du coût : moins de tokens de réflexion à chaque étape, multipliés par de nombreuses étapes.

Sa position face aux concurrents dépend du benchmark. Il faut examiner ces résultats avant de migrer un agent de code : des comparatifs indépendants placent 3.7 Flash devant Sonnet 5 sur FrontierCode (43.6% contre 42.7%) et près de 3x devant lui sur AutomationBench. D’après le même comparatif et les analyses publiées la semaine du lancement, GPT-5.6 Terra domine Terminal-bench et Sonnet 5 arrive en tête du test de tâches bureautiques. Sur le coût minimal, l’avantage de 3.7 ne laisse aucune ambiguïté.

Qu’est-ce qui casse lors d’une migration depuis 3.6 ?

Deux changements produisent systématiquement une erreur 400. Plusieurs autres échouent de façon plus discrète que ne le laisse entendre la documentation. La note de migration de Google demande de supprimer temperature, top_p, top_k, candidate_count et les tours de modèle préremplis. Voici nos mesures :

Le contraste est net : le réglage de réflexion est validé strictement — un niveau non pris en charge produit une erreur 400 claire qui cite sa valeur —, tandis que les paramètres d’échantillonnage et les plafonds de sortie acceptent tout sans signalement. Si votre bibliothèque cliente définit temperature par défaut, rien ne casse pour l’instant. Si elle préremplit des tours assistant pour guider la sortie, cette fonctionnalité était déjà cassée avant la migration.

Le cache, le contexte et le tokenizer restent-ils compatibles ?

Oui, avec un délai supplémentaire. Le cache implicite produit le même type de hit que sur 3.6 : au second appel d’un prompt identique, 4 076 tokens sur 6 905 provenaient du cache, ce qui a réduit le coût de l’appel de 52 %. Les lectures sont facturées à 10 % du tarif d’entrée de lancement. La construction du cache est toutefois plus lente : 3.6 a servi un hit 4 secondes après l’appel d’amorçage, tandis que 3.7 n’a rien renvoyé après 4 secondes et n’a produit un hit qu’après 30 secondes. Des requêtes identiques envoyées à quelques secondes d’intervalle arrivent donc avant que le cache soit prêt. L’économie côté écriture reste inchangée.

Le modèle a accepté 708 912 tokens en entrée lors d’un seul appel et a répondu correctement à une question ciblée, ce qui correspond à la fenêtre annoncée de 1M. La grille tarifaire ne prévoit aucun palier de prix pour les contextes longs. Le tokenizer texte produit exactement les mêmes octets sur quatre générations : gemini-3.1-pro-preview, 3.5-flash, 3.6 et 3.7 ont tous compté 50 tokens sur le même corpus mêlant anglais, chinois et code. Les budgets de tokens peuvent donc être repris tels quels. Les images sont toujours facturées au forfait de 1 089 tokens, quelle que soit leur taille, comme sur toute la gamme Gemini mesurée. Aucune des deux générations ne renvoie le texte de son raisonnement : reasoning_content était vide à chaque appel. La réflexion facturée reste donc invisible sur les deux modèles, un reproche récurrent dans les discussions de la semaine du lancement. Les sorties structurées fonctionnent toujours : le mode strict json_schema a renvoyé un JSON valide et correct lors de 3/3 exécutions. Avec reasoning_effort: "low", la réflexion de l’extraction est tombée à zéro, soit la même zone sûre pour les tâches en une étape que celle observée dans toute notre matrice de réglages.

FAQ

Combien coûte l’API Gemini 3.7 Flash ?

Le tarif de lancement est de $0.75 par million de tokens en entrée et de $3.75 par million en sortie jusqu’au 31 décembre 2026. À partir du 1er janvier 2027, il repassera à $1.50/$7.50, soit la même grille que Gemini 3.6 Flash. Les lectures de cache coûtent $0.075 par million. Sur des prompts identiques, notre compteur a facturé 3.7 exactement deux fois moins cher que 3.6.

Peut-on désactiver la réflexion sur Gemini 3.7 Flash ?

Non. Toutes les syntaxes de désactivation renvoient une erreur 400 (« Thinking level is unsupported »). Le réglage propose low, medium — la valeur par défaut — et high. Même au niveau low, notre tâche en 5 étapes a consommé 133 tokens de raisonnement. Gemini 3.6 Flash reste le modèle Flash le plus récent sur lequel reasoning_effort: "none" fonctionne, au tarif post-lancement de 3.7.

Gemini 3.7 Flash coûte-t-il vraiment moins cher que 3.6 par requête ?

Oui, et l’écart dépasse les 50 % annoncés. À tâche identique, il réfléchit aussi 26 à 77 % de moins. Dans nos mesures, la facture par tâche a donc baissé de 61 à 88 % — un problème en 2 étapes est passé de $0.0020 à $0.0002. Après le 31 décembre, le tarif rejoindra celui de 3.6 et seules les économies liées à la réflexion resteront.

Le code écrit pour Gemini 3.6 Flash fonctionne-t-il avec 3.7 ?

Dans l’ensemble, oui. Les paramètres d’échantillonnage (temperature, top_p, top_k) restent acceptés malgré leur présence dans la liste des suppressions, et les valeurs trop élevées de max_tokens sont plafonnées silencieusement. Deux incompatibilités sont strictes : les tours assistant préremplis renvoient une erreur 400 — comme c’était déjà le cas sur 3.6 — et toutes les méthodes de désactivation de la réflexion produisent désormais une erreur 400. Le pilotage des coûts doit donc passer de thinking_budget aux trois niveaux disponibles.

Mesures réalisées le 2026-08-15 via la gateway Synthorai, deux jours après la sortie : matrice des niveaux et méthodes de désactivation (7 valeurs d’effort, 5 budgets, 2 paramètres de désactivation, n=3, avec gemini-3.6-flash retesté dans le même lot pour chaque comparaison), mesure du coût de réflexion sur quatre tâches, sortie structurée en JSON strict, tests des paramètres dépréciés, acceptation du plafond de sortie et d’un contexte de 708K, paires de requêtes avec cache implicite selon deux délais, comparaison du tokenizer sur un corpus fixe pour quatre générations de Gemini, boucle d’appels de fonctions en deux tours (n=3 par modèle) et test de refus sur cinq questions portant sur des entités inventées. Les montants par tâche correspondent aux tokens de complétion mesurés, facturés au tarif de sortie actuel de chaque modèle. Deux résultats ont été vérifiés via un second chemin de requête indépendant : l’acceptation de valeurs max_tokens trop élevées et l’absence d’option de désactivation. Les tarifs et dates de lancement sont ceux publiés par Google. Le comportement peut évoluer à mesure que le déploiement se stabilise.

← Retour au blog