Cursor 3.3 expose ce qui mange votre contexte d'agent

Le 6 mai, Cursor a poussé la version 3.3 de son IDE¹. La nouveauté qui compte tient en une phrase : on peut désormais cliquer sur l'anneau de contexte d'un agent et voir, ligne par ligne, ce qui consomme vraiment l'espace dont il dispose pour réfléchir. Rules, skills, MCP, subagents : chaque bucket est affiché avec sa part. Ça n'a l'air de rien. Pour qui pilote des agents en production, c'est l'outil qu'on demandait depuis des mois.

Le problème qu'on sentait sans pouvoir le pointer

Depuis un an, le quotidien d'un builder qui shippe avec un IDE agentique ressemble à ça. On ajoute une règle de projet pour cadrer une convention. On installe un MCP pour brancher la base. On définit un skill pour automatiser une vérification récurrente. On lance deux subagents pour paralléliser. Au bout de quelques semaines, l'agent répond plus lentement, fait plus d'erreurs sur les petits détails, oublie des consignes qu'on croyait verrouillées.

La cause, dans la plupart des cas, n'est pas le modèle. C'est le contexte qui sature en silence. Ce phénomène a un nom dans la communauté builders : le context bloat. Le forum Cursor en parlait depuis avril, avec des demandes explicites de visualisation du contexte qui empilaient les votes². Anthropic l'a évoqué dans son rapport agentic coding du 1er mai, sans donner de méthode. Tout le monde sentait le problème, personne ne pouvait le mesurer.

Ce que le breakdown change concrètement

L'écran de Cursor 3.3 affiche pour chaque agent la répartition du contexte par catégorie. Un utilisateur du forum, Naufaldi Rafif, a publié dès le 7 mai un retour qui résume tout : son skill consomme une part disproportionnée du budget². Avant 3.3, il ne pouvait pas le savoir. Le skill marchait, l'agent rendait des résultats, mais une partie significative de la fenêtre partait dans une instruction dont la valeur marginale était faible.

Cette visibilité change la discipline. Un MCP qui charge mille schémas alors que l'agent en utilise dix devient mesurable. Un skill qui s'autodécrit sur cinq cents lignes au lieu de cinquante apparaît à l'œil nu. Une règle bavarde qui aurait pu tenir en une phrase se voit aussitôt. On passe de l'intuition au diagnostic.

Pourquoi c'était le grand absent de l'agentic coding

Dans l'article du 1er mai sur le rapport Anthropic 2026 sur l'agentic coding, on pointait que le context engineering restait le sujet qu'aucun outil ne traitait sérieusement. La théorie était partout. Choisir ce qui entre dans la fenêtre. Élaguer ce qui ne sert plus. Structurer l'information pour que le modèle la trouve quand il en a besoin. La pratique, elle, se faisait à l'aveugle. On éditait un fichier .cursorrules ou un CLAUDE.md et on espérait que le modèle reste concentré.

Le breakdown ne résout pas tout. Il ne dit pas si un bloc de contexte est utile, il dit seulement combien il coûte. Mais la mesure précède toujours l'optimisation. On a passé deux ans à entendre que les tokens d'inférence devaient être comptés. Les tokens de contexte devront l'être aussi.

Le mouvement parallèle côté capacité

Le même 6 mai, Anthropic a annoncé le doublement des limites cinq heures de Claude Code pour les plans Pro, Max, Team et Enterprise, ainsi qu'une hausse substantielle des limites API sur les modèles Opus³. Le levier est différent : Anthropic ouvre les vannes côté capacité brute grâce à un accord avec SpaceX pour le datacenter Colossus 1 et ses 220 000 GPU⁴. Cursor, lui, instrumente côté frugalité.

Les deux mouvements visent le même plafond. Quand un agent atteint ses limites, deux explications coexistent. Le quota est trop bas, ou le contexte est trop chargé. La semaine du 6 mai a apporté une réponse à chaque cause. Le builder qui sait ce qu'il consomme et combien il peut consommer a deux nouveaux leviers de décision qu'il n'avait pas une semaine plus tôt.

Ce qu'on retient au studio

La discipline va probablement devenir un critère de séniorité tacite. Celui qui sait écrire des rules courtes et précises, des skills qui ne se répètent pas, des configurations MCP filtrées plutôt qu'exhaustives, livrera des agents plus stables que celui qui empile par confort. On a connu ce moment pour les bundles JavaScript et pour les requêtes SQL. Le contexte d'agent vient de rejoindre la liste.

Sources