Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Cache local de preuves

Statut : mémoire activée par défaut ; RocksDB sur activation explicite

Portée : état actuel

Dernière revue : 2026-09-13

Responsable : runtime ax-code

AX Code utilise par défaut un cache de preuves en mémoire borné, avec une persistance RocksDB facultative à côté de son stockage SQLite existant. SQLite conserve l’historique complet des sessions et les enregistrements de vérification. Le cache contient du texte rendu jetable et des symboles syntaxiques ; il ne change pas les permissions et ne compte pas comme une vérification fraîche.

Le mode mémoire par défaut n’ouvre pas de base RocksDB. Pour activer la persistance dans une installation source, construisez sa prise en charge native et sélectionnez RocksDB explicitement :

pnpm build:native fs
AX_CODE_EVIDENCE_CACHE=rocksdb pnpm run dev

AX_CODE_EVIDENCE_CACHE=memory sélectionne explicitement la réutilisation bornée par défaut dans le processus, sans stockage persistant. En mode RocksDB, une prise en charge native manquante, un verrou de base détenu par un autre runtime, ou un échec du cache revient à la mémoire avec un diagnostic. Les constructions d’extension de système de fichiers standard incluent RocksDB pour une activation explicite. Les constructions de publication vérifient que l’extension empaquetée peut écrire et rouvrir son cache. Les opérations natives s’exécutent hors de la boucle d’événements JavaScript.

Les lectures de texte jusqu’à 1 MiB valident les octets de source actuels et réutilisent la plage rendue lorsque son contenu, son chemin, sa plage et son format correspondent. Les fichiers plus grands, les lectures externes, les répertoires et les pièces jointes n’entrent pas dans le cache de lecture. Les instructions du dépôt et les tampons de lecture de fichier restent en direct. L’extraction syntaxique peut réutiliser des symboles pour une source et une langue identiques ; ces symboles n’établissent pas de références sémantiques ni d’appelants.

Avec l’un ou l’autre mode de cache, les résultats de lecture de texte complète répétés, déjà visibles dans la requête de modèle courante, utilisent une courte référence vers le premier résultat. Les sorties d’outil complètes d’origine restent dans l’historique de session. Le compactage reconstruit la visibilité ; une lecture ultérieure est rendue en entier si sa copie antérieure est absente. Les vues paginées de lecture, de grep et de glob, répétées et identiques octet pour octet, peuvent aussi référencer la première vue complète renvoyée. Chaque référence conserve son pied de troncature d’origine et ses consignes de continuation ; le contenu source omis reste indisponible. Les résultats porteurs d’instructions, média, erreur, rognés par ligne et les résultats partiels non reconnus restent verbatim. Cela change l’entrée du modèle, pas l’historique canonique ni l’exécution des outils, et n’établit pas une réduction de facturation du fournisseur.

Les succès de cache économisent le rendu ou l’analyse ; ils n’éliminent pas les lectures de validation de source ni les appels d’outils demandés par le modèle. Pour regrouper une découverte dépendante en moins d’allers-retours de modèle, activez explicitement l’option existante experimental.read_only_recipes et utilisez read_recipe avec des sélections bornées. Utilisez code_intelligence avec operation: "buildContext" pour une vue structurelle bornée. Aucune de ces options n’est activée automatiquement par le cache.

Lorsqu’il est choisi, le cache persistant vit sous le répertoire de cache normal d’AX Code dans evidence-v1, avec une base distincte par répertoire d’instance de projet. L’admission RocksDB est limitée à 1024 entrées et 32 MiB de valeurs logiques ; l’usage disque physique inclut aussi l’encodage, les journaux et le surcoût de compactage. Les deux modes limitent la réutilisation en mémoire à 128 entrées et 4 MiB de valeurs sérialisées par instance de projet et par processus ; ce n’est pas une limite de RAM totale du processus. Les entrées mémoire sont effacées à la destruction de l’instance et ne survivent pas à la sortie du processus. Les entrées expirent après 24 heures et sont validées à la consultation. L’éviction de capacité peut effacer en lot les entrées natives jetables. Aucune donnée SQLite existante n’est migrée ni remplie rétroactivement.

Pour désactiver à la fois la réutilisation du stockage et la déduplication de l’entrée du modèle, définissez AX_CODE_EVIDENCE_CACHE=off et redémarrez AX Code. Une valeur non définie ou vide utilise la mémoire ; une valeur non vide non reconnue désactive le cache. Redémarrez les runtimes existants pour appliquer le nouveau défaut, et retirez tout forçage explicite rocksdb pour utiliser la mémoire. Les fichiers de cache persistant existants sont conservés. Aucun retour arrière SQLite n’est nécessaire. Arrêtez les runtimes avant de retirer manuellement evidence-v1 ; ne retirez pas les fichiers de verrou RocksDB pendant qu’un runtime utilise le cache.

Pour la qualification native locale après la construction de la fonctionnalité :

cd packages/ax-code
AX_TEST_EVIDENCE_NATIVE=1 AX_TEST_FILES=test/evidence/cache-native.test.ts,test/evidence/cache-eval.test.ts pnpm exec vitest run --retry 0

L’évaluation sur fixture fixe signale séparément les lectures demandées, les succès de rendu, les octets de sortie omis et le temps écoulé. Ce n’est pas un banc de modèle en direct ni une affirmation sur la facturation de jetons du fournisseur.

Lorsque vous signalez un problème, incluez la version d’AX Code, le système et l’architecture, la sortie ax-code doctor, le fait que off ou memory change le comportement, et une tâche reproductible si elle est disponible. Doctor signale le mode demandé et la capacité native ; il ne peut pas déterminer si un autre processus en cours possède le cache du projet. Le repli de verrou ou d’entrées-sorties du projet apparaît dans le journal d’exécution. Aucun retour ni contenu source mis en cache n’est téléversé automatiquement. Les binaires publiés existants n’acquièrent ces défauts qu’après l’installation d’une version mise à jour.