Caliber: generierte Agent-Konfigurationen für Claude Code, Cursor und Codex

Das Problem: veraltete Kontextdateien nach jedem Refactoring

Das README benennt den Ausgangszustand in einem Satz: handgeschriebene CLAUDE.md-Dateien veralten in dem Moment, in dem umgebaut wird. Der Agent arbeitet dann mit Pfaden, die es nicht mehr gibt, übersieht neue Abhängigkeiten und empfiehlt Architekturen von gestern. Das ist kein Modellproblem, sondern ein Pflegeproblem: Die Kontextdatei wird einmal geschrieben und danach nicht mehr angefasst, während sich der Code täglich ändert.

Caliber setzt genau dort an. Es erzeugt die Kontextdateien nicht einmalig, sondern hält sie gegen den Repository-Zustand aktuell. Angesprochen sind Teams, die Agenten einsetzen und mehrere Oberflächen parallel betreiben, also etwa Claude Code für einen Teil der Belegschaft und Cursor für einen anderen. Sobald zwei Personen mit unterschiedlichen Werkzeugen auf dasselbe Repository schauen, entsteht die zweite Baustelle: Die eine Regel steht in CLAUDE.md, die andere in .cursor/rules, und beide driften auseinander. Der Nutzen skaliert also mit der Zahl der Agenten, nicht mit der Projektgröße.

Der Bewertungslauf ist deterministisch, die Generierung nicht

Caliber trennt zwei Vorgänge, die oft in einen Topf geworfen werden. Der erste ist die Bewertung. Laut README arbeitet sie deterministisch, ohne LLM und ohne API-Aufrufe, und gleicht die Konfigurationsdateien gegen das echte Dateisystem ab: Existieren die referenzierten Pfade? Sind Codeblöcke vorhanden? Hat sich seit dem letzten Commit Konfigurationsdrift eingeschlichen? Das Ergebnis wird in sechs Kategorien aufgeschlüsselt (FILES & SETUP, QUALITY, GROUNDING, ACCURACY, FRESHNESS, BONUS) und zu einer Punktzahl zwischen 0 und 100 verrechnet. Das ist der belastbare Teil, weil er reproduzierbar ist.

Der zweite Vorgang ist die Erzeugung, und die läuft über ein Modell. Bootstrap selbst ist laut README zu 100 Prozent lokal, ohne LLM-Aufrufe. Die Generierung nutzt das eigene KI-Abonnement oder den eigenen API-Schlüssel, Caliber sehe den Code nicht. Wer einen eigenen Anthropic-, OpenAI-, MiniMax- oder Vertex-AI-Schlüssel mitbringt, kann den Anbieter wählen. Diese Trennung ist die eigentliche Designentscheidung: Prüfen ist billig und wiederholbar, Schreiben kostet Tokens und ist nicht deterministisch. Wer nur die Punktzahl als Qualitätsmaßstab nimmt, sollte wissen, dass sie nur die Prüfungen abbildet, die Caliber kennt.

Ablauf: Audit, Vorschlag, Freigabe, Backup, Undo

Der Schreibpfad ist als Prüfprozess modelliert, nicht als Überschreibvorgang. Das README beschreibt fünf Schritte: Score als reines Lesen, Propose als Diff, Review mit Annehmen, Verfeinern oder Ablehnen pro Änderung, Backup der Originale nach .caliber/backups/ vor jedem Schreibvorgang, und Undo über caliber undo, das alles auf den vorherigen Stand zurücksetzt.

Zwei Details sind praktisch relevant. Erstens die Schwelle: Liegt die bestehende Konfiguration bei 95 oder höher, überspringt Caliber die vollständige Neugenerierung und bessert nur die konkret fehlschlagenden Prüfungen nach. Das begrenzt den Token-Verbrauch auf Repositories, die schon gepflegt sind. Zweitens der Vergleichsmodus: caliber score --compare main zeigt, wie der eigene Branch die Punktzahl verändert hat. Das ist brauchbar in einer Pipeline, weil es Konfigurationsdrift als Diff sichtbar macht, statt sie erst beim nächsten Agentenlauf auffallen zu lassen.

Installation: zwei Wege, je nach Agent

Voraussetzung ist Node.js in Version 20 oder neuer. Der eine Weg führt über den Agenten: npx @rely-ai/caliber bootstrap ausführen, danach in einem Terminal (nicht im IDE-Chat) eine Claude-Code- oder Cursor-CLI-Sitzung starten und /setup-caliber eingeben. Der Agent erkennt den Stack, erzeugt die Konfigurationen, richtet Pre-Commit-Hooks ein und aktiviert die Synchronisierung.

Der zweite Weg ist caliber init, ein CLI-Assistent für alle, die weder Claude Code noch Cursor verwenden. Danach übernimmt caliber refresh die Aktualisierung, laut README automatisch bei jedem Commit über die Pre-Commit-Hooks. Die Hook-Kette ist der Punkt, an dem die Synchronisierung tatsächlich stattfindet, und gleichzeitig der fragilste Teil unter Windows: Das README weist darauf hin, dass Hooks und Auto-Sync-Skripte Shell-Syntax verwenden, Git Bash empfohlen wird und Hooks unter reinem PowerShell stillschweigend übersprungen werden können. Wer auf Windows arbeitet, sollte nach der Einrichtung einen Commit machen und prüfen, ob der Refresh wirklich lief, statt sich auf die Ausgabe des Assistenten zu verlassen. Ein weiterer Hinweis aus dem README: nicht aus mehreren Terminals gleichzeitig arbeiten, das könne zu widersprüchlichem Zustand und unerwarteter Anbietererkennung führen.

Erzeugte Dateien und Formate im Detail

Für Claude Code entstehen CLAUDE.md mit Projektkontext, Build- und Testbefehlen sowie Konventionen, dazu CALIBER_LEARNINGS.md mit Mustern aus den Sitzungen, .claude/skills/*/SKILL.md im OpenSkills-Format, .mcp.json mit automatisch gefundenen MCP-Servern und .claude/settings.json für Berechtigungen und Hooks. Für Cursor sind es .cursor/rules/*.mdc mit Frontmatter aus description, globs und alwaysApply, dazu .cursor/skills/*/SKILL.md und .cursor/mcp.json. Für Codex entsteht AGENTS.md plus .agents/skills/*/SKILL.md, für OpenCode ebenfalls AGENTS.md plus .opencode/skills/*/SKILL.md. GitHub Copilot bekommt nur .github/copilot-instructions.md.

Die Asymmetrie fällt auf: Copilot erhält weder Skills noch MCP-Konfiguration, weil das Format dort schlicht nichts Vergleichbares vorsieht. Wer Copilot als einzigen Agenten nutzt, bekommt von Caliber also eine einzelne Datei gepflegt. Codex und OpenCode teilen sich AGENTS.md, wenn beide Zielplattformen aktiv sind, was doppelte Pflege vermeidet, aber auch bedeutet, dass eine plattformspezifische Anweisung dort keinen Platz hat. Die Sprach- und Framework-Erkennung deckt laut README unter anderem TypeScript, Python, Go, Rust, Java, Ruby und Terraform ab.

Grenzen: Modellabhängigkeit, Windows-Hooks und das Schreibrisiko

Die erste Einschränkung ist struktureller Natur. Der Prüfteil ist deterministisch, der Generierungsteil hängt am gewählten Modell und am eigenen Schlüssel. Zwei Läufe können unterschiedliche Formulierungen in CLAUDE.md erzeugen. Wer reproduzierbare Konfigurationen braucht, etwa für Audits, muss die generierten Dateien versionieren und den Diff reviewen, nicht nur die Punktzahl. Das README sieht das vor, es ändert aber nichts daran, dass die Qualität des Ergebnisses nicht allein in Calibers Hand liegt.

Die zweite Einschränkung betrifft Windows, wie oben beschrieben: Ohne Git Bash können Hooks stillschweigend ausfallen, und dann findet kein automatischer Refresh statt. Das Werkzeug meldet das nicht zwingend, der Zustand wirkt nur veraltet.

Die dritte ist der Schreibvorgang selbst. Der Agent fasst bestehende Konfigurationsdateien an, gesichert zwar nach .caliber/backups/, aber die Entscheidung, welche Datei überschrieben wird, trifft der Agent auf Basis des Diffs. In Repositories mit sorgfältig formulierten, absichtlich knappen Regeln kann eine Neugenerierung mehr Text und weniger Präzision erzeugen. Wer solche Dateien bewusst pflegt, sollte die Schwellenlogik ab 95 Punkten nutzen oder nur einzelne Prüfungen nachbessern lassen.

Die vierte Grenze ist der Anwendungsfall. Caliber ist das falsche Werkzeug, wenn der Agent nur gelegentlich und lesend auf das Repository zugreift, wenn sich die Verzeichnisstruktur kaum ändert, oder wenn im Team nur ein einziger Agent im Einsatz ist. Dann übersteigt der Aufwand für Einrichtung und Hook-Pflege den Nutzen einer einzelnen Kontextdatei.

Alternative: handgeschriebene Kontextdatei oder ein Regel-Generator

Die naheliegende Alternative ist die handgeschriebene CLAUDE.md, versioniert im Repository und bei Bedarf manuell nachgezogen. Der Unterschied liegt nicht in der Datei, sondern im Prüfmechanismus: Eine handgeschriebene Datei hat keine Instanz, die Referenzen gegen das Dateisystem abgleicht. Verweise auf gelöschte Pfade bleiben stehen, bis jemand sie beim Lesen bemerkt. Caliber macht daraus eine Prüfung mit Punktzahl und einen Diff gegen main. Wer bereit ist, die Datei bei jedem größeren Umbau selbst zu prüfen, braucht den zusätzlichen Lauf nicht.

Eine zweite Alternative sind Werkzeuge, die Regeln aus einer einzigen Quelle in die Formate der einzelnen Agenten übersetzen, also gewissermaßen ein Compiler für Regeldateien. Der Ansatz unterscheidet sich grundlegend: Dort schreibt man die Regeln weiterhin selbst, und das Werkzeug verteilt sie nur. Caliber geht den umgekehrten Weg und leitet die Inhalte aus dem Repository ab. Das verteilte Modell bleibt vollständig deterministisch und kostet keine Tokens, veraltet aber genauso wie eine handgeschriebene Datei, weil es den Code nicht liest. Wer maximale Kontrolle über jede Formulierung braucht, ist mit dem Übersetzeransatz besser bedient; wer die Pflegearbeit loswerden will, mit Caliber. Beides zugleich geht nicht.

Wartung, Versionierung und Lizenz

Die Release-Frequenz ist hoch: Aufeinanderfolgende Versionen wie v1.53.3, v1.53.4 und v1.53.5 liegen laut Repository-Angaben nur Minuten bis Stunden auseinander. Für Nutzer bedeutet das zweierlei. Erstens ist das Projekt aktiv, zweitens sollte man eine feste Version pinnen, statt bei jedem Lauf npx ohne Versionsangabe zu verwenden, weil sonst unbeabsichtigt aktualisiert wird. Der Aufwand für Upgrades liegt damit bei einer Zeile in der eigenen Tooling-Konfiguration, nicht bei einer Migration.

Lizenziert ist das Projekt unter MIT. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange der Lizenztext und der Urheberrechtshinweis beibehalten werden. Wer die generierten Konfigurationsdateien in ein eigenes Produkt einbettet, sollte die MIT-Bedingungen der Vorlage mitführen. Das ist eine allgemeine Einordnung und keine Rechtsberatung.

Ein Kostenfaktor, der leicht übersehen wird: Die Generierung läuft über den eigenen API-Schlüssel oder das eigene Abonnement. Bei häufigen Refreshes in großen Repositories entstehen Token-Kosten, die nicht bei Caliber liegen. Die Bewertung selbst ist laut README kostenlos, weil sie ohne LLM arbeitet. Wer die Kosten begrenzen will, sollte den Refresh an die Pre-Commit-Hooks binden und nicht zusätzlich manuell anstoßen.

Redaktionelles Fazit

Sinnvoll ist Caliber für Teams, die mindestens zwei Agenten parallel betreiben und deren Verzeichnisstruktur sich häufig ändert, weil dort der manuelle Pflegeaufwand für CLAUDE.md, AGENTS.md und .cursor/rules am größten ist. Wer ausschließlich Claude Code nutzt und pro Quartal einen Pfad umbenennt, fährt mit einer handgeschriebenen Datei billiger. Wer nur Copilot nutzt, kann auf Caliber verzichten, weil copilot-instructions.md keine Skills und keine MCP-Konfiguration kennt. Vor der Einführung sollte man prüfen, ob caliber score auf dem eigenen Repository überhaupt Referenzfehler meldet; liegt der Wert bereits über 95, greift laut README nur noch die gezielte Nachbesserung einzelner Prüfungen, und der Nutzen schrumpft auf die Hook-Automatik. Ebenfalls vorab zu klären ist, welche Dateien der Agent beim Refresh anfassen darf, denn der Schreibvorgang läuft über das Agent-Werkzeug und nicht über das CLI.

Offizielle Quellen

1. caliber-ai-org/ai-setup on GitHub
2. License: MIT
3. Project website
4. README
5. Releases