Open-Source-Local-Hook schaltet Claude-Modelle automatisch um, um KI-Kosten zu senken
Ein Entwickler hat einen lokalen Hook quelloffen gemacht, der automatisch das kosteneffizienteste Claude-KI-Modell basierend auf der Art der Programmieraufgabe auswählt, was KI-Kosten um 50-70% reduzieren kann, ohne Qualitätseinbußen.
So funktioniert es
Das Tool läuft als lokaler Hook in Cursor und Claude Code (beide nutzen dasselbe Hook-System) bevor jeder Prompt gesendet wird. Es sitzt neben Opus/Plan und fungiert als effizienter Frontend-Filter, der offensichtlich schlechte Modellzuordnungen verhindert, bevor sie teure Modelle erreichen.
Wesentliche Funktionen
- Liest den Prompt und die aktuelle Modellauswahl
- Verwendet einfache Schlüsselwortregeln zur Aufgabenklassifizierung (Git-Operationen, Feature-Arbeit, Architektur/tiefgehende Analyse)
- Blockiert bei Überzahlung (z.B. Opus für Git-Commit) und schlägt Haiku oder Sonnet vor
- Blockiert bei Unterdimensionierung (Sonnet/Haiku für Architektur) und schlägt Opus vor
- Lässt alles andere unverändert durch
- !-Präfix umgeht den Filter vollständig bei Unstimmigkeiten mit dessen Vorschlag
Technische Details
- 3 Dateien: Bash + Python3 + JSON
- Kein Proxy, keine API-Aufrufe, keine externen Dienste
- Fail-Open-Design: bei Hängern läuft Claude Code normal weiter
- Quelloffen verfügbar unter: https://github.com/coyvalyss1/model-matchmaker
Leistung und Tests
Der Entwickler analysierte mehrere Wochen eigener Prompts und fand:
- 60-70% waren Standard-Feature-Arbeit, die Sonnet bewältigen konnte
- 5-20% waren Debugging/Fehlerbehebung
- Ein signifikanter Anteil waren reine Git/Umbenennungs/Formatierungsaufgaben, die Haiku identisch bei 90% geringeren Kosten bewältigt
Retrospektive Analysen zeigten, dass das Tool 50-70% der KI-Ausgaben ohne Qualitätsverlust reduziert hätte. Nach Feinabstimmung bewältigte es 12/12 echte Test-Prompts korrekt.
Gelöstes Problem
Das Problem ist nicht Wissen – Entwickler wissen, dass sie Modelle wechseln sollten – sondern Reibung. Im Flow-Zustand möchten Entwickler nicht über Dropdown-Menüs nachdenken. Dieses Tool automatisiert den Entscheidungsprozess.
📖 Read the full source: r/ClaudeAI
👀 Siehe auch
APEX-Testbenchmark-Ergebnisse: Qwen 3.5-Leistung bei echten Programmieraufgaben
APEX-Testing-Benchmark-Ergebnisse zeigen die Leistung der Qwen-3.5-Modelle bei 70 echten GitHub-Coding-Aufgaben, wobei die 397B-Version bei Master-Level-Aufgaben auf 1194 ELO abfällt, während GLM-4.7 quantisiert mit 1572 ELO die lokalen Modelle anführt.
Anwendung der Claude-Code-Architektur auf lokale 9B-Modelle: Wichtige Erkenntnisse und Optimierungen
Ein Entwickler extrahierte Architekturmuster aus dem geleakten Quellcode von Claude Code und wandte 10 Optimierungen auf qwen3.5:9b an, das lokal auf einer RTX 5070 Ti läuft. Die wichtigste Erkenntnis war, dass qwen3.5:9b native strukturierte tool_calls hat, und die größte Einschränkung für 9B-Modelle ist die Selbstdisziplin, zu wissen, wann man mit dem Erkunden aufhören und mit der Ausgabeerzeugung beginnen soll.
Das WCY-Format reduziert den Token-Overhead von LLMs um 50–71 % und fügt strukturelle „Ich weiß nicht“-Marker hinzu.
WCY (Watch-Compute-Yield) ist ein zeilenorientiertes Format, das den JSON-Token-Overhead um 50-71% reduziert und strukturelle '?'-Marker für LLMs einführt, um Unsicherheit während des Denkprozesses anzuzeigen. Das Format erfordert kein Fine-Tuning – nur drei Few-Shot-Beispiele.
obsidian-mcp: Graph-bewusster MCP-Server für Claude mit 25 Werkzeugen für große Tresore
obsidian-mcp ist ein MCP-Server, der 25 Tools bereitstellt (einschließlich get_note, traverse_graph, query_dataview, move_note, create_notes) und Claude einen graphenbewussten Zugriff auf Ihren Obsidian-Vault gibt – und so den Tod des Kontextfensters bei 5.000 Notizen umgeht. MIT-Lizenz, funktioniert mit Claude Desktop, Claude Code, Cursor, Cline, Continue, Zed.