intro handled in meta - body only

Chaque fois qu'un agent de code exécute git status, pytest, docker compose ou kubectl get pods, le modèle reçoit la sortie complète. Ces journaux sont souvent longs, répétitifs, et n'apportent qu'une fraction d'information utile pour décider la suite. Le contexte se remplit, la latence augmente, et la facture suit.

Navin compacte automatiquement ces sorties avant qu'elles n'entrent dans le contexte du modèle. Aucun proxy externe, aucun binaire à installer : la compaction est intégrée à l'outil exec de l'application locale.

D'où viennent les tokens d'un agent

Une requête agent n'est pas limitée à votre message. À chaque tour, le modèle reçoit en général :

1. les instructions système et les règles du projet ;
2. les schémas d'outils ;
3. l'historique de la session ;
4. la sortie de la dernière commande shell.

Les trois premiers blocs se répètent souvent d'un tour à l'autre et bénéficient du prompt caching lorsqu'il est disponible. Le quatrième change à chaque commande. Un npm install verbeux ou un kubectl describe verbeux pèse donc directement sur le coût et sur la fenêtre de contexte.

C'est pourquoi une session de debug peut consommer plusieurs millions de tokens pour quelques dizaines de requêtes, même si vos consignes restent courtes.

Ce que fait la compaction

Compacter ne signifie pas masquer les erreurs. L'objectif est de conserver le signal utile et de retirer le bruit :

• barres de progression et séquences ANSI ;
• colonnes secondaires dans docker ps ou kubectl get ;
• événements peu informatifs dans un describe ;
• longs blocs de tests verts lorsque seuls les échecs comptent ;
• progression Git sans valeur pour la décision suivante.

Navin identifie la famille de commande (git, tests, Kubernetes, install…), applique un filtre adapté, puis expose au modèle une version courte. Lorsque la réduction est significative, le journal complet reste disponible sous .navin/tool-results/exec/.

Couverture

Les wrappers du type bash -lc '…' sont résolus pour classer la commande réelle.

Comportement dans le travailbench

Vous gardez une lecture claire dans le terminal ; le modèle reçoit la version compactée une fois le résultat finalisé. Documentation produit : Command output compaction.

Impact sur le coût

La compaction ne retire pas le system prompt, les schémas d'outils ni l'historique. Elle agit sur la part la plus volatile : les sorties de commandes. Pour les quotas Free face aux budgets d'abonnement, voir modèles gratuits et abonnements.

Avec les autres leviers Navin

Le cache de réponses HTTP (corps de réponse identiques) n'est pas pertinent pour un agent : chaque tour a un corps différent.

FAQ

Les erreurs importantes sont-elles conservées ?

Oui. Les filtres privilégient échecs, findings et status utiles. Le journal brut reste sur disque lorsque la compaction s'applique.

Faut-il activer une option ?

Non. C'est le comportement par défaut de exec dans Navin.

Kubernetes et Docker sont-ils couverts ?

Oui, notamment kubectl, oc, helm, et les commandes docker/podman courantes (ps, logs, compose).

Cela remplace-t-il le prompt caching ?

Non. Le caching porte sur le préfixe stable ; la compaction porte sur les sorties variables.

Comment récupérer la sortie complète ?

Via le fichier indiqué dans la note [compacted…] sous .navin/tool-results/exec/.

Pour aller plus loin

1. Téléchargez Navin.
2. Ouvrez un projet dans le module Code.
3. Laissez l'agent exécuter git, tests ou docker : la compaction s'applique seule.

Télécharger Navin · Fonctionnalités · Documentation