Tarifs du contexte long: jusqu'à 6,7x, invisibles sur les gateways

Le prix affiché sur la page d’un modèle n’est plus celui facturé par la gateway dès que le prompt devient long. Nous avons envoyé des requêtes de part et d’autre de chaque seuil de longueur documenté pour neuf modèles à paliers, via un grand agrégateur multi-provider. Cinq ont été facturés exactement 2x le prix de leur page après le premier seuil. Les trois modèles d’Alibaba sont montés à 3x, 3x et 6,7x au sommet de leurs grilles. Un modèle servi par Azure a été facturé 1,25x le tarif affiché pour son endpoint, avant comme après le seuil, puis son prix a doublé. Rien de tout cela n’apparaît sur les pages. Le mécanisme est documenté par les fournisseurs eux-mêmes: Google, OpenAI, xAI, Alibaba, ByteDance et MiniMax réévaluent toute la requête, sortie comprise, dès qu’elle dépasse un seuil fixé à 32K, 128K, 200k, 256K, 272K ou 512k tokens d’entrée. Cet article présente d’abord les factures, puis les grilles tarifaires qui les expliquent, et enfin les réglages permettant de rester sous les seuils.

TL;DR

• Neuf modèles à paliers ont été facturés entre 1,8x et 6,7x au-delà du seuil du fournisseur via un agrégateur dont les pages n’affichent qu’un seul prix. GPT-5.6 Luna via Azure a coûté 1,25x le tarif affiché.
• qwen3.7-flash a coûté $0.03, puis $0.10, puis $0.20 par million de tokens d’entrée aux seuils de 32K et 256K. qwen3-coder-plus s’est arrêté à 3x, alors que le fournisseur indique 6x.
• Dès que l’entrée franchit un seuil compris entre 32K et 512k tokens, les fournisseurs réévaluent toute la requête, sortie comprise.
• Limitez l’entrée, pas la sortie: /autocompact dans Claude Code, model_context_window dans Codex, ou les déclencheurs de compaction des API.

Les gateways facturent-elles le prix affiché?

Non, dès que le prompt devient long. Pour connaître l’écart, il faut comparer deux éléments chez chaque intermédiaire: les métadonnées tarifaires publiées par la gateway et le coût réellement remonté pour une requête de chaque côté du seuil.

Un grand agrégateur multi-provider publie son catalogue avec un tableau pricing.overrides: un prix de base accompagné de règles conditionnelles, par exemple min_prompt_tokens: 200000 avec les tarifs supérieurs. Pour les modèles DeepSeek et Tencent, on trouve aussi des plages utc_start / utc_end correspondant aux tarifs en heures creuses. Dans le catalogue récupéré le 2026-09-01, 60 entrées contenaient des overrides, notamment les modèles Gemini Pro, Grok 4.x, qwen3.7-plus, qwen3.7-flash, qwen3-coder-plus, les modèles Seed 2.0 et toute la gamme GPT-5.6 à 272,000. Les pages des modèles n’affichent que le prix de base. Le palier n’existe que dans les métadonnées. Et ces métadonnées ne reprennent pas toujours toute la grille du fournisseur: qwen3-coder-plus contient des règles à 32,000 et 128,000, mais aucune au quatrième palier du fournisseur, à 256K.

Nous avons donc envoyé des requêtes de part et d’autre de chaque seuil documenté via cet agrégateur, avec le suivi de consommation activé. L’agrégateur renvoie dans la réponse le montant facturé. Nous avons aussi enregistré l’endpoint utilisé, car un même identifiant de modèle peut pointer vers plusieurs hébergeurs upstream, chacun avec son propre prix. L’agrégateur les appelle des endpoints. Deux exécutions par point ont été réalisées les 2026-09-02 et 2026-09-03:

Ces pages ont été capturées le même jour que les factures. Elles affichent un prix principal, un tableau par endpoint et aucun palier de longueur. Tous les montants facturés ont suivi les métadonnées au token près. Les neuf modèles ont changé de tarif au premier seuil du fournisseur, selon le multiplicateur prévu par celui-ci. Pour les trois modèles Alibaba, la facture a suivi une grille absente de la page: qwen3.7-flash est passé de $0.03 à $0.10 à 32K, puis à $0.20 à 256K, soit 6,7x le prix affiché de $0.03. GPT-5.6 Luna a lui aussi changé de palier, avec un écart supplémentaire: chaque exécution servie par Azure a été facturée 1,25x le prix affiché pour l’endpoint Azure, avant comme après le seuil ($0.275 contre $0.22, puis $0.50 et $0.55 contre $0.40 et $0.44). Cette majoration n’apparaît ni sur la page ni dans les métadonnées de l’endpoint.

La grille peut aussi s’arrêter avant celle du fournisseur. Pour qwen3-coder-plus, le prix est monté à 1,8x à 32K, puis à 3x à 128K. Il est ensuite resté à $1.95 par million jusqu’à 276k tokens, alors que le tarif officiel d’Alibaba passe à $6 en entrée et $60 en sortie, soit six et douze fois les prix de base. Les métadonnées de l’agrégateur ne comportent aucune règle à 256K, et la facture n’a donc pas changé. Impossible de savoir de l’extérieur si l’agrégateur absorbe la différence ou bénéficie d’un contrat différent. Un point est en revanche observable: la facture suit les métadonnées, tandis que les métadonnées et la page sont deux documents différents.

Le manque de transparence ne se situe donc pas entre les métadonnées et la facture, mais entre la page et ces deux sources. Le prix principal de la page correspond à l’endpoint le moins cher du tableau, pas nécessairement à celui qui servira la requête. Ni l’un ni l’autre n’indique la condition de longueur. Une fiche modèle avec un prix unique ne précise ni le palier, ni l’endpoint qui traitera la prochaine requête, ni même si l’endpoint dont vous consultez le prix est accessible à votre compte.

La règle à suivre est simple. Consultez les tarifs machine-readable du modèle utilisé au niveau de l’endpoint et recherchez une condition de longueur. Envoyez ensuite une requête de chaque côté du seuil avec le suivi de consommation activé, puis comparez le coût remonté. Si le prix de la gateway change à un seuil absent de sa page, elle répercute une règle du fournisseur sans l’indiquer. Si son prix reste fixe alors que celui du fournisseur change, elle utilise soit un hébergeur appliquant d’autres tarifs, soit elle absorbe l’écart. Seul le premier cas peut durer.

Où se trouvent les seuils et comment s’appliquent-ils?

Six fournisseurs publient un seuil de longueur. Pour chaque modèle dont la règle est explicite, le tarif supérieur s’applique à tous les tokens de la requête, sortie comprise. Le premier palier est généralement à 2x, mais certaines grilles montent davantage: 3x à l’unique seuil de qwen3.7-plus, 6,7x en entrée au troisième palier de qwen3.7-flash, puis 6x en entrée et 12x en sortie au quatrième palier de qwen3-coder-plus. Les prix sont indiqués par million de tokens et proviennent des pages tarifaires des fournisseurs consultées le 2026-09-01.

Deux détails de frontière doivent être reproduits dans le code de facturation. Les deux pages de Google diffèrent d’un token: la note Vertex dit « supérieur ou égal à 200K », tandis que le tableau tarifaire de l’API Gemini indique « prompts > 200k tokens ». Alibaba donne aussi une définition précise de K: 128K correspond à 128,000 tokens et 256K à 256,000, pas à des puissances de deux.

Le palier est déterminé uniquement par la longueur de l’entrée, mais il s’applique à toute la requête, y compris la sortie. Le coût marginal du token qui franchit le seuil correspond donc à toute la majoration appliquée aux tokens qui le précèdent. Avec Gemini 2.5 Pro, un prompt de 199,999 tokens coûte $0.25 en entrée. À 200,001 tokens, il coûte $0.50, et une réponse de 4,000 tokens passe de $0.04 à $0.06. Un token supplémentaire entraîne donc $0.27 de plus.

Pour qwen3.7-plus, le passage est à 3x: au tarif officiel, un prompt de 255,029 tokens coûte $0.102, contre $0.309 pour 257,332 tokens. Sur qwen3-coder-plus, le même mécanisme se cumule sur quatre paliers. Un prompt de 260k tokens est alors facturé six fois plus par token qu’un prompt de 30k, et sa sortie douze fois plus.

La règle apparaît sur une facture réelle, pas seulement dans le tableau du fournisseur. Pour qwen3.5-plus, dont les tarifs officiels passent de $0.40 à $0.50 par million de tokens d’entrée à 256K, notre facture gateway par token d’entrée différait exactement de 1,25x entre dix exécutions sous le seuil, à 243k tokens, et 24 exécutions au-dessus, de 256k à 321k. Le prix de sortie n’a pas changé. La requête de 259k n’a pas payé 1,25x uniquement sur ses 3k derniers tokens, mais sur l’ensemble des tokens.

Pour un agent qui accumule l’historique, le franchissement se produit silencieusement au milieu d’une session. Le tour qui dépasse le seuil paie la majoration sur tous les tours antérieurs qu’il transporte. Chaque tour suivant continue à la payer jusqu’à ce que le contexte soit réduit.

Les capacités changent-elles au même seuil?

Non. Nous l’avons mesuré, car il est facile de confondre le palier tarifaire avec une limite de capacité. Ce n’en est pas une. Sur deux modèles Qwen à paliers dont le seuil se situe à 256K, nous avons inséré à cinq profondeurs une needle unique, une ligne factuelle contenant un code aléatoire propre à chaque exécution. Elle a été retrouvée 30 fois sur 30 par chaque modèle à 243k, 269k et 320k tokens, avec le thinking désactivé. La latence a augmenté progressivement avec la longueur, sans rupture au seuil: médiane de 15,2 s, 17,0 s et 20,5 s sur qwen3.7-plus. Une tâche plus difficile, consistant à compter K occurrences rares réparties dans tout le journal, s’est bien dégradée avec la longueur. Sur qwen3.7-plus, la part retrouvée est passée de 74% à 128k à 60% à 192k, 58% à 243k et 45% à 320k. La baisse commence bien avant le seuil tarifaire, et les mesures de part et d’autre suivent la même pente.

La documentation d’Anthropic nomme cet effet progressif: quand le nombre de tokens augmente, la précision et le rappel se dégradent, phénomène appelé « context rot ». Cet effet est réel et continu. Il ne dépend pas du seuil tarifaire.

Comment garder une requête sous le seuil?

Limitez l’entrée, pas la sortie. Le palier dépend de la longueur d’entrée de la requête. max_tokens, qui limite la sortie, n’a donc aucun effet. Il faut agir sur les réglages qui bornent ce que le client envoie. Ils existent à quatre niveaux.

Voici les réglages qui limitent le prompt, classés par niveau. La colonne « Sous un palier? » identifie ceux qui acceptent un nombre absolu de tokens et peuvent donc être réglés juste sous un seuil tarifaire. Les réglages relatifs à la fenêtre servent uniquement à rester dans la fenêtre de contexte du modèle, qui correspond à une autre limite.

Ce tableau entraîne deux conclusions. Pour un agent de code utilisant un modèle à paliers, la fenêtre de compaction est le réglage qui remplace la hausse brutale par un résumé. Elle doit être exprimée en nombre absolu de tokens juste sous le seuil, et non comme une proportion d’une fenêtre de 1M. Les deux réglages de sécurité les plus courants, Responses truncation: "auto" et le middle-out de l’agrégateur, protègent uniquement la fenêtre du modèle. Ils se déclenchent à 1M sur les modèles Gemini et GPT-5.6 concernés, et non à 200,000 ou 272,000 tokens, là où le tarif change. Ils empêchent donc la requête d’échouer, mais pas de franchir le seuil tarifaire.

Ne comptez pas sur le cache pour rester sous le seuil. Le prompt cache réduit la facture, mais pas le palier sur les modèles Google, où les lectures de cache suivent le même palier de longueur: un préfixe en cache de 150k auquel s’ajoutent 60k de contexte frais forme un prompt de 210k et est facturé comme tel. La capacité provisionnée évite entièrement la question, car les provisioned throughput units (PTUs) sont facturées à l’heure, quel que soit le nombre de tokens. Si le franchissement du seuil se justifie, faites-le volontairement. Les mesures ci-dessus montrent que le modèle ne devient pas moins performant au seuil. La seule question est de savoir si le contexte marginal vaut un multiplicateur de 2x, 3x, voire 6,7x aux paliers les plus élevés, appliqué à toute la requête.

Comment Synthorai gère ces paliers

Un palier de longueur est une condition tarifaire. La gateway le traite donc comme tel: la fiche tarifaire d’un modèle peut contenir une liste de paliers indexés par un seuil de tokens d’entrée. Chaque requête est facturée selon le palier sélectionné par la longueur de son propre prompt, sur tous ses tokens, comme chez le fournisseur. C’est ce mécanisme qui a produit la facture qwen3.5-plus présentée plus haut. L’enregistrement de consommation conserve le nombre de tokens du prompt et la version du tarif avec le coût calculé. Une facture peut ainsi être décomposée jusqu’à indiquer qu’une requête donnée a franchi le seuil. Le palier utilisé pour facturer une requête peut être relu dans l’enregistrement de consommation, pas uniquement dans un tableau tarifaire.

FAQ

Le tarif supérieur du contexte long s’applique-t-il uniquement aux tokens au-delà du seuil?

Non. Tous les fournisseurs qui documentent cette règle réévaluent toute la requête: Google indique que « tous les tokens, en entrée comme en sortie, sont facturés au tarif du contexte long », OpenAI précise « pour la totalité de la requête », xAI « pour tous les tokens de la requête » et Alibaba « tous les tokens de la requête sont facturés au prix unitaire du palier correspondant ». Un prompt qui dépasse le seuil d’un seul token paie la majoration sur tous les tokens précédents.

Les gateways API répercutent-elles les paliers tarifaires du contexte long?

Oui, selon nos mesures. Via un grand agrégateur, neuf modèles à paliers ont été facturés au tarif supérieur du fournisseur après le seuil de celui-ci, alors que leurs pages n’affichent qu’un seul prix. Le palier figure dans les métadonnées tarifaires de la gateway, pas sur la page. Ces métadonnées peuvent aussi omettre un palier du fournisseur, comme pour qwen3-coder-plus au-dessus de 256K.

max_tokens permet-il de rester sous un palier tarifaire?

Non. max_tokens limite la sortie, tandis que le palier est déterminé par la longueur de l’entrée. Les réglages utiles bornent le prompt: fenêtre de compaction ou limite de tokens dans l’agent, comme /autocompact dans Claude Code ou model_context_window dans Codex, déclencheur de compaction dans l’API, ou troncature côté client avant l’envoi de la requête.

La qualité du modèle baisse-t-elle au seuil tarifaire?

Pas dans nos mesures. Sur deux modèles Qwen à paliers, le rappel de la needle était parfait de part et d’autre du seuil de 256K. Une tâche de comptage s’est dégradée progressivement avec la longueur, sans rupture au seuil. Le palier relève d’une règle commerciale. La perte de capacité liée à la longueur existe, mais elle est continue.

Prix et règles cités depuis les pages tarifaires des fournisseurs consultées le 2026-09-01; réglages des agents et API issus de la documentation liée au 2026-09-02; mesures de facturation réalisées du 2026-09-01 au 2026-09-03, avec le thinking désactivé, des prompts salés et deux exécutions par point chez l’agrégateur. Les prix évoluent. Vérifiez la source liée avant d’intégrer un seuil au code de facturation.

À lire aussi: guide des unités de facturation (la couche de modificateurs détaillée dans cet article), anatomie de la consommation de tokens, fonctionnement du prompt cache, mesure des minimums du cache.

← Retour au blog