Cloudflare a livré Code Mode pour MCP le 14 avril, un réaménagement de la façon dont les agents IA appellent des APIs qui ramène l'empreinte en jetons de l'exposition de l'API Cloudflare complète de plus d'un million de jetons à environ mille. L'affirmation mérite d'être prise au sérieux, parce que le patron MCP par défaut (définir chaque endpoint comme un outil, pousser ces définitions dans la fenêtre de contexte du modèle) s'effondre vraiment à grande échelle. Si l'API Cloudflare toute seule consommait plus d'un million de jetons (plus que n'importe quelle fenêtre de contexte actuelle), juste pour décrire les outils qui existent, chaque grosse API SaaS frappe le même mur.
Code Mode remplace l'approche « des milliers d'outils » par exactement deux outils : search() pis execute(). search() laisse le modèle interroger un SDK typé pour trouver les méthodes pertinentes. execute() exécute le code écrit par le modèle contre ce SDK à l'intérieur d'un Worker dynamique Cloudflare en bac à sable. Au lieu que le modèle choisisse un outil pré-défini par étape, il écrit un petit script qui enchaîne des opérations, roule le script, pis inspecte le résultat. L'effet net, c'est une empreinte en jetons fixe pour toute la surface d'API, peu importe que la passerelle soit devant un service ou cinquante. Les tests indépendants de WorkOS rapportent une réduction de 81 % des jetons dans leur scénario ; le blog de Cloudflare revendique 99,9 % sur l'API Cloudflare spécifiquement. Les deux chiffres peuvent être vrais. Ça dépend de ce à quoi tu compares pis de la fraction d'outils utilisée par session.
Le patron dépasse Cloudflare. N'importe qui qui bâtit des intégrations MCP pour de grosses APIs frappe le même plafond : plus t'exposes d'endpoints, plus tu brûles du contexte avant que l'agent ait fait quoi que ce soit. Code Mode, c'est vraiment « donne à l'agent un REPL pis un SDK », une approche que le monde Python reconnaît depuis que les idées de notebook-comme-interface-d'agent ont commencé à circuler il y a deux ans. Cloudflare l'a livré en premier parce qu'ils ont déjà un runtime en bac à sable (Workers) pour exécuter du code non fiable en sécurité. Tous les autres vont avoir besoin d'une histoire de bac à sable avant de pouvoir livrer le même patron. Attends-toi à Vercel, Fly, Render pis les grands nuages qui vont sortir des capacités similaires dans les six prochains mois, pis à une année de débats sur les arguments de sécurité à propos de ce que l'isolation en bac à sable garantit vraiment.
Si tu bâtis ou opères des serveurs MCP, il y a deux gestes actionnables. Premièrement, audite ton coût en contexte : combien de jetons ta liste d'outils consomme avant que l'agent ait fait quoi que ce soit ? Si la réponse est plus que quelques milliers, t'as un problème de scaling qu'un modèle plus gros ne réglera pas tout seul. Deuxièmement, demande-toi si ta surface d'API peut être représentée comme un SDK typé plutôt que comme une liste plate d'outils. Pour les APIs REST avec des dizaines à des milliers d'endpoints, le patron Code Mode, c'est probablement la bonne direction à long terme, même si tu touches jamais Cloudflare spécifiquement. La question plus dure, c'est le bac à sable. Exécuter du code généré par un modèle, c'est un problème de sécurité que toute équipe finit par devoir régler, pis « fais confiance à l'exécuteur Python du fournisseur de modèle » c'est pas une réponse durable quand tes agents touchent des systèmes en production. Code Mode déplace cette conversation de « préoccupation future » à « décision de conception actuelle ».
