La plupart des équipes appellent un fournisseur de modèles directement depuis le code applicatif. La clé d’API tient dans une variable d’environnement, l’appel SDK fait trois lignes, et cela marche du premier coup. Cloudflare AI Gateway existe à cause de ce qui arrive ensuite. La facture tombe et personne ne peut dire quelle fonctionnalité l’a provoquée. Le fournisseur passe un mauvais après-midi et emporte votre produit avec lui. Un prompt système est modifié et il ne reste aucune trace de ce que renvoyait l’ancien.

Une passerelle est un proxy entre votre application et le fournisseur. Chaque requête la traverse, donc chaque requête peut être comptée, journalisée, mise en cache, limitée en débit et, quand le fournisseur tombe, réessayée ailleurs. C’est le correctif structurel le moins cher pour trois problèmes que l’on résout autrement tard et à la main.

Voici ce qu’elle fait, ce qu’elle impose par opposition à ce qu’elle se contente d’observer, ce qu’elle coûte en argent et en millisecondes, et où se situent ses limites honnêtes.

Mettre une passerelle devant votre API de modèle fait-il vraiment économiser ? Pas directement. Le cœur de Cloudflare AI Gateway est gratuit sur toutes les formules et n’ajoute aucune marge sur l’inférence, donc l’économie vient de ce qu’elle vous montre plutôt que de ce qu’elle bloque. L’attribution des coûts par fonctionnalité vous dit quelle partie du produit coûte cher, la mise en cache supprime les appels identiques répétés là où c’est sûr, et le routage de repli évite qu’une panne du fournisseur devienne la vôtre. Le plafonnement budgétaire existe, mais ce qui se passe une fois le budget épuisé est une décision produit, pas un réglage.

Les trois questions auxquelles un appel direct au modèle ne répond pas

Tout argument en faveur d’une passerelle se ramène à l’une des trois questions qu’un appel SDK direct laisse sans réponse. La version abstraite, visibilité et contrôle, ne convainc personne qui doit justifier le travail.

Personne ne peut attribuer la facture

La facturation au token dépend de l’usage et les factures des fournisseurs agrègent. Vous recevez un total mensuel par clé d’API, pas un total par fonctionnalité. Si un résumeur, un assistant conversationnel et un travail de classification nocturne partagent une clé, la facture ne peut pas dire lequel a triplé. La réponse habituelle est une clé par fonctionnalité, ce qui marche jusqu’à ce que vous ayez onze fonctionnalités et une politique de rotation.

Personne ne peut reproduire la panne

Quand un appel échoue dans le code applicatif, ce qui survit est ce que votre journal a capturé, en général un code de statut et un message tronqué. Rarement le prompt exact, la version du modèle qui a répondu, ou la latence à laquelle il a abandonné. Reproduire un incident un jour plus tard devient une devinette sur les entrées. Pendant ce temps, une panne du fournisseur se propage directement jusqu’à vos utilisateurs.

Rien ne plafonne une boucle emballée

Un agent qui se relance, un consommateur de file qui redistribue en cas d’échec, ou une boucle dont un modèle juge sans cesse la condition d’arrêt non remplie : chacun peut générer des milliers d’appels avant que quiconque le remarque. Sans rien dans le chemin qui compte, le premier signal est la facture. Les limites par utilisateur et les arrêts nets n’existent pas tant qu’un composant du chemin ne les impose pas, et le code applicatif est un mauvais endroit pour cela, car chaque point d’appel doit y penser.

Ce qu’est Cloudflare AI Gateway et où il se place dans le chemin de la requête

L’aperçu d’AI Gateway de Cloudflare décrit un service placé entre votre application et les fournisseurs de modèles d’IA, afin de surveiller l’usage et de gérer la montée en charge de l’application. Les fonctions sont l’analytique, la journalisation, la mise en cache, la limitation de débit et la reprise avec repli, sur toutes les formules Cloudflare. Cloudflare affirme qu’une seule ligne de code suffit pour démarrer, et la forme de l’intégration explique pourquoi c’est presque vrai.

L’intégration se résume à changer d’URL de base

Au lieu de pointer votre SDK vers le fournisseur, vous le pointez vers une adresse de passerelle portant votre identifiant de compte, votre identifiant de passerelle et le nom du fournisseur. Cloudflare documente la forme OpenAI comme https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai, fournie en tant que baseURL à la construction du client. Les noms de modèles, les paramètres, le streaming et l’analyse des réponses restent inchangés. La liste des fournisseurs de Cloudflare couvre deux douzaines de services sur le même schéma, dont OpenAI, Anthropic, Google Vertex AI, Amazon Bedrock, Azure OpenAI, Mistral, Groq, DeepSeek, xAI et le Workers AI de Cloudflare.

Ce que cette forme implique

L’adoption est vraiment peu coûteuse : une valeur de configuration par service, réversible en la remettant comme avant, ce qui en fait l’un des rares changements d’infrastructure que l’on peut essayer sans plan de projet.

Votre clé de fournisseur transite désormais par Cloudflare, parce que le proxy doit la transmettre, sauf si vous passez aux clés stockées ou aux identifiants gérés par Cloudflare. C’est une décision de confiance, pas un détail.

Et tout ce qui est proposé est borné par ce qu’un proxy peut voir. Il voit les requêtes et les réponses, pas l’intention de votre application, et c’est pourquoi l’attribution exige que vous étiquetiez vous-même les requêtes plutôt que d’attendre de la passerelle qu’elle devine à quoi servait un appel.

L’analytique et la journalisation sont les fonctions qui font économiser

La passerelle compte chaque requête. La documentation sur la journalisation de Cloudflare liste ce que contient une entrée : le prompt de l’utilisateur, la réponse du modèle, le fournisseur, l’horodatage, le statut de la requête, la consommation de tokens, le coût, la durée et l’agent utilisateur du client. Par requête plutôt que par mois, et interrogeable.

Soyez direct sur la raison pour laquelle l’argent est ici, et non dans les fonctions de contrainte. Bloquer une dépense économise le coût des appels que vous avez arrêtés, ce qui est borné. Savoir où part la dépense change ce que vous construisez, ce qui ne l’est pas.

L’attribution n’est pas automatique. Les métadonnées personnalisées attachent vos propres étiquettes, nom de fonctionnalité ou de client par exemple, pour que l’analytique puisse regrouper selon elles. Sautez cette étape et vous obtenez un total, c’est-à-dire ce que la facture vous donnait déjà.

La mise en cache, et les cas où un succès de cache ruine le produit

La mise en cache est la fonction le plus souvent activée pour la mauvaise raison, et celle qui est la plus capable de casser un produit en silence.

Comment la clé de cache est construite

La documentation sur la mise en cache de Cloudflare explique que la clé est une empreinte SHA-256 du fournisseur, du point de terminaison, du modèle, de l’en-tête d’authentification et du corps complet de la requête. Une correspondance exacte sur l’ensemble est un succès, tout le reste un échec. Un succès suppose donc une requête identique au octet près, ce qui est rare après le premier tour sur un point de terminaison de conversation portant un historique accumulé. La durée de vie minimale est de 60 secondes et la maximale d’un mois. Le contrôle par requête vient de cf-aig-cache-ttl, cf-aig-skip-cache et cf-aig-cache-key, tandis que cf-aig-cache-status renvoie HIT ou MISS pour mesurer le taux de succès réel.

Quand un succès est sûr et quand il ne l’est pas

Un succès est sûr là où une entrée identique doit produire une sortie identique et où l’obsolescence est acceptable : classification, extraction structurée, traduction de chaînes fixes, embeddings de documents inchangés, trafic d’évaluation. Il est risqué partout où la valeur du produit dépend de la variation. Si deux utilisateurs posent la même question et que le second reçoit une réponse produite pour le premier, votre réglage de température est décoratif.

L’échec le plus grave relève de la confidentialité. Si le corps de la requête ne porte rien qui distingue les utilisateurs, une réponse mise en cache peut franchir une frontière entre comptes, ce qui est une divulgation et non un problème de qualité. La mise en cache ne couvre par ailleurs que les réponses texte et image.

Limitation de débit, reprises et routage de repli

Ces trois éléments sont décrits ensemble comme des fonctions de fiabilité. Un seul d’entre eux contraint réellement le coût.

La limitation de débit plafonne les requêtes, pas les tokens

Cloudflare propose une fenêtre fixe et une fenêtre glissante, et les requêtes au-dessus de la limite reçoivent un 429. Notez ce qui est compté : des requêtes. Un appel unique portant un très grand contexte coûte bien plus qu’un appel court, et le limiteur ne sait pas les distinguer. La limitation de débit vous protège d’une boucle emballée et d’un point de terminaison abusé, pas d’un prompt coûteux, et la traiter comme un contrôle des coûts est l’erreur courante.

Reprises et délais d’expiration

Les en-têtes de traitement des requêtes de Cloudflare autorisent jusqu’à 5 tentatives avec cf-aig-max-attempts, un délai jusqu’à 5000 millisecondes avec cf-aig-retry-delay, et une stratégie constante, linéaire ou exponentielle avec cf-aig-backoff. L’en-tête cf-aig-request-timeout se mesure à partir de l’arrivée de la première partie de la réponse, c’est donc, sur un appel en streaming, une limite sur le temps jusqu’au premier octet plutôt que sur la durée totale. À la dernière tentative, la passerelle attend la fin de la requête, aussi longue soit-elle.

Le routage de repli a changé de forme

L’Universal Endpoint, qui prenait un tableau d’objets fournisseurs et le parcourait en cas d’échec, est déprécié. Cloudflare oriente désormais les nouvelles intégrations vers le point de terminaison compatible OpenAI, et vers Dynamic Routing pour les replis, les reprises et le routage conditionnel. Une route dynamique est un flux nommé et versionné, construit visuellement ou en JSON, fait de nœuds de modèle, de nœuds conditionnels qui bifurquent selon le corps de la requête, les en-têtes ou les métadonnées, de nœuds de pourcentage pour les tests A/B, et de nœuds de limite de débit et de limite de budget qui dévient vers un repli en cas de dépassement. Vous l’invoquez en mettant le nom de la route là où va le nom du modèle.

Inspecter ce qui entre et ce qui revient

Parce que le proxy détient les deux moitiés de l’échange, il peut les évaluer. Les Guardrails de Cloudflare interceptent les prompts des utilisateurs et les réponses des modèles, signalent un contenu pour examen ou l’empêchent de passer, et appliquent une politique unique quel que soit le fournisseur qui a répondu.

L’argument en faveur d’une politique dans le chemin plutôt que dans le code est que la modération applicative doit être écrite une fois par point d’appel, et que le point d’appel ajouté la semaine dernière est celui qui l’oublie. Le prix à payer est que l’inspection est elle-même de l’inférence : les Guardrails sont facturés comme un usage de Workers AI au token, donc le prix suit la longueur de ce que vous inspectez. L’analyse de prévention des fuites de données est gratuite sur toutes les formules.

Ce qui a changé pendant l’Agents Week d’août 2026

Cloudflare a tenu sa première Agents Week du 3 au 7 août 2026 et a publié le dernier jour l’unification de Workers AI et d’AI Gateway en un seul plan de contrôle. Séparez ce qui est livré de ce qui est annoncé.

Ce qui est livré : un seul binding IA au lieu de deux, si bien que env.AI.run() couvre à la fois les modèles Workers AI et les fournisseurs externes. Le routage par passerelle est devenu le comportement par défaut de Workers AI plutôt qu’une option, avec gateway: { id: 'default' } qui crée la passerelle à la première utilisation et apporte la journalisation des requêtes, le suivi des tokens et l’attribution des coûts sans autre changement. Les crédits sont devenus dépensables chez tous les fournisseurs, donc Workers AI se paie sur le même solde prépayé qu’OpenAI ou Anthropic.

Ce qui n’est pas livré : le routage par modèle, où vous demandez un modèle et où la plateforme choisit le fournisseur, est annoncé pour la suite et n’est pas disponible, et un routeur intelligent qui classe les prompts reste un pilote interne. Il s’agit d’une consolidation de la facturation, des bindings et des tableaux de bord, pas d’une nouvelle capacité. Si vous appeliez déjà Workers AI en périphérie sans passerelle, vous obtenez maintenant l’observabilité par défaut.

Ce que coûte Cloudflare AI Gateway

La page de tarification d’AI Gateway de Cloudflare indique que les fonctions de base disponibles aujourd’hui sont offertes gratuitement, ce qui couvre l’analytique du tableau de bord, la mise en cache et la limitation de débit sur toutes les formules. Tous les chiffres ci-dessous sont les prix en dollars américains publiés par Cloudflare, cités dans la devise dans laquelle Cloudflare les publie.

Où les frais apparaissent réellement

Les journaux persistants sont gratuits mais plafonnés par formule : 100 000 journaux pour l’ensemble des passerelles sur Workers Free, et 10 millions par passerelle sur Workers Paid. Logpush, qui exporte ces journaux ailleurs, est une fonction de la formule Paid, à 10 millions par mois avec 0,05 USD par million supplémentaire. Workers AI lui-même, d’après sa page de tarification, inclut 10 000 neurons par jour sans frais et facture 0,011 USD par tranche de 1 000 neurons au-delà sur la formule Paid, un neuron étant l’unité de calcul GPU de Cloudflare.

La facturation unifiée coûte 5 pour cent

Si vous utilisez les identifiants gérés par Cloudflare plutôt que vos propres clés de fournisseur, les achats de crédits portent des frais de 5 pour cent. L’exemple donné par Cloudflare est un achat de crédit de 100 USD facturé 105 USD. L’inférence est répercutée sans marge. Si vous apportez votre propre clé, la facturation unifiée ne s’applique pas, car une requête portant une authentification de fournisseur ou une clé stockée la contourne.

Le contrôle des coûts fait correctement

Une passerelle impose de façon fiable trois choses : un débit de requêtes, une limite de budget à l’intérieur d’une route dynamique, et le fait qu’une requête soit servie depuis le cache. Tout le reste de ce qu’elle fait relève de la mesure. Confondre ces deux catégories explique pourquoi des équipes en installent une, cochent toutes les cases, et restent surprises par la facture.

Un plafond budgétaire strict est une décision d’entreprise avant d’être une configuration. Quelque chose doit arriver quand le plafond est atteint, et chaque option est mauvaise à sa manière. Faire échouer la requête dégrade le produit pour celui qui a demandé en dernier, ce qui ressemble à un bug. Se replier sur un modèle moins cher dégrade la qualité en silence. Mettre en file convertit un problème de coût en problème de latence. Choisir entre ces options, c’est cela le travail.

L’économie qui atteint une facture vient d’habitude de l’observabilité plutôt que de la contrainte. Une fois la dépense regroupée par fonctionnalité, la chose coûteuse est presque toujours réparable sans changer de modèle : un prompt système surdimensionné envoyé à chaque tour, un historique de conversation complet renvoyé là où un résumé glissant suffirait, une boucle de reprise qui s’acharne sur un échec qui n’allait jamais réussir. Un journal trouve tout cela. Un limiteur de débit n’en trouve aucun.

La latence que vous ajoutez

Un saut supplémentaire n’est pas gratuit, et prétendre le contraire est la façon dont une bonne décision se prend pour une mauvaise raison. Votre requête se termine désormais dans un centre de données Cloudflare, y est traitée puis transmise au fournisseur, ce qui ajoute une poignée de main TLS et un segment réseau que vous ne payiez pas auparavant.

Dans le cas normal, c’est petit par rapport à ce que cela enveloppe. Une complétion de conversation dure de quelques centaines de millisecondes à plusieurs secondes et reste dominée par le temps de génération, et la passerelle siège sur le réseau périphérique de Cloudflare, donc le premier segment se termine près de l’appelant. Face à une complétion de deux secondes, le surcoût est du bruit.

Là où il cesse d’être du bruit, c’est sur les appels courts, peu coûteux et très nombreux. Une requête d’embedding qui revient bien en dessous d’un dixième de seconde est un cas où le surcoût fixe devient un pourcentage visible. Le streaming est l’autre cas, parce que le chiffre que les utilisateurs ressentent est le temps jusqu’au premier token, et tout ce qui s’ajoute avant lui pèse sur la métrique qui compte. Mesurez-le à partir de la durée que la passerelle journalise, face au même appel fait en direct.

Stratégie multifournisseur et l’enfermement auquel vous n’échappez pas

L’argument de vente est qu’une passerelle rend les fournisseurs interchangeables, et à la couche de transport c’est vrai. Le point de terminaison compatible OpenAI vous donne une seule forme de requête, le routage dynamique vous donne la bascule sans déploiement, et changer un nom de modèle devient de la configuration plutôt que du code.

La couche de transport n’a jamais été la partie coûteuse. Changer de modèle coûte cher parce que les modèles se comportent différemment. Un prompt système affiné pendant des mois sur un modèle produit une autre sortie sur un autre. Les formats et la fiabilité des appels d’outils diffèrent. Le comportement de refus diffère, donc un contenu qui passait avant se voit refusé. Le respect d’une forme JSON demandée diffère, et un analyseur écrit selon les habitudes d’un modèle casse sur celles d’un autre. Les fenêtres de contexte diffèrent.

Ce que vous achetez vraiment, c’est qu’un changement devienne un après-midi d’évaluation plutôt qu’un sprint de plomberie, et que la bascule en cas de panne existe sans que vous la construisiez. Cela vaut la peine, mais ce n’est pas de la portabilité. Une dépendance de second ordre mérite d’être nommée : la passerelle siège maintenant dans le chemin de chaque appel de modèle, donc sa disponibilité devient la vôtre. C’est le même arbitrage que nous avons examiné en comparant Cloudflare Workers et AWS Lambda.

Journaliser des prompts, c’est traiter des données personnelles

C’est la section que l’on saute et celle qui porte une exposition juridique. La journalisation est active par défaut sur chaque passerelle, et une entrée contient le prompt de l’utilisateur et la réponse du modèle en entier. Si vos utilisateurs tapent quoi que ce soit à leur sujet, collent un document ou décrivent une situation médicale ou financière à votre assistant, ce contenu constitue des données personnelles dans un stockage de journaux tiers, et sous le UK GDPR vous en restez le responsable de traitement.

Expurgez avant que cela ne quitte votre application

Le seul endroit fiable pour retirer quelque chose est avant l’envoi. La passerelle propose cf-aig-collect-log-payload: false pour garder les métadonnées en abandonnant les corps, et cf-aig-collect-log: false pour ne rien journaliser. Mais la minimisation des données consiste à ne pas collecter plus que nécessaire dès le départ, donc le correctif durable est en amont : retirez les numéros de compte, les identifiants et les champs libres dont le modèle n’a pas besoin avant que la requête ne quitte votre processus.

La conservation est une décision que vous devez prendre

Les recommandations de l’ICO sur la limitation de conservation ne fixent aucune durée. Elles exigent que vous ne gardiez pas les données personnelles plus longtemps que nécessaire, que vous puissiez justifier la durée choisie, que vous ayez une politique fixant des durées standard, et que vous révisiez puis effaciez ou anonymisiez ce dont vous n’avez plus besoin. Un stockage de journaux avec un plafond lié à la formule n’est pas une politique de conservation, car un plafond est une limite de stockage et non une durée justifiée.

Les solutions concurrentes, nommées loyalement

Il existe trois vraies solutions concurrentes, et le choix porte surtout sur qui exploite la chose.

Un proxy LLM open source auto-hébergé vous donne le même chemin de requête avec les journaux sur une infrastructure que vous contrôlez, ce qui convient quand la sensibilité des prompts est elle-même le problème. Le prix est l’exploitation d’un composant sur le chemin critique de chaque appel de modèle.

Un éditeur spécialisé en observabilité des LLM va plus loin sur l’évaluation, le versionnage des prompts et l’inspection des traces. Si votre problème est que les sorties sont fausses plutôt que les coûts opaques, cela convient mieux, et les deux ne s’excluent pas.

Le construire vous-même se défend quand le besoin est étroit. Un wrapper qui enregistre requête, réponse, comptes de tokens et une étiquette de fonctionnalité dans votre pile d’observabilité existante représente peut-être deux jours de travail et répond à la question de l’attribution. Ce que vous n’obtiendrez pas à bon compte, c’est la mise en cache avec une clé correcte, et la bascule entre fournisseurs.

La règle : si personne ne sait où part la dépense, une passerelle est le correctif le plus rapide et la formule gratuite le prouve. Si les prompts ne doivent pas quitter votre infrastructure, auto-hébergez. Si les sorties sont fausses, aucune passerelle n’aide et il vous faut des outils d’évaluation.

Ce que demande la mise en œuvre, et ce qu’elle rapporte

Pour un seul service appelant déjà un fournisseur, une demi-journée. Créer la passerelle, changer l’URL de base dans la configuration, déployer derrière un drapeau pour qu’un retour arrière soit une variable d’environnement plutôt qu’une livraison, regarder les journaux se remplir, confirmer que le streaming se comporte toujours bien.

Pour un vrai produit, prévoyez trois à cinq jours-ingénieur, et l’essentiel n’est pas la passerelle. C’est décider d’un schéma de métadonnées pour que l’attribution réponde aux questions que vous poserez vraiment, auditer chaque point d’appel y compris les travaux planifiés et le code que personne n’a ouvert depuis un an, déterminer quels points de terminaison peuvent être mis en cache sans risque, et écrire l’étape d’expurgation. Ajoutez un jour pour le routage de repli, car un repli ne vaut la peine qu’une fois testé que le modèle de repli produit une sortie acceptable.

Le retour est peu spectaculaire. Vous cessez d’être surpris par la facture, ce qui pour la plupart des équipes vaut mieux que l’économie absolue. Une panne du fournisseur devient une réponse dégradée plutôt qu’un incident. Les équipes qui construisent des flux d’agents en profitent le plus, car une action utilisateur qui se ramifie en dizaines d’appels de modèle est l’endroit où les estimations s’écartent de la réalité, un schéma que nous avons traité dans ce que coûtent les agents IA et où ils échouent.

En installer une sans casser la production

La séquence qui marche est ennuyeuse à dessein. Mettez la passerelle dans le chemin avec la journalisation activée et rien d’autre. Collectez une semaine de données. Lisez l’attribution. Activez ensuite exactement les fonctions que les données justifient, et activez la mise en cache en dernier, uniquement sur les points de terminaison où vous pouvez expliquer pourquoi une réponse répétée est une réponse correcte.

Mecanik construit et exploite cette couche dans le cadre de notre travail d’intégration d’IA, et notre service d’intégration de l’API OpenAI couvre le côté fournisseur. Les missions commencent presque toujours de la même façon, par une semaine de journalisation et aucun autre changement, parce que les données d’attribution réordonnent en général la liste des priorités.

Questions fréquentes

Cloudflare AI Gateway est-il gratuit ? Les fonctions de base sont gratuites sur toutes les formules, ce que la page de tarification de Cloudflare décrit comme l’analytique du tableau de bord, la mise en cache et la limitation de débit, et l’analyse de prévention des fuites de données est gratuite aussi. Les frais apparaissent sur les bords : Logpush est une fonction de la formule Paid, les Guardrails sont facturés comme de l’inférence Workers AI au token, et le stockage des journaux est plafonné par formule plutôt que facturé au journal.

Une passerelle IA ajoute-t-elle de la latence aux appels de modèle ? Oui, elle ajoute une poignée de main TLS et un segment réseau. Face à une complétion de conversation qui dure de quelques centaines de millisecondes à plusieurs secondes, ce surcoût est en général négligeable. Il devient visible sur les appels courts et très nombreux comme les embeddings ou les petites classifications, et sur les réponses en streaming où la métrique ressentie est le temps jusqu’au premier token plutôt que la durée totale.

Quand est-il risqué de mettre en cache des réponses de LLM ? Chaque fois que la valeur du produit dépend de la variation entre les réponses, ou que le corps de la requête ne distingue pas un utilisateur d’un autre. Cloudflare construit la clé de cache à partir du fournisseur, du point de terminaison, du modèle, de l’en-tête d’authentification et du corps complet, donc un succès suppose une requête identique au octet près. Le cache convient à la classification, à l’extraction et aux embeddings, pas aux réponses conversationnelles qui doivent différer selon l’utilisateur.

Une passerelle facilite-t-elle le changement de fournisseur de modèles ? À la couche de transport, oui. Une seule forme de requête, un seul changement de configuration, et la bascule sans déploiement. La partie coûteuse du changement reste intacte : un prompt affiné sur un modèle se comporte autrement sur un autre, les formats d’appels d’outils et le comportement de refus diffèrent, le respect du JSON diffère, et les fenêtres de contexte diffèrent. Une passerelle supprime la plomberie, pas le travail d’évaluation.

Qu’a changé Cloudflare en août 2026 ? Le 7 août 2026, à la fin de l’Agents Week, Cloudflare a unifié Workers AI et AI Gateway en un seul plan de contrôle : un binding IA couvrant Workers AI et les fournisseurs externes, le routage par passerelle activé par défaut pour Workers AI, et des crédits dépensables chez tous les fournisseurs depuis un solde prépayé unique. Le routage par modèle a été annoncé pour la suite, pas livré.