Claude Sonnet 4 prend désormais en charge un contexte de 1 million de tokens

 (anthropic.com)
2 points par GN⁺ 2025-08-13 | 1 commentaires | Partager sur WhatsApp
  • Claude Sonnet 4 d’Anthropic prend désormais en charge un contexte allant jusqu’à 1 million de tokens, ce qui permet de traiter en une seule fois de vastes bases de code ou de nombreux documents
  • Grâce à cette prise en charge étendue du contexte, divers usages deviennent possibles, comme l’analyse de code à grande échelle, le traitement de vastes ensembles de documents et le développement d’agents capables de conserver le contexte
  • Pour les prompts dépassant 200 000 tokens, les tarifs API augmentent, mais il est possible de réduire les coûts grâce au prompt caching et au traitement par lots
  • Les clients Bolt.new et iGent AI ont déjà considérablement amélioré leur productivité et leurs fonctionnalités IA grâce à cette capacité
  • La prise en charge du long contexte de Sonnet 4 est actuellement disponible en bêta sur l’API Anthropic et Amazon Bedrock, et sera bientôt proposée sur Google Cloud

Prise en charge d’un contexte de 1 million de tokens

  • Claude Sonnet 4 via l’API Anthropic prend désormais en charge jusqu’à 1 million de tokens de contexte
  • Cela permet de traiter en une seule requête l’intégralité de plus de 75 000 lignes de code ou plusieurs articles de recherche de façon unifiée
  • La fonctionnalité bêta de contexte à 1 million de tokens est actuellement disponible sur l’API Anthropic et Amazon Bedrock, et Vertex AI de Google Cloud la prendra également bientôt en charge

Un contexte plus long, des cas d’usage élargis

  • Analyse de code à grande échelle : il devient possible de charger en une seule fois l’ensemble d’une base de code (fichiers source, tests et documentation compris), afin de comprendre la structure du projet, d’identifier les relations entre les fichiers et de proposer des améliorations de code fondées sur l’architecture du système
  • Synthèse unifiée de documents : il est possible d’analyser en bloc des centaines de contrats juridiques, d’articles de recherche ou de spécifications techniques, et d’en extraire des insights globaux tout en conservant les relations entre les documents
  • Agents avec maintien du contexte : même au fil de centaines d’appels d’outils et de workflows multi-étapes, il devient possible de développer des agents conversationnels conservant un état cohérent en incluant l’ensemble de la documentation API, les définitions d’outils et l’historique des interactions

Politique tarifaire de l’API

  • Prompts de 200 000 tokens ou moins : entrée à 3 $/million de tokens, sortie à 15 $/million de tokens
  • Prompts de plus de 200 000 tokens : entrée à 6 $/million de tokens, sortie à 22,5 $/million de tokens
  • L’application du prompt caching permet de réduire la latence et les coûts
  • La combinaison du contexte à 1 million de tokens avec le traitement par lots peut permettre jusqu’à 50 % d’économies supplémentaires

Cas d’usage chez les clients

  • Bolt.new

    • Bolt.new intègre Claude à une plateforme de développement web et fait évoluer en profondeur le développement web
    • "Grâce à la fenêtre de contexte de 1 million de tokens de Sonnet 4, les développeurs peuvent désormais gérer des projets plus vastes avec une grande précision"

  • iGent AI

    • Basée à Londres, au Royaume-Uni, iGent AI transforme le contenu des conversations en code exploitable via Maestro, son partenaire IA
    • "Des capacités d’ingénierie logicielle autonome auparavant impossibles deviennent réalisables grâce au contexte de 1 million de tokens de Sonnet 4, ce qui permet de faire tourner des sessions durant plusieurs jours sur de véritables bases de code"

Utilisation et feuille de route

  • La fonctionnalité de long contexte est actuellement proposée en bêta aux clients Tier 4 et aux clients avec tarification personnalisée de l’API Anthropic, avec un élargissement à davantage d’utilisateurs prévu dans les prochaines semaines
  • Elle est également prise en charge sur Amazon Bedrock, et la prise en charge de Google Cloud Vertex AI est prévue prochainement
  • Anthropic prévoit aussi d’introduire le long contexte dans d’autres produits de la gamme Claude
  • Des informations détaillées sont disponibles dans la documentation officielle et la page des tarifs

À lire aussi

1 commentaires

 
GN⁺ 2025-08-13
Avis Hacker News

  • On ressent un besoin urgent que les LLM conservent vraiment bien le contexte dans les tâches professionnelles d’ingénierie logicielle ; les annonces disant qu’un nouveau modèle s’est un peu amélioré sont peu intéressantes en pratique. Mais le facteur décisif reste le prix. C’est bien de pouvoir faire entrer une bonne partie de ma base de code dans la fenêtre de contexte, mais comme le prix a fortement augmenté, je pense qu’il vaut mieux pour l’instant mieux gérer le contexte. Le fait que j’utilise énormément la fenêtre de contexte profite au fournisseur du service, mais j’ai l’impression qu’il faut évaluer séparément dans quelle mesure Sonnet reste réellement focalisé, donc il est difficile d’être certain de la valeur réelle.

    • Le contexte est dans le dépôt, et il faut accepter que le LLM ne pourra jamais toujours avoir tout le contexte nécessaire, surtout pour les gros dépôts qui ne tiennent même pas entièrement sur une seule machine. Pour accomplir une tâche donnée, il faut retirer les informations inutiles afin de rester concentré ; si on met tout, on perd au contraire en focalisation. Autrefois, la taille de la fenêtre était trop petite, et je pense qu’elle l’est encore, mais au final il faut surtout savoir comprendre un dépôt en posant les bonnes questions.

    • Si on met trop de contexte, le risque augmente que le LLM se brouille lui-même. Avec un contexte très long, à force d’avancer sans réinitialisation, il finit par perdre sa concentration.

    • Je pense qu’il faut entraîner l’IA à manipuler uniquement des informations abstraites, et non l’ensemble de la base de code. Les humains non plus ne travaillent pas en gardant tout le code en tête, donc les LLM n’en ont pas besoin non plus.

    • Après avoir travaillé quelques semaines récemment avec Claude Code, j’en suis arrivé à la conclusion que la valeur pratique de l’IA agentique est plutôt négative. Je réessaierai quand même dans 6 à 8 mois.

    • Je pense que l’objectif n’est pas seulement de mettre plus de code d’un coup dans le contexte. Certaines tâches ont bien un minimum de contexte nécessaire, mais un modèle à 1M de contexte demande aussi de nouvelles façons d’injecter les données. La vraie force de ce modèle se situe sur des problèmes de deep dive comme l’exploration itérative à long horizon, l’apprentissage in-context et la reconstruction ; par exemple, il y a des tâches en largeur comme appliquer un changement d’API à 100 fichiers, mais il excelle aussi sur des tâches en profondeur où l’on essaie 15 approches avant de trouver une solution. Sonnet 1M semble particulièrement sans équivalent sur ce second type de travail.

  • Il propose quelques conseils aux utilisateurs de Claude Code qui s’inquiètent de la consommation de tokens :

    1. Rassembler le contexte nécessaire au travail et charger beaucoup de code de la base.
    2. À chaque point d’arrêt logique, appuyer deux fois sur Échap pour revenir à un checkpoint riche en contexte (sans consommer à nouveau ces tokens).
    3. Dire à Claude que « le développeur a terminé la tâche X », l’ajouter au contexte et demander un retour (il pointe davantage de problèmes dans du code écrit par quelqu’un d’autre que dans son propre code). Pour utiliser plusieurs chats en parallèle, on peut rappeler le même fil avec /resume, puis faire un double Échap pour repartir d’un moment riche en contexte et réinitialiser.

    • Il utilise aussi la méthode consistant à dire à Claude : « dans une autre session, tu as écrit la tâche X », puis à exploiter ce contexte pour poser des questions ou demander des modifications.

    • Je fais souvent pareil moi aussi, mais ça ne marche pas toujours bien. Parfois, il est plus utile d’utiliser Claude en conservant tout le contexte de la conversation.

    • La latence diminue fortement. On n’a pas besoin d’attendre qu’un nouveau Claude recharge tout le contexte depuis le début.

    • Ce processus donne l’impression de relever de l’astrologie pour programmeurs (astrogy) ; si on ne le lui dit pas explicitement, on ne sait pas ce qui va se passer quand l’agent travaille sur la base de code.

    • Ce qui est intéressant, c’est de se demander pourquoi Claude trouve plus de problèmes quand on lui présente le code comme s’il avait été écrit par un autre développeur.

  • Jusqu’ici, l’usage le plus utile dans Claude Code a été de demander directement : « Y a-t-il un bug dans le diff actuel ? » Le chatbot analyse alors les changements très soigneusement et détecte rapidement des bugs subtils qui auraient autrement exigé beaucoup de temps et de nombreux déploiements, tout en listant point par point diverses améliorations pour renforcer la justesse du code.

    • Il est étonnant que cela fonctionne comme souhaité sans même devoir demander explicitement de « réfléchir plus profondément ».

    • D’après l’expérience acquise hors des tâches de code aussi, la créativité est limitée, mais ses capacités de relecteur critique et méticuleux sont excellentes.

    • Certains proposent d’implémenter concrètement cette fonction comme un hook de Claude Code.

    • L’auteur dit qu’il va essayer cette méthode dès demain.

  • Mon expérience actuelle avec ces outils est la suivante :

    1. C’est très utile pour démarrer un nouveau langage, framework, utilitaire ou projet greenfield. Ensuite, en parcourant le code, on se demande si on peut vraiment lui faire confiance, mais comme on a de toute façon la flemme de tout interpréter soi-même, on finit souvent par se dire « ça marche, donc allons-y ».
    2. Dans les langages ou frameworks qu’on connaît déjà bien, la productivité baisse au contraire. Le temps passé à écrire un contexte adapté au prompt est similaire, voire supérieur, au temps nécessaire pour coder directement. Dans certains cas précis ça fonctionne, mais on obtient facilement un code ambigu qui donne l’impression d’avoir été écrit par un junior. Une personne peu expérimentée pourrait ne pas voir tout de suite le problème. Je l’ai utilisé en Typescript, Kotlin, Java, C++ pour des sites web, des composants ESPHome, des API backend, des scripts Node et divers environnements ; au final c’est bien pour les loisirs, les scripts et les prototypes, mais encore insuffisant pour du code de niveau entreprise.

    • J’ai eu une expérience similaire moi aussi (Cline + Sonnet & Gemini pendant un an). Puis j’ai découvert Claude Code, et surtout j’ai appris à vraiment bien gérer le contexte, et là j’ai senti une vraie percée. La clé est de traiter l’IA non comme un générateur de code, mais comme un architecte et implémenteur. Récemment, je commence toujours par demander à CC de rédiger le document de conception de la tâche à réaliser, puis je lui demande de s’appuyer sur le code et ce document. Je relis cela pour valider clairement la direction voulue, puis je découpe le travail en chunks, eux-mêmes subdivisés. Une fois la définition initiale terminée, j’efface le contexte, je lui fais relire la doc étape par étape, puis je lui fais implémenter. Si nécessaire, j’ajuste la direction des modifications ou je corrige le document, puis je relance seulement cette étape. À chaque étape : commit, effacement du contexte, étape suivante. De cette manière, des fonctionnalités qui prenaient autrefois 2 à 3 jours peuvent être livrées en une journée. On obtient au final un résultat bien cadré, avec documentation validée, tests unitaires, Storybook, accessibilité (arai, etc.) et le reste. Et à la fin, je fais aussi relire le code par un autre modèle. Même si on n’atteint pas encore une vitesse écrasante aujourd’hui, je vois cela comme un investissement d’avenir dans ses compétences, en prévision d’outils qui continuent de progresser.

    • À mon avis, cet outil rappelle le scaffolding de rails new à l’époque de Ruby on Rails. Les LLM sont parfaits pour créer l’ossature initiale d’un projet, là où il suffit surtout de bien comprendre la documentation officielle des outils. En revanche, ils sont moins utiles pour les systèmes legacy ou les projets avec beaucoup de contraintes externes. Pour des outils qui évoluent vite comme Databricks, c’est presque inutile. Si les noms, la syntaxe ou les fonctionnalités ont changé après les données d’entraînement, il faut absolument injecter activement la documentation en temps réel dans le prompt pour avoir une chance que ça marche.

    • Mon workflow combine Claude Desktop et le système de fichiers d’un serveur MCP. J’indique à Claude les chemins des fichiers concernés et je lui demande de résoudre la tâche. Claude lit alors directement les fichiers, les analyse et effectue les modifications ou ajouts nécessaires. En général, il me suffit de copier-coller quelques erreurs de build et il corrige de nouveau. Le fait qu’il écrive du nouveau code en conservant exactement le style du code existant est aussi impressionnant. Je l’ai utilisé en Typescript et en C# ; d’après mon expérience, le résultat ne se limite pas à un niveau hobby.

    • Je ne suis pas programmeur, mais j’ai besoin de code Python et bash dans mon travail. Je gère aussi quelques projets personnels et sites web. Grâce à Claude Code, j’ai pu réaliser de petits projets que je ne pouvais pas faire avant par manque de compétences et de temps. Je peux maintenant même améliorer moi-même mon environnement emacs. Il me génère aussi des fonctions lisp sans difficulté. Pour moi, c’est l’outil parfait : il débloque des choses qui me bloquaient auparavant et rend la vie plus facile.

    • Je l’ai utilisé en Typescript, Go, SQL et Rust. Rust était trop complexe et rempli d’erreurs, et j’ai envie de finir vite le projet (même si le projet lui-même est déjà très difficile). Go est tellement simple comme langage que c’est extrêmement productif : vitesse multipliée par deux. En Typescript, c’est correct pour les composants React et les animations. Pareil pour SQL/PostgreSQL. Je déteste le boilerplate des procédures stockées, et le LLM m’en retire une partie, ce qui soulage mes poignets.

  • C’est clairement une bonne chose d’avoir autant d’options, mais en même temps, si on injecte beaucoup de contexte, la qualité des résultats du LLM peut baisser, car il devient plus facile pour lui d’être distrait. Si les utilisateurs ne comprennent pas ce compromis et se reposent uniquement sur le mode automatique, je m’inquiète de la qualité du code produit avec Claude Code.

    • Il donne quelques liens de lecture utiles

    • Pour l’instant, le long contexte n’est pas encore intégré à Claude Code. Ils disent « étudier des moyens d’appliquer le long contexte à d’autres produits ». J’imagine qu’ils ont déjà identifié le problème et cherchent comment le résoudre. Ils semblent vouloir proposer une solution avant que les utilisateurs ne génèrent trop de coûts supplémentaires sur les offres les plus chères.

    • Quelqu’un demande ce qui est recommandé comme alternative. Il commence à prendre ses habitudes avec Claude Code, mais n’est pas encore à l’aise avec les bonnes pratiques.

    • L’équipe Chroma étudie le problème et des données chiffrées devraient arriver.

  • Quelqu’un demande si Opus n’est pas meilleur, en disant sentir une grosse différence quand il est forcé de basculer sur Sonnet parce qu’il n’a plus de tokens. Avec plus d’expérience, beaucoup d’idées mais des difficultés en code, il explique que depuis l’arrivée de Claude, il va à toute vitesse autant pour implémenter ses idées que pour les tester et corriger les bugs.

    • Mais il s’inquiète aussi qu’à force de trop dépendre de Claude Code, ses compétences réelles de développement finissent par se dégrader.

  • Le gros problème des chat apps (ChatGPT, Claude.ai), ce sont les comportements bizarres liés à la fenêtre de contexte (coupures soudaines, résumés, réinsertion de « snippets fantômes », etc.). Il serait plus pratique que l’utilisateur puisse choisir lui-même de conserver le contexte ou de démarrer un nouveau chat, mais en pratique les offres tarifaires et les limites de calcul l’empêchent. En réalité, il faut utiliser des outils développeur (Google AI Studio) ou des chat apps encapsulant l’API pour pouvoir envoyer intégralement tout le contexte. Si on construit une chat app personnalisée, on peut aussi insérer un horodatage dans chaque message et demander au LLM de « résumer le contenu de cette période dans une nouvelle ligne d’un tableau Markdown toutes les 10 minutes ».

    • Une autre suggestion dit qu’au lieu d’un découpage par temps, il vaudrait mieux un découpage « par message », par exemple « faire un résumé dans blah-blah.md tous les 10 messages ».

  • J’ai l’impression que cette offre tarifaire est le premier cas où l’on reconnaît explicitement que le coût augmente presque de manière « quadratique » avec le nombre de tokens. On dirait que le fournisseur de LLM reflète pour la première fois une structure tarifaire non linéaire. Cette approche ressemble aux lois de scaling d’inférence que nous connaissons déjà.

  • Il signale aussi une discussion sur un sujet connexe

  • Cette fonctionnalité est impressionnante, mais je me demande comment améliorer la vitesse de raisonnement. Personnellement, 200K de contexte me suffisent, et j’aimerais surtout que la réponse soit plus rapide. Je pense que beaucoup de gens seraient satisfaits même avec un contexte plus petit si l’agent travaillait beaucoup plus vite (actuellement il faut attendre 2 à 3 minutes par prompt).