Les passerelles OpenClaw longue durée sur un Mac mini macOS 24/7 accumulent du contexte plus vite que ne le prévoient les tableurs : chaque fil Slack ajoute des transcriptions d’outils, chaque commande en échec retente avec un stderr verbeux, et chaque aperçu de pièce jointe gonfle des blobs base64 dans l’état de conversation. Vers la troisième semaine, les opérateurs voient une latence p95 au-dessus de 8 secondes alors que le CPU reste sous 45 % : le fournisseur de modèle ingère des mégaoctets de texte redondant, il ne « calcule » pas davantage. Ce guide opérationnel explique comment élaguer la mémoire de conversation, borner la sortie des outils, aligner les plafonds de jetons par tour sur les limites annoncées par le fournisseur et répéter les changements sur du matériel réel. Croisez-le avec budget jetons et limitation d’outils OpenClaw (FR), profils JSON et variables d’environnement OpenClaw sur Mac cloud, et OpenClaw Doctor et diagnostic passerelle (FR) afin que les politiques d’élagage ne contredisent jamais vos tables d’auth ou de routage.
Vous obtiendrez une matrice de décision, des ordres de grandeur initiaux (caps de jetons, fenêtres de rétention, tailles de rotation des journaux), les pièges spécifiques à macOS et une FAQ orientée ingénieurs plateforme.
Signaux indiquant que la mémoire est le goulot
Un temps jusqu’au premier jeton qui augmente alors que CPU et GPU restent bas signale en général des prompts surdimensionnés. Un autre indice : des pics d’écriture disque toutes les 90 secondes lorsque la passerelle instantanise des fils entiers — même les canaux inactifs coûtent de l’argent.
Compteurs utiles côté finance : moyenne de jetons de prompt par tour, octets stdout d’outil ajoutés par heure, pourcentage d’espace libre sur le volume racine, tickets rouverts étiquetés « l’assistant a oublié une décision antérieure ». Sans ces quatre séries, vous ne pouvez pas prouver qu’un changement d’élagage a aidé.
Lors d’un incident, figez les fonctionnalités : instantané de transcriptions expurgées montrant des charges d’outil dupliquées, puis retour arrière sur la dernière modification de résumé automatique.
Documentez les hausses temporaires de rétention « brise-vitre » avec identifiants de ticket ; sinon les équipes désactivent l’élagage en silence pendant les lancements et s’étonnent que la facture mensuelle double.
Le support doit noter si les ralentissements surviennent sur le premier message de la journée ou seulement après de longs fils : le premier cas pointe vers une mauvaise configuration de démarrage à froid, le second vers des trous dans l’élagage.
Matrice : résumé automatique vs troncature dure
| Stratégie | Qualité | Coût | Risque |
|---|---|---|---|
| Résumé LLM tous les N tours | Continuité élevée | Appels modèle supplémentaires | Les résumés peuvent perdre des chiffres critiques pour la conformité |
| Troncature dure avec faits système épinglés | Moins cher | Faible surcharge de jetons | Les utilisateurs perçoivent de l’« oubli » si les épingles sont incomplètes |
| Hybride : ne résumer que le bruit des outils | Équilibré | Moyen | Exige une redaction consciente du schéma |
L’hybride l’emporte en 2026 pour la majorité des équipes : conserver décisions utilisateur et identifiants de ticket textuellement, compresser les journaux shell bruyants au-delà de 4 Kio par appel d’outil.
Valeurs par défaut qui survivent aux audits
Réglages initiaux : garder les 30 derniers tours visibles utilisateur textuellement, résumer l’historique plus ancien en notes à puces ≤ 900 jetons, plafonner tout aperçu de pièce jointe d’outil à 64 Kio avant base64, et refuser les nouvelles pièces lorsque l’espace libre tombe sous 12 %.
Limiter le nombre total de tâches de résumé concurrentes à 3 pour que le résumé automatique n’affame pas les réponses interactives.
Lorsque les fournisseurs publient des fenêtres de maintenance, baissez préventivement la fréquence de résumé de 50 % à partir de 15 minutes avant l’ouverture — cela évite de chevaucher compaction et incidents fournisseur.
Red-team avec des fichiers de rejouage contenant des fils de 200 tours ; si plus de 2 % des sessions synthétiques perdent des faits de conformité épinglés, votre prompt de résumé fuit encore.
Versionnez les tables d’élagage dans Git ; l’astreinte ne doit jamais deviner quelles constantes étaient actives pendant un incident.
Disques macOS, LaunchAgents et journaux
Les tâches launchd qui écrivent des transcriptions verbeuses dans ~/Library/Logs peuvent épuiser des conteneurs APFS plus vite que ne l’anticipent les équipes habituées à ext4 sous Linux. Faites tourner les journaux à 256 Mio par fichier avec 5 générations conservées.
Combinez l’élagage avec des limites locales de fork — voir le guide de limitation et de budget jetons pour les plafonds de concurrence qui empêchent les workers de résumé de fork indéfiniment.
Si l’achat matériel traîne, louez un Mac mini cloud pour répéter la compaction : les hôtes Apple silicon MacHTML s’affichent couramment autour de 16,9 $/jour avec SSH/VNC pour capturer pression disque et latence en direct.
Après modification des constantes d’élagage, redémarrez le LaunchAgent de la passerelle et vérifiez que les variables d’environnement sont synchronisées sur chaque chemin plist documenté dans les profils JSON et d’environnement.
Exécutez des sondes doctor après déploiement : validez la santé RPC avant de clore le déploiement de compaction.
Expérience canal pendant l’élagage
Les utilisateurs Slack et Teams tolèrent le résumé lorsque le texte explique le pourquoi. Émettez une note modèle lorsque la compaction supprime plus de 40 % des jetons bruts, avec lien vers une FAQ interne sur la rétention.
Les chefs de produit demandent souvent une « mémoire infinie ». Traduisez en budgets explicites : montrez le coût en dollars par 1 000 jetons de prompt supplémentaires en moyenne hebdomadaire, puis proposez un bloc de faits épinglés qui survit au résumé. Les équipes qui adoptent ces épingles voient environ 18 à 28 % de dépense mensuelle en moins sans baisse mesurable de satisfaction dans les enquêtes internes.
Pour les bots publics, ajoutez une courte ligne « mémoire actualisée » après compaction afin que l’utilisateur sache qu’un long texte juridique peut nécessiter une reconfirmation — surtout dans les secteurs réglementés où les chaînes de consentement doivent rester textuelles.
Évitez de renvoyer le stderr brut des outils dans les canaux après élagage : cela peut ressusciter des secrets pourtant redactés.
Lorsque des équipes multilingues partagent une passerelle, localisez les avis de résumé selon l’en-tête de locale du workspace.
Throttez les indicateurs de frappe pour que les clients n’inondent pas d’événements pendant les jobs de résumé — ces événements amplifient la charge fournisseur.
Télémétrie et métriques « finance-friendly »
Exportez des histogrammes de jetons de prompt avant et après élagage — une divergence inférieure à 25 % signale en général un résumé silencieusement défaillant.
Étiquetez chaque exécution de compaction avec le SHA Git de votre prompt de résumé afin que la finance relie les pics de facture aux modifications de prompt plutôt qu’au fournisseur par défaut. Lorsque les pics dépassent 12 % semaine sur semaine, ouvrez une revue blameless sous 48 heures tant que les journaux bruts sont encore là.
Alertez lorsque l’espace libre reste sous 15 % plus de 10 minutes ; appelez l’infra avant que la passerelle bloque les écritures en pleine compaction.
Conservez des journaux d’audit structurés 90 jours avec identifiants de corrélation liant messages utilisateur et versions de compaction.
Tableau de bord : taux de succès « première tentative répondue » aux côtés des moyennes de jetons de prompt, pour que le produit n’optimise pas la latence en faisant exploser le coût.
Chaque trimestre, examinez manuellement 35 des fils les plus longs ; le bucketing automatique étiquette encore les ralentissements fournisseur comme des bugs mémoire locaux.
Sécurité lorsque l’on supprime du contexte
Ne journalisez jamais des prompts entiers avec des marqueurs de compaction — les bundles d’incident ne doivent stocker que des identifiants de conversation hachés. Redactez les clés API des dumps de debug même lorsque l’équipe est fatiguée à 3 h du matin.
Les auditeurs RGPD et SOC2 demandent souvent comment vous prouvez que les utilisateurs ont été informés avant un élagage destructif ; gardez bannières et horodatages de consentement dans le même index d’audit que les jobs de compaction.
Faites tourner les clés fournisseur partagies après toute fuite suspectée, et resserrez temporairement la concurrence de résumé jusqu’à ce que les nouvelles clés se propagent à chaque plist LaunchAgent.
Scripts de pen-test qui martèlent les points de terminaison « résumer maintenant » : assurez authentification et limites de débit pour qu’un attaquant ne transforme pas la compaction en épuisement CPU.
Enfin, répétez le basculement : instantané du magasin de fils sur disque, simulez une compaction interrompue en écriture, vérifiez que la passerelle refuse de démarrer plutôt que de servir un historique partiellement tronqué. Ce seul exercice évite la pire classe de tickets support où les utilisateurs voient des réponses incohérentes après un déploiement nocturne.
FAQ
L’élagage doit-il tourner à chaque message ou chaque heure ?
À chaque message pour les canaux chargés ; horaire pour les espaces calmes afin d’éviter la turbulence.
L’élagage remplace-t-il les throttles ?
Non — combinez les deux couches.
Pourquoi répéter sur un Mac mini physique ?
La planification macOS, la pression disque et le comportement du Trousseau diffèrent du CI Linux.
Le matériel Mac mini Apple Silicon reste la plateforme de répétition la plus fidèle pour les politiques mémoire OpenClaw : thermiques prévisibles pendant de longues captures, comportement natif du système de fichiers pour la rotation des journaux, et temporisation LaunchAgent alignée sur la production. MacHTML loue des Mac mini cloud avec SSH/VNC afin que les équipes plateforme valident élagage, throttles et sondes doctor sans nouveau cycle CapEx — provisionnez pour l’exercice, capturez la preuve, retirez la machine quand le feu est vert.
Répéter les politiques mémoire OpenClaw sur Mac mini cloud
Louez de la capacité Apple Silicon pour tester l’élagage des transcriptions, la rotation des disques et les contrôles doctor sur macOS réel.