Résultats des tests A/B : Les hooks oh-my-claudecode montrent un impact minimal sur les performances de Claude Code.
Configuration et méthodologie de l'expérience
Un développeur a réalisé un test A/B simple pour évaluer l'impact des crochets dynamiques oh-my-claudecode sur les performances de Claude Code. L'expérience a utilisé Claude Sonnet 4.6 avec la même tâche de programmation exécutée six fois au total : trois exécutions avec les crochets OMC ACTIVÉS et trois exécutions avec les crochets OMC DÉSACTIVÉS. Toutes les exécutions ont utilisé des invites, un déroulement de session et un environnement machine identiques.
La tâche consistait à créer un éditeur Markdown à partir de zéro dans une seule session continue, en implémentant l'application, en écrivant et exécutant des tests, puis en examinant et corrigeant les bogues, les problèmes de sécurité et d'accessibilité avant de relancer les tests. L'objectif n'était pas de produire un code parfait, mais de mesurer si les crochets modifiaient le comportement de Claude de manière significative.
Résultats clés
- Qualité du code : Scores identiques (15,0/20 pour les deux conditions DÉSACTIVÉ et ACTIVÉ)
- Coût total : Littéralement le même (5,56 $ pour les deux conditions)
- Total de jetons : Légèrement inférieur avec les crochets ACTIVÉS (6,48 M contre 6,76 M DÉSACTIVÉ)
- Temps réel : Les crochets ACTIVÉS étaient en moyenne plus rapides (1 673 s contre 2 152 s DÉSACTIVÉ)
- Appels d'outils : Légèrement moins nombreux avec les crochets ACTIVÉS (37,0 contre 40,7 DÉSACTIVÉ)
Observations notables
Le crochet SessionStart a considérablement augmenté les jetons de lecture du cache sur la première invite : 424 K avec les crochets ACTIVÉS contre 195 K avec les crochets DÉSACTIVÉS (une augmentation de 117 %). Cependant, ce contexte supplémentaire ne s'est pas traduit par une meilleure sortie pour cette tâche particulière. Fait intéressant, à l'invite 3, les crochets DÉSACTIVÉS ont en réalité utilisé plus de lectures de cache que les crochets ACTIVÉS.
Le dépôt de l'expérience est disponible à l'adresse https://github.com/ej31/omc-hook-experiment.
Enseignements du développeur
Le développeur a conclu que les crochets dynamiques ne sont pas un "bouton magique pour un meilleur code" pour les tâches de programmation en session unique, car Claude performe déjà bien avec des instructions statiques. Tout gain lié aux crochets semble suffisamment faible pour être noyé dans la variance normale d'exécution en exécution. La surcharge constante plus importante pourrait en réalité provenir de l'empreinte statique d'OMC—les définitions d'outils MCP, les compétences, le catalogue d'agents—plutôt que du simple comportement dynamique des crochets.
Il est important de noter que cette expérience n'a testé que le comportement des crochets, et non si l'écosystème plus large d'OMC est utile dans des flux de travail plus importants et multi-sessions. Le développeur prévoit de tester davantage en supprimant complètement oh-my-claudecode et en faisant créer à Claude un jeu Snake à partir de zéro.
📖 Lire la source complète : r/ClaudeAI
👀 See Also
Compétence OpenClaw pour la transcription de réunions locales avec Whisper
Une nouvelle compétence OpenClaw appelée ghostmeet permet la transcription locale de réunions en utilisant Whisper. Elle capture l'audio des onglets du navigateur via une extension Chrome et peut générer des résumés avec Claude, tout l'audio et la transcription étant traités localement sur votre machine.
Le plugin OpenClaw ajoute une mémoire persistante avec le serveur Engram.
Un développeur a créé un plugin TypeScript qui connecte les agents OpenClaw à Engram, un serveur de mémoire léger basé sur Go qui stocke des observations structurées dans SQLite avec la recherche en texte intégral FTS5. Cela fournit une mémoire à long terme pour les agents qui survit aux redémarrages, aux compactions et aux fins de session.
9 Blocs de Construction pour Exécuter Claude Code comme un OS Persistant à Travers 18 Entreprises
Un développeur exécute 18 instances de Claude Code comme un OS partagé avec synchronisation sélective, état déplacé vers des serveurs MCP, vérification basée sur des reçus, et règles de chargement automatique. Détaille l'architecture.
Ninetails Memory Engine V4.5 : Quantification Int8 + Cache LRU réduit la mémoire MCP locale à 60 Mo
Le moteur de mémoire Ninetails V4.5 utilise la quantification scalaire Int8 et l'éviction de cache LRU pour réduire le stockage vectoriel de 6 Ko à 1,5 Ko par plongement, maintenant l'ensemble du moteur entre 40 et 60 Mo de RAM. Il combine 70 % de similarité vectorielle avec 30 % de recherche BM25 dans une implémentation SQLite entièrement locale.