FR: Passerelle de surveillance de restauration de configuration : combiner les contrôles de santé avec la restauration automatique
Un utilisateur de Reddit sur r/openclaw propose un mécanisme pour empêcher la passerelle OpenClaw de rester bloquée dans une boucle de démarrage en raison de modifications de configuration erronées. L'idée combine un chien de garde avec un retour automatique à la configuration précédente — le tout implémenté en dehors d'OpenClaw lui-même.
Comment ça marche
- Un chien de garde surveille la réactivité du port de la passerelle.
- Si le port devient non réactif, le chien de garde redémarre automatiquement la passerelle.
- Si la passerelle ne parvient pas à démarrer 5 fois de suite, le chien de garde restaure la configuration précédente connue comme bonne avant de tenter un nouveau redémarrage.
Cela garantit qu'une mauvaise modification de configuration ne rende pas la passerelle définitivement inutilisable. Le retour en arrière se fait de manière externe, donc la logique de démarrage propre à OpenClaw reste inchangée.
Pourquoi c'est important
Les utilisateurs rapportent qu'OpenClaw modifie parfois sa propre configuration, ce qui fait échouer la passerelle au prochain démarrage. Un simple chien de garde de redémarrage boucle indéfiniment si la configuration est cassée. Ajouter un compteur d'échecs avec retour automatique à la configuration précédente brise la boucle.
L'auteur demande à la communauté : « Avez-vous de tels mécanismes ? Peut-être de meilleurs ? »
C'est une approche pratique et peu coûteuse pour les passerelles de production où la disponibilité est primordiale. Le modèle de chien de garde externe signifie qu'il peut être implémenté avec systemd, les healthchecks Docker ou un script personnalisé — pas besoin de modifier les composants internes d'OpenClaw.
📖 Lire la source complète : r/openclaw
👀 See Also
Correction de la vitesse de traitement des prompts dans Llama.cpp à l'aide du paramètre --ubatch-size
Un utilisateur a découvert que le réglage de --ubatch-size pour correspondre à la taille du cache L3 du GPU (64 Mo pour la Radeon 9070XT) a considérablement amélioré la vitesse de traitement des invites pour les modèles plus volumineux comme Qwen 27B dans Llama.cpp, rendant l'invocation de code Claude utilisable.
Claude n'est pas mauvais en codage — c'est votre configuration de contexte qui l'est
Après des mois d'utilisation de Claude, un développeur soutient que les échecs viennent de la façon dont vous structurez le contexte, pas du modèle lui-même. Améliorations clés : séparer les instructions de la logique, réduire le bruit contextuel et utiliser des motifs stables.
Sources de données de Claude : Quand demander des recherches web pour des informations actuelles
Claude s'appuie parfois sur des données d'entraînement internes plutôt que d'effectuer des recherches web, ce qui peut fournir des informations obsolètes. Les utilisateurs peuvent demander spécifiquement des recherches web pour obtenir des résultats plus récents.
Claude CLI v2.1.154 brise le vLLM local — un correctif d'une ligne le répare
Claude CLI ≥2.1.154 ajoute trois nouveaux rôles API (ctx, msg, system) qui cassent la compatibilité avec les serveurs vLLM locaux. Un correctif d'une ligne dans le protocole Anthropic de vLLM rétablit la compatibilité.