La compaction avec perte du contexte dans Claude Code me fait penser à la même erreur que j’ai commise l’année dernière avec Busy4, quand j’ai remarqué des ralentissements sur des fenêtres de contexte énormes. Mes sessions duraient des jours et finissaient par ramper.
Pour régler ça, j’ai créé une fenêtre de contexte glissante avec vectorisation dirigée par l’agent. Il s’avère que Claude Sonnet était tout à fait capable de le faire. Pour y arriver, mes premières implémentations utilisaient des variantes de SQLite, PSQL, Mongo et Redis, mais la manière de stocker les vecteurs importe peu.
Le vrai déclic est venu quand j’ai fait tourner le client Busy avec Gemini, et que j’ai remarqué comment Gemini gérait l’appariement interne du contexte. Par exemple, avec Gemini, on s’aperçoit que peu importe la longueur de la fenêtre de contexte, il arrive toujours à se souvenir du début de la conversation.
Autre bizarrerie : Gemini semble se souvenir des numéros d’ID d’entrée du contexte quand on lui parle, ce qui m’indique qu’il y a des appels d’outils en arrière-plan pour fouiller dans la mémoire au sein d’une session.
J’ai donc implémenté ça en JavaScript puis en Go, ce qui est assez simple dans les deux cas, et j’ai développé une stratégie universelle. Ça devrait aussi marcher en TypeScript.
Les modèles Claude hallucinent et s’embrouillent si les appels d’outils sont gérés sans étiquetage clair. C’est peut-être pour ça que Claude Code se rabat sur la compaction avec perte.
Sauf que la solution, c’est l’étiquetage (succès et échec, avec permission de continuer).
C’est comme ça qu’on garde le client réactif et à jour. Étant donné les contraintes du framework de Claude Code.
J’aimerais voir ça implémenté pour qu’on n’ait plus à se taper cette compression avec perte à la Cursor. Claude accepte le schéma si on lui explique.
Mes logs concernant le "Panda Protocol" devraient fournir des détails d’implémentation remontant à environ 18 mois.