intro handled in meta - body only

Sur un agent de développement, une grande part du prompt se répète d'un tour à l'autre : instructions système, descriptions d'outils, règles projet, mémoire partagée. Sans prompt caching, ce préfixe est renvoyé et refacturé à chaque requête. Avec le caching, le provider facture surtout le delta : nouveau message, nouvelles sorties d'outils, fin d'historique.

Navin active le prompt caching pour les providers qui le supportent (routes gérées, Anthropic, et passerelles compatibles). Il se combine naturellement avec la compaction des sorties shell.

Définition

Le provider mémorise un préfixe stable de la requête. Les tours suivants qui recommencent par le même préfixe coûtent moins cher (et sont souvent plus rapides) sur la portion mise en cache.

Il ne s'agit pas d'un cache de réponses toutes faites. C'est un cache de contexte d'entrée.

Prompt caching et cache de réponses

Navin s'appuie sur le prompt caching. Le cache de réponses HTTP n'est pas utilisé pour l'agent : après une lecture de fichier ou un test, la requête suivante n'est presque jamais bytes-identique.

Ce qui est mis en cache

Selon le provider, Navin marque les blocs éligibles (cache_control ou équivalent déclaré) :

• instructions système et politiques ;
• descriptions d'outils ;
• portions stables de contexte projet injectées à chaque tour.

Restent hors cache ou en fin de prompt :

• le dernier message utilisateur ;
• les derniers résultats d'outils (d'où l'intérêt de les compacter) ;
• l'historique qui s'allonge.

Pourquoi c'est décisif dans un IDE agent

Un chatbot léger a un system prompt court. Un IDE comme Navin envoie régulièrement :

• un large catalogue d'outils (Code, git, board, Vision 360…) ;
• des modes et workflows (Agent, Plan, Revue…) ;
• la mémoire projet (Project Brain).

Sans caching, chaque « continue » republie ce préfixe. Avec caching, la facture suit surtout le travail nouveau du tour.

Quand le gain est maximal

• Sessions longues, nombreux tours, même modèle et même jeu d'outils.
• System prompt et outils stables pendant la session.
• Moins efficace si vous changez de preset ou de modèle à chaque message.

Le caching traite le préfixe ; la compaction traite les sorties d'outils. Les deux se complètent sur les sessions riches en shell.

Vérifier que c'est actif

1. Choisissez un modèle / provider qui annonce le prompt caching.
2. Enchaînez plusieurs tours sans changer de modèle ni de jeu d'outils.
3. Consultez l'usage provider (tokens en cache / cache hit selon le tableau de bord).

Sur Free, le caching n'annule pas les rate limits ; il réduit surtout le coût lorsque la facturation au token s'applique. Aucun interrupteur « activer le cache » n'est requis dans Navin pour les providers supportés : c'est le chemin d'appel normal.

Pièges courants

• Confondre cache de réponses et prompt caching.
• Attendre une baisse massive sur Free alors que la limite est en requêtes.
• Changer de modèle trop souvent et invalider le préfixe.
• Laisser passer d'énormes journaux shell : même avec un préfixe en cache, le suffixe outil reste coûteux.

FAQ

Le prompt caching est-il déjà disponible dans Navin ?

Oui, pour les providers qui le déclarent.

Faut-il configurer un en-tête spécial ?

Non pour l'usage courant. Navin applique les marques de cache selon le provider.

Fonctionne-t-il avec les modèles gratuits ?

Lorsque le provider Free expose le caching, oui. Sinon, le bénéfice porte surtout sur les modèles payants et les budgets gérés.

Remplace-t-il la compaction des commandes ?

Non. Caching = préfixe stable. Compaction = sorties variables.

Peut-on forcer un cache de réponses HTTP ?

Ce n'est pas le mécanisme retenu pour l'agent Navin.

Suite

1. Téléchargez Navin et travaillez en session continue sur un même modèle.
2. Laissez le prompt caching amortir le préfixe.
3. Comptez sur la compaction exec pour les sorties shell.

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