Open-source local hook bascule automatiquement entre les modèles Claude pour réduire les coûts d'IA

Un développeur a open-sourcé un crochet local qui sélectionne automatiquement le modèle d'IA Claude le plus rentable en fonction du type de tâche de codage, réduisant potentiellement les coûts d'IA de 50 à 70 % sans perte de qualité.

Fonctionnement

L'outil s'exécute comme un crochet local dans Cursor et Claude Code (tous deux utilisent le même système de crochet) avant que chaque invite ne soit envoyée. Il se place à côté d'Opus/plan et agit comme un filtre frontal efficace qui empêche les mauvais appariements de modèles évidents avant qu'ils n'atteignent les modèles coûteux.

Fonctionnalités clés

• Lit l'invite et la sélection de modèle actuelle
• Utilise des règles de mots-clés simples pour classer les tâches (opérations git, travail sur les fonctionnalités, architecture/analyse approfondie)
• Bloque si vous surpayez (par exemple, Opus pour un commit git) et suggère Haiku ou Sonnet
• Bloque si vous êtes sous-équipé (Sonnet/Haiku pour l'architecture) et suggère Opus
• Laisse passer tout le reste inchangé
• Le préfixe ! contourne complètement le filtre si vous n'êtes pas d'accord avec sa suggestion

Détails techniques

• 3 fichiers : bash + python3 + JSON
• Pas de proxy, pas d'appels API, pas de services externes
• Conception fail-open : en cas de blocage, Claude Code continue normalement
• Open-sourcé à : https://github.com/coyvalyss1/model-matchmaker

Performance et tests

Le développeur a analysé plusieurs semaines de ses propres invites et a constaté :

• 60-70 % étaient des travaux de fonctionnalités standard que Sonnet pouvait gérer
• 5-20 % étaient du débogage/résolution de problèmes
• Une part importante était des tâches purement git/renommage/mise en forme qu'Haiku gère de manière identique à 90 % de coût en moins

L'analyse rétrospective a montré que l'outil aurait réduit de 50 à 70 % les dépenses en IA sans baisse de qualité. Après ajustement, il a correctement traité 12/12 invites de test réelles.

Problème résolu

Le problème n'est pas la connaissance - les développeurs savent qu'ils doivent changer de modèle - mais la friction. En état de flow, les développeurs ne veulent pas penser aux menus déroulants. Cet outil automatise le processus de prise de décision.