tokensave

Semantische Code-Intelligenz für KI-Codierungsagenten

Weniger Tokens • Weniger Tool-Aufrufe • 100% lokal

Warum tokensave?

KI-Codierungsagenten verschwenden Tokens beim Erkunden von Codebasen. Jedes grep, glob und Dateilesen kostet Geld. Bei komplexen Aufgaben starten Agenten mehrere Explore-Unteragenten, die Hunderte von Dateien scannen, nur um Kontext aufzubauen.

tokensave gibt Agenten einen vorindizierten semantischen Wissensgraphen. Statt Dateien zu scannen, fragt der Agent den Graphen ab und erhält sofortige, strukturierte Antworten – die richtigen Symbole, ihre Beziehungen und den Quellcode in einem einzigen Aufruf.

So funktioniert es

┌──────────────────────────────────────────────────────────────┐
│  AI Coding Agent (Claude Code, Codex, Gemini, Cursor, ...)   │
│                                                              │
│  "Implement user authentication"                             │
│        │                                                     │
│        ▼                                                     │
│  ┌─────────────────┐       ┌─────────────────┐               │
│  │  Sub-agent      │ ───── │  Sub-agent      │               │
│  └────────┬────────┘       └─────────┬───────┘               │
└───────────┼──────────────────────────┼───────────────────────┘
            │                          │
            ▼                          ▼
┌──────────────────────────────────────────────────────────────┐
│  tokensave MCP Server                                        │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐           │
│  │   Search    │  │   Callers   │  │   Context   │           │
│  │   "auth"    │  │  "login()"  │  │   for task  │           │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘           │
│         └────────────────┼────────────────┘                  │
│                          ▼                                   │
│              ┌───────────────────────┐                       │
│              │   libSQL Graph DB     │                       │
│              │   • Instant lookups   │                       │
│              │   • FTS5 search       │                       │
│              └───────────────────────┘                       │
└──────────────────────────────────────────────────────────────┘

Ohne tokensave: Agenten verwenden grep, glob und Read, um Dateien zu scannen – viele API-Aufrufe, hoher Token-Verbrauch.

Mit tokensave: Agenten fragen den Graphen über MCP-Tools ab – sofortige Ergebnisse, lokale Verarbeitung, weniger Tokens.

Hauptfunktionen

Schnellstart

1. Installation

Homebrew (macOS):

brew install aovestdipaperino/tap/tokensave

Scoop (Windows):

scoop bucket add tokensave https://github.com/aovestdipaperino/scoop-bucket
scoop install tokensave

Cargo / cargo-binstall (beliebige Plattform):

# Fast install prebuilt binary without compiling:
cargo binstall tokensave

# Or compile from source:
cargo install tokensave                          # full (50+ languages, default)
cargo install tokensave --features medium        # medium tier
cargo install tokensave --no-default-features    # lite (smallest binary)

Vorkompilierte Binärdateien (Linux, Windows, macOS):

Lade von der neuesten Version herunter und platziere die Binärdatei in deinem PATH.

2. Agent konfigurieren

tokensave install                         # auto-detects installed agents
tokensave install --agent antigravity     # Google Antigravity (formerly Windsurf)
tokensave install --agent auggie          # AugmentCode
tokensave install --agent claude          # Claude Code
tokensave install --agent cline           # Cline
tokensave install --agent codex           # OpenAI Codex CLI
tokensave install --agent copilot         # GitHub Copilot
tokensave install --agent cursor          # Cursor
tokensave install --agent droid           # Factory Droid
tokensave install --agent gemini          # Gemini CLI
tokensave install --agent kilo            # Kilo CLI
tokensave install --agent kiro            # AWS Kiro
tokensave install --agent kimi            # Moonshot Kimi CLI
tokensave install --agent omp             # Oh My Pi (OMP)
tokensave install --agent opencode        # OpenCode
tokensave install --agent pi              # Pi (pi.dev)
tokensave install --agent plank           # Plank (macOS only)
tokensave install --agent qwen            # Qwen Code
tokensave install --agent roo-code        # Roo Code
tokensave install --agent vibe            # Mistral Vibe
tokensave install --agent zed             # Zed
tokensave install --agent grok            # Grok Build (xAI)
tokensave install --git-hook yes           # auto-install the global post-commit and post-checkout hooks (no prompt)
tokensave install --git-hook no            # skip the post-commit and post-checkout hooks (no prompt)
tokensave githooks                         # show which global git hooks tokensave owns
tokensave githooks off                     # remove them, leaving any hook content you wrote

Jeder Agent erhält seinen MCP-Server im nativen Konfigurationsformat registriert. Claude Code erhält zusätzlich einen PreToolUse-Hook (blockiert verschwenderische Explore-Agenten), einen UserPromptSubmit-Hook, einen Stop-Hook, Prompt-Regeln in CLAUDE.md und automatisch erlaubte Tool-Berechtigungen. Kiro erhält globale MCP-Konfiguration, tokensave.md-Steuerung als Ressource geladen und einen von tokensave verwalteten Standard-Agenten mit großzügiger integrierter/tokensave-Tool-Genehmigung, Delegations-Guardrail-Hooks und Post-Write-Synchronisierung; benutzerverwaltete Kiro-Agenten bleiben erhalten.

Globale OMP-Installationen zielen auf das Profil, das von nacktem omp config path gemeldet wird, und schreiben <resolved-agent-dir>/mcp.json und <resolved-agent-dir>/rules/tokensave.md. Exportiere OMP_PROFILE oder OMPs kompatibles PI_PROFILE, wenn du in ein benanntes Profil installierst; OMPs Resolver berücksichtigt auch PI_CONFIG_DIR und PI_CODING_AGENT_DIR. Tokensave vertraut diesem nativen Resolver, anstatt OMPs Profillogik zu duplizieren. Tokensave installiert MCP- und Beratungsregeln für OMP; es installiert keine OMP-Hook-Durchsetzung.

Alle Änderungen sind idempotent – sicher, nach einem Upgrade erneut auszuführen. Nach der Agenteneinrichtung werden dir globale git post-commit- und post-checkout-Hooks angeboten. tokensave uninstall entfernt diese Hooks zusammen mit den Agenten-Integrationen; übergib --keep-git-hooks, um sie zu belassen, oder verwalte sie separat mit tokensave githooks.

Projektlokale Installation

Standardmäßig registriert tokensave install den MCP-Server in deiner globalen Agentenkonfiguration (z. B. ~/.claude.json). Um tokensave stattdessen nur für das aktuelle Projekt zu registrieren, füge --local hinzu:

tokensave install --local --agent claude
tokensave install --local --agent omp

Dies schreibt projektspezifische Konfiguration, die du committen und mit deinem Team teilen kannst. Für Claude sind das ./.mcp.json, ./.claude/settings.json und ./CLAUDE.md; OMP verwendet ./.omp/mcp.json und ./.omp/rules/tokensave.md ohne Aufruf der OMP-CLI. Unterstützte Agenten: claude, cursor, droid, gemini, zed, opencode, roo-code, kiro, auggie, omp, plank (jeder schreibt seine eigene Projektdatei, z. B. .cursor/mcp.json, .factory/mcp.json, .gemini/settings.json, .zed/settings.json, opencode.json, .roo/mcp.json, .kiro/settings/mcp.json, .augment/settings.json, .omp/mcp.json, .mcp.json für plank). Andere Agenten haben keine projektspezifische Konfiguration und melden einen Fehler mit --local.

Entferne eine projektlokale Installation mit tokensave uninstall --local.

3. Projekt indizieren

cd /path/to/your/project
tokensave init

Dies erstellt ein .tokensave/-Verzeichnis mit der Wissensgraphen-Datenbank. Initialisierung und Synchronisierung sind separate Befehle: init ist ein einmaliges Opt-in pro Projekt, während sync nur Projekte aktualisiert, die bereits initialisiert wurden. Dies verhindert, dass die globalen git-Hooks stillschweigend Datenbanken in Repos erstellen, die du nie indizieren wolltest. Nach init verwende tokensave sync für inkrementelle Updates – nur geänderte Dateien werden neu indiziert.

{
  "mcpServers": {
    "tokensave": {
      "command": "/path/to/tokensave",
      "args": ["serve"]
    }
  }
}

Absturzsichere Synchronisierung

Tree-Sitter-Grammatiken sind kompilierter C/C++-Code. Sie stoßen gelegentlich auf eine interne Assertion oder beenden den Prozess anderweitig über Pfade, die die Rust-Panic-Behandlung nicht abfangen kann. Ab v4.3.0 wird jede Datei in einem kurzlebigen Worker-Subprozess geparst: Wenn eine Grammatik einen Segfault verursacht, abort() aufruft oder einen Stack-Overflow trifft, stirbt nur der Worker. Der Pool startet ihn neu, die problematische Datei wird protokolliert und übersprungen, und sync läuft weiter.

Der Worker ist ein versteckter extract-worker-Unterbefehl, der gegen den Elternprozess über ein 256-Bit-Token pro Spawn authentifiziert wird, das sowohl als TOKENSAVE_WORKER_TOKEN-Umgebungsvariable als auch als die ersten 32 Bytes auf stdin erforderlich ist. Direkte Aufrufe durch Benutzer schlagen fehl. Standardmäßig available_parallelism() Worker; ablehnen mit TOKENSAVE_DISABLE_SUBPROCESS=1.

Editier-Primitive (tokensave_str_replace, tokensave_insert_at usw.) laufen weiterhin im Prozess: Sie zielen auf eine Datei nach der anderen, wo Subprozess-Overhead dominieren würde, und ein Extraktor-Absturz dort ist sofort für den Agenten sichtbar.

Multi-Branch-Indizierung (Optional)

tokensave kann optional einen separaten Code-Graphen pro git-Branch pflegen. Wenn aktiviert, liefert der Branch-Wechsel nie veraltete Ergebnisse und indiziert nie Dateien neu, die du bereits in einem anderen Branch geparst hast. Multi-Branch-Verfolgung ist Opt-in – ohne sie verwendet tokensave eine einzige Datenbank für alle Branches.

So funktioniert es

Wenn du einen Branch verfolgst, kopiert tokensave die nächstgelegene Vorgänger-Datenbank und synchronisiert nur die Dateien, die sich unterscheiden. Das bedeutet, dass das Verfolgen eines Feature-Branch von main nahezu sofort ist – es parst nur die Dateien, die du geändert hast.

CLI-Befehle

tokensave branch add              # track the current branch
tokensave branch list             # see tracked branches and DB sizes
tokensave branch remove <name>    # stop tracking a branch
tokensave branch removeall        # remove all tracked branches except default
tokensave branch gc               # clean up branches deleted from git

Branch-übergreifende MCP-Tools

Drei MCP-Tools ermöglichen Branch-übergreifende Abfragen ohne Wechsel deines Checkouts:

• tokensave_branch_search – Symbole im Graphen eines anderen Branch suchen
• tokensave_branch_diff – Code-Graphen zwischen zwei Branches vergleichen: hinzugefügte, entfernte und geänderte Symbole (Signatur unterscheidet sich). Unterstützt Datei- und Art-Filter.
• tokensave_branch_list – verfolgte Branches mit Datenbankgrößen, Eltern-Branch und Synchronisierungszeiten auflisten

Branch-Fallback

Wenn der MCP-Server keine Datenbank für den aktuellen Branch findet, bedient er aus der Datenbank des nächstgelegenen Vorgänger-Branch und fügt eine Warnung in jede Tool-Antwort ein, die vorschlägt, tokensave branch add auszuführen.

Automatische Branch-Verfolgung (v7.3.0)

Sobald der Multi-Branch-Modus initialisiert ist (ein erstes manuelles tokensave branch add hat die Branch-Metadaten erstellt), können neue Branches automatisch verfolgt werden, anstatt auf die Vorgänger-Datenbank zurückzufallen. Zwei unabhängige Mechanismen decken dies ab; Projekte im Einzel-Datenbank-Modus sind nie betroffen, und keiner der Mechanismen berührt jemals die Datenbank des Standard-Branch. Git-Hook (bei Branch-Checkout). Der post-checkout-Hook, den tokensave install einrichtet, erkennt einen Branch-Checkout (im Gegensatz zu einem Datei-Checkout) und führt tokensave branch add im Hintergrund aus. Dieser Befehl ist ein No-op, wenn der Branch bereits getrackt wird oder der Standard-Branch ist, sodass das normale Wechseln zwischen bekannten Branches nichts kostet. Der anfängliche Checkout eines frischen git clone und eines neuen git worktree add ist ebenfalls ein Branch-Checkout und kann auf einem Branch landen, der nicht der Standard-Branch ist (git clone -b feature, git worktree add -b feature); dort führt der Hook zuerst tokensave init und danach tokensave branch add aus, in dieser Reihenfolge. Ein Hook, der von einer früheren Version geschrieben wurde, behält den Rumpf, mit dem er installiert wurde – der Installer überschreibt niemals einen vorhandenen –, sodass bei diesen Installationen ein frisches Worktree weiterhin auto_track unten oder ein manuelles tokensave branch add benötigt.

Auto-Tracking beim Öffnen (opt-in). Wenn TokenSave::open ausgeführt wird – CLI-Befehl oder MCP-Serverstart – und der aktive Branch ungetrackt ist, kann tokensave ihn sofort tracken, indem es die DB des nächsten getrackten Vorfahren kopiert und sie in den Branch-Metadaten aufzeichnet. Dies wird durch das auto_track-Konfigurationsfeld (Standard false) oder die TOKENSAVE_AUTO_TRACK-Umgebungsvariable gesteuert, die die Konfiguration pro Lauf überschreibt (jeder Wert aktiviert es außer 0, false, no, off oder leer). Die Kopie ist dieselbe nahezu sofortige Vorfahren-DB-Kopie, die ein manuelles branch add durchführt; in diesem Moment läuft keine Synchronisierung – der post-commit-Hook hält die neue Branch-DB beim Committen frisch, oder führen Sie tokensave sync aus, um sofort zu aktualisieren. Auto-Tracking ist strikt Best-Effort: Jeder Fehler wird als Warnung gemeldet und open() fährt mit dem üblichen Vorfahren-Fallback fort, sodass es niemals einen Tool-Aufruf unterbrechen kann.

Kurz gesagt: Mit installiertem Hook erhält das Auschecken eines neuen Feature-Branches – einschließlich des Branches, auf dem ein frischer Klon oder ein Worktree startet – transparent seinen eigenen Pro-Branch-Graphen; mit aktiviertem auto_track wird sogar ein Branch, der außerhalb eines Checkouts erstellt wurde, beim ersten Öffnen des Projekts durch tokensave auf diesem Branch erfasst.

Siehe docs/BRANCHING-USER-GUIDE.md für die vollständige Anleitung.

Sitzungsübergreifender Speicher

Drei MCP-Tools persistieren Entscheidungen und Codebereichskontext über Sitzungen hinweg, gespeichert im projektspezifischen .tokensave/tokensave.db.

Verwenden Sie diese, damit der Agent Architekturwahl nicht von Sitzung zu Sitzung neu erklären muss.

Spar-Ledger

Jeder MCP-Aufruf schreibt eine append-only Zeile in ~/.tokensave/global.db (savings_ledger-Tabelle). Untersuchen Sie mit tokensave gain:

tokensave gain                    # current project, last 30 days
tokensave gain --all              # all projects
tokensave gain --history --range 7d
tokensave gain --json

Dollar-Schätzungen verwenden das vorhandene Preismodul (Sonnet-Eingabepreise, täglich über LiteLLM aktualisiert).

Reproduzierbarer Benchmark

tokensave bench führt einen festen Abfragesatz durch tokensave_context aus und meldet Einsparungen beim Abruf gegenüber einer Volldatei-Baseline (spiegelt die CCE-Methodik wider):

tokensave bench                                    # ships with 10 default queries
tokensave bench --queries my-queries.toml --json
tokensave bench --max-nodes 5

Gemessen gegen dieses Repo (tokensave selbst) mit dem mitgelieferten generischen Abfragesatz:

Aggregat: 88 % mittlere Abrufeinsparung (142,8k → 5,5k Token über 10 Abfragen).

Der Standard-Abfragesatz zielt auf Muster ab, die in den meisten Anwendungscodebasen vorhanden sind (CLIs, Daemons, Dienste). Führen Sie ihn mit tokensave bench auf Ihrem eigenen Projekt aus, um Ihre Zahlen zu sehen, oder schreiben Sie eine maßgeschneiderte Abfragedatei (--queries my.toml) für eine engere Trefferquote.

Criterion-Benchmark gegen große reale Repos

benches/large_repos.rs ist ein criterion-Mikro-Benchmark, der die MCP-Tools Ende-zu-Ende gegen vier große Open-Source-Codebasen ausführt, die auf konstanten Refs fixiert sind. Jedes Tool wird mit mindestens 5 Abfragen mit Argumenten (Knoten-IDs, qualifizierten Namen, Dateiglobs, …) gesteuert, die einmal pro Repo aus dem indizierten Graphen abgetastet werden, sodass die Zeitmessungen über Läufe hinweg reproduzierbar sind.

Repos und fixierte Refs (definiert in benches/repos.rs):

Jedes Repo wird bei der ersten Verwendung flach geklont (git init + git fetch --progress --depth 1 origin <ref> + checkout FETCH_HEAD) und lokal zwischengespeichert; nachfolgende Läufe verwenden den Checkout erneut. Die Git-Ausgabe wird auf das Terminal gestreamt, sodass der Multi-GB-Abruf Fortschritt in Echtzeit zeigt.

Abgedeckte Tools (5 Abfragen jeweils). Lese-Tools – search, context, callers, callees, node, by_qualified_name, signature, impact, body, files, complexity, doc_coverage, largest, hotspots, god_class, module_api, derives, dead_code, rank, coupling, circular. Schreib-Tools – str_replace, multi_str_replace, insert_at und (wenn ast-grep auf PATH ist) ast_grep_rewrite.

Force-Sync bei jedem Lauf. Bevor ein Benchmark ausgelöst wird, führt das Framework das Äquivalent von tokensave sync --force auf jedem Repo aus (index_all() unabhängig von der .tokensave/-Frische), sodass die Zeitmessungen immer die fixierte Quelle widerspiegeln.

Schreib-Benchmarks und Bereinigung. Schreib-Tools mutieren Dateien. Um die Vorbedingung „Übereinstimmung muss eindeutig sein“ aufrechtzuerhalten, verwendet das Framework criterions iter_batched – eine kleine Scratch-Datei unter <repo>/.tokensave-bench-scratch/ wird vor jeder zeitgesteuerten Iteration mit bekanntem Inhalt neu geschrieben, dann läuft das Bearbeitungstool dagegen. Nachdem alle Benchmarks abgeschlossen sind, führt das Framework git stash --include-untracked && git stash drop in jedem vorbereiteten Repo aus, sodass der Arbeitsbaum zur fixierten Ref zurückkehrt.

Criterion-Konfiguration. Der Benchmark überschreibt criterions Standardwerte auf sample_size = 10 und measurement_time = 30s (gegenüber den Standardwerten 100 / 5s), was jeder Pro-Abfrage-Zeitmessung ~30 Sekunden Messung gibt – genug, damit langsame Tools wie tokensave_context auf polkadot-sdk stabile Zahlen erzeugen.

Ausführen:

# Required: a writable cache directory for the cloned repos + their indexes.

<p align="center">
  <a href="https://ai.enzolombardi.net/"><img src="https://img.shields.io/badge/built%20with-AI-D97757?style=flat-square&labelColor=101010&logo=anthropic&logoColor=white" alt="Built with AI — part of Enzo Lombardi's AI portfolio"></a>
</p>

# Expect several GB of disk and a long first run (shallow clone + full index of each repo).
export TOKENSAVE_BENCH_REPOS_DIR=~/tokensave-bench-cache

cargo bench --bench large_repos

Wenn TOKENSAVE_BENCH_REPOS_DIR nicht gesetzt ist, druckt der Benchmark einen Hinweis und registriert null Benchmarks (sodass cargo bench --all auf den Maschinen der Mitwirkenden günstig bleibt).

Konfiguration (alle optional, über Umgebung):

Filtern von Benchmarks verwendet die Standard-Criterion-CLI – zum Beispiel nur das search-Tool auf scipy:

cargo bench --bench large_repos -- 'scipy/tokensave_search'

Berichte (HTML + Rohproben) landen unter target/criterion/.

Um die fixierten Refs zu ändern (z. B. auf eine neuere Version oder eine bestimmte SHA), bearbeiten Sie REPOS in benches/repos.rs und löschen Sie den entsprechenden $TOKENSAVE_BENCH_REPOS_DIR/<repo>/.bench-ref-Marker, damit der nächste Lauf erneut holt. Wenn Sie die Bereinigung nach dem Lauf überspringen (z. B. Sie Ctrl-C mitten im Benchmark), stellen Sie es manuell wieder her, indem Sie git stash --include-untracked && git stash drop in jedem Repo-Verzeichnis ausführen.

MCP-Testmatrix-Sonde (scripts/mcp_probe)

scripts/mcp_probe/ ist ein Python-Framework, das tokensave serve über stdio gegen einen konfigurierbaren Satz realer Repos treibt und jedes schreibgeschützte MCP-Tool mit 5 Abfragevarianten pro Sprache ausübt, wodurch eine Pro-Tool-/Pro-Repo-Statustabelle erzeugt wird. Dasselbe Framework dient zwei Zwecken:

• Regressions-Sweep. Neue Sprachunterstützung, neues Tool oder Refactoring – führen Sie die Matrix erneut aus, und jede Zelle, die neu Fehler, Zeitüberschreitungen oder leere Ergebnisse erzeugt, sticht als 🚩 hervor.
• Leistungssonde. Zeitmessungen pro Aufruf werden in TSV protokolliert; derselbe feste Korpus von Repos dient als grober Versionsvergleich. Der aktuelle tokensave_inheritance_depth-Zyklusfehler wurde von diesem Framework gefunden, als ein einzelnes Tool auf polkadot-sdk bei >60 s eine Zeitüberschreitung hatte.

Layout – probe.py ist der Treiber (id-abgeglichenes JSON-RPC, sodass ein langsames Tool nachfolgende Aufrufe nicht vergiften kann), isolated.py führt ein einzelnes Tool mit einem frischen Server pro Aufruf erneut aus (entkommt der Server-Warteschlange), build_matrix.py liest das TSV und erzeugt Markdown, tools/<lang>.py-Module tragen pro Sprache Abfragesätze bei (Rust mitgeliefert; fügen Sie Python/Go/… hinzu, indem Sie ein neues Modul ablegen), repos.toml listet Ziel-Repos auf (überschreiben über $TOKENSAVE_PROBE_REPOS).

Schneller Lauf:

cargo build --release --bin tokensave
python3 scripts/mcp_probe/probe.py
python3 scripts/mcp_probe/build_matrix.py > matrix.md

Ausgabezellen sind ✓ 5/5 (sauber), 🐛 e/N (Fehler), ⏱ N/N (Zeitüberschreitungen), ∅ E/N (leer), 🐢 ok/slow (>10 s Aufrufe). Jede Zelle mit einem Fehler oder einer Zeitüberschreitung erhält ein 🚩 in der äußersten rechten Spalte. Detail pro Aufruf mit den ersten 100 Zeichen jedes Fehlers landet im TSV-Protokoll zur Nachverfolgung.

Anders als der Criterion-Benchmark oben: Criterion misst die Latenz pro Iteration für einen fokussierten Tool-Satz auf fixierten Refs und erzeugt statistische Berichte unter target/criterion/; mcp_probe übt jedes Tool mit einem breiteren Abfragesatz auf beliebigen Repos aus, auf die Sie es richten, und optimiert auf Breite der Abdeckung statt Messpräzision.

80+ MCP-Tools

Der Server stellt mehr als 80 Tools bereit (eines weniger, wenn die optionale ast-grep-Binärdatei nicht auf PATH ist); die Tabellen unten gruppieren die am häufigsten verwendeten nach Kategorie. Die meisten sind schreibgeschützt, sicher parallel aufrufbar und mit readOnlyHint annotiert. Die Bearbeitungsprimitive sind auf einzelne Dateien beschränkt und indizieren an Ort und Stelle neu; Sitzungs-Baseline- und Speicheraufzeichnungstools mutieren ebenfalls lokalen .tokensave-Zustand und sind als nicht schreibgeschützt annotiert. Die drei Kern-Tools (tokensave_context, tokensave_search, tokensave_status) sind als anthropic/alwaysLoad markiert, sodass sie die Tool-Such-Round-Trip des Clients umgehen.

Ein anderes initialisiertes Projekt abfragen

Semantische Lese-Tools können einen explizit ausgewählten lokalen Graphen abfragen, ohne den MCP-Server neu zu starten:

{
  "query": "screenGate",
  "graph_root": "/absolute/path/to/typewhisper"
}

Ausgewählte Ergebnisse enthalten kanonische Root-/Branch-Herkunft. Knoten-IDs sind auf diesen Graphen namensraumgebunden, und die übereinstimmenden Selektoren müssen bei Folgeaufrufen wiederholt werden. Zum Beispiel enthält eine Folge auf eine Branch-ausgewählte Abfrage beide Werte:

{
  "node_id": "graph:<fingerprint>:function:<raw-id>",
  "graph_root": "/absolute/path/to/typewhisper",
  "graph_branch": "feature/auth"
}

graph_root muss die exakte absolute Wurzel eines bereits initialisierten Projekts sein. graph_branch ist optional und muss, wenn angegeben, einen getrackten Branch benennen. Ausgewählte Öffnungen sind schreibgeschützt: Sie initialisieren, synchronisieren, migrieren, auto-tracking oder schreiben niemals Graph-/Quelldaten. Sie tragen auch nicht zur Spar-Buchhaltung bei. Aufrufe ohne Selektoren verhalten sich genau wie zuvor. graph_root ist nur nützlich, wenn man weiß, dass das andere Projekt existiert. Deshalb teilt der Server dir mit: initialisierte Projekte, die direkt neben dem bedienten Root liegen, werden im MCP instructions, in tokensave_status und in leeren tokensave_search / tokensave_context-Ergebnissen benannt – an dem Punkt, an dem eine Sitzung sonst schlussfolgern würde, dass ein Symbol nicht existiert, anstatt nebenan zu schauen (#375). Nur direkte Geschwister werden angeboten, höchstens fünf, und nichts wird in ihrem Namen geöffnet oder indiziert; eine Abfrage erfordert weiterhin einen expliziten graph_root.

Selektoren sind absichtlich bei Werkzeugen nicht verfügbar, die schreiben, Shell-Befehle ausführen oder vom aktuellen Checkout abhängen: die Bearbeitungs-Primitive, VCS- und Branch-Werkzeuge, Diagnose- und Testausführung, Abhängigkeits- und Laufzeit-Introspection, Workflow- und Sitzungsspeicher-Werkzeuge, das persistente Cache-Werkzeug (tokensave_redundancy) und die Serververwaltung. Diese Werkzeuge lehnen einen Selektor ab, anstatt ihn stillschweigend zu ignorieren.

Entdeckung

Nicht-Code-Artefakte

tokensave_files deckt mehr als nur Quellcode ab. Dateien, deren Erweiterung in artifact_extensions aufgeführt ist (.feature, .json, .yaml, .yml, .sql, .toml, .proto, .graphql, .md standardmäßig), werden nach Pfad verfolgt, sodass Fragen wie „Wo sind die .feature-Dateien für den Login-Ablauf?" eine grafische Antwort haben, anstatt eine blockierte find (#323). Sie werden nie geparst und tragen keine Symbole bei; kind: "artifact" und kind: "code" filtern zwischen den beiden, und Analysen, die „Code" bedeuten, schließen sie aus. Eine Erweiterung, die bereits von einem Sprach-Extraktor verarbeitet wird, wird in dieser Liste ignoriert, sodass sie nicht verwendet werden kann, um das Parsen einer Sprache zu stoppen.

Die Liste entscheidet auch, in was die wörtliche Suche hineinschauen kann (#442). Eine wörtliche (literal: true) Suche über tokensave_search liest Bytes statt Symbole, benötigt also keinen Parser – aber sie durchläuft die indizierten Dateien, sodass sie nur eine Datei erreichen kann, für die der Index eine Zeile hat. Eine verfolgte .html-Vorlage oder ein .css-Stylesheet hat weder einen Extraktor noch einen Standard-Artefakt-Eintrag, daher fehlen ihre Übereinstimmungen; füge die Erweiterung hier hinzu und führe tokensave sync -f aus, und ihre Zeilen werden wie jede andere durchsucht, gemeldet mit enclosing: null, da es keinen Symbolkontext gibt. Eine wörtliche Antwort, die nicht jede verfolgte Datei erreichen konnte, sagt dies in einem unscanned-Block mit der Anzahl und den Erweiterungen, sodass eine teilweise Antwort nie als vollständige präsentiert wird.

Aufrufgraph & Auswirkung

Code-Qualität

Code-Gesundheitsanalysen

Fünf Werkzeuge zeigen strukturelle Qualitätssignale aus dem vorhandenen Graphen. Der zusammengesetzte Score verwendet ein geometrisches Mittel über unabhängige Dimensionen, sodass keine einzelne manipuliert werden kann.

Sitzungen

Erfasse Gesundheitsmetriken zu Beginn einer KI-Codierungssitzung und vergleiche sie am Ende, um zu sehen, was sich verbessert oder verschlechtert hat.

Bearbeitungs-Primitive

Vier Schreibwerkzeuge, die Agenten ermöglichen, Dateien ohne Regex- oder Shell-Quoting-Gefahren zu ändern. Jedes ist einzeilig, verankert und löst nach dem Schreiben eine In-Place-Neuindizierung aus, sodass der Graph nie veraltet.

Git & Workflow

Typsystem

Portierung

Multi-Branch

MCP-Ressourcen

Vier Ressourcen werden über resources/list und resources/read bereitgestellt:

• tokensave://status – Graphstatistiken als JSON
• tokensave://files – Indizierter Dateibaum, gruppiert nach Verzeichnis
• tokensave://overview – Projektübersicht mit Sprachverteilung und Symbolarten
• tokensave://branches – Verfolgte Branches mit DB-Größen und Elterninformationen

Token-Verfolgung

tokensave misst die Tokens, die es bei jedem MCP-Werkzeugaufruf spart. Jede Werkzeugantwort enthält eine tokensave_metrics: before=N after=M-Zeile, die zeigt, wie viele Rohdatei-Tokens durch diesen spezifischen Aufruf vermieden wurden.

Berichterstattung deaktivieren. Die Metrikzeile bittet zusammen mit einem Satz im MCP instructions den Agenten, Einsparungen an dich zu melden – was bedeutet, dass das Modell Ausgabe-Tokens ausgibt, um eine Einsparung zu erzählen, die tokensave bei Eingabe-Tokens erzielt hat. Ausgabetokens sind die teurere Art. Wenn dein Agent also bei fast jeder Runde tokensave erwähnt, kann diese Erzählung den Gewinn aufwiegen (#356). Setze report_savings auf false in .tokensave/config.json oder die TOKENSAVE_REPORT_SAVINGS-Umgebungsvariable, um es pro Lauf zu überschreiben (jeder Wert aktiviert es außer 0, false, no, off oder leer). Sowohl die Metrikzeile als auch die Anweisung verschwinden; tokensave install schreibt die Berichtsregel ebenfalls nicht mehr in Agent-Prompt-Dateien. Die Messung bleibt in beiden Fällen unberührt – jeder Aufruf landet weiterhin im Einsparungs-Ledger, sodass tokensave gain, tokensave list, status und monitor genau wie zuvor berichten. Der Standard bleibt true.

Kostenbeobachtbarkeit

tokensave cost                     # 7-day cost summary (default)
tokensave cost today               # today only
tokensave cost --by-model          # breakdown by Claude model
tokensave cost --by-task           # breakdown by task category (coding, debugging, exploration, ...)
tokensave cost --export json       # JSON export to stdout
tokensave cost --export csv        # CSV export to stdout

Parst Claude-Code-Sitzungstranskripte (~/.claude/projects/**/*.jsonl), klassifiziert jede API-Runde in eine von 13 Aufgabenkategorien, berechnet Dollarkosten mithilfe der Modellpreise und speichert Ergebnisse in ~/.tokensave/global.db für schnelle Aggregatabfragen. Preise werden alle 24 Stunden von LiteLLM aktualisiert und fallen auf eine eingebettete Tabelle zurück, wenn offline.

Der tokensave status-Header enthält eine Kostenzeile, die die heutigen Ausgaben, den 7-Tage-Gesamtwert und das Effizienzverhältnis (gespeicherte Tokens / Gesamttokens) zeigt. Die tokensave monitor-TUI zeigt ein Live-Kostenpanel neben dem Einsparungs-Feed. Am Ende jeder Claude-Code-Sitzung druckt der hook_stop-Handler eine einzeilige Quittung auf das Terminal.

Aufgabenklassifizierungskategorien: Codierung, Debugging, Feature-Entwicklung, Refactoring, Testen, Erkundung, Planung, Delegation, Git-Operationen, Build/Deploy, Brainstorming, Konversation, Allgemein. Die Klassifizierung ist deterministisch (Musterabgleich auf Werkzeugnamen und Bash-Befehlen), erfordert keine LLM-Aufrufe und ist von AgentSeal/codeburn angepasst.

Live-Monitor

tokensave monitor

Eine globale TUI, die MCP-Werkzeugaufrufe aller Projekte in Echtzeit über einen gemeinsamen speicherzugeordneten Ringpuffer bei ~/.tokensave/monitor.mmap zeigt. Jeder Eintrag zeigt den Projektnamen, den Werkzeugnamen und das Token-Delta. Ein Kostenpanel oben zeigt die heutigen Ausgaben, Einsparungen, Effizienz und das Top-Modell (alle 30 Sekunden aktualisiert).

Speicherdiagnose

tokensave memory [--clean]

Ein maschinenweiter Speicherbericht für jeden tokensave-Prozess (MCP-Server, Syncs, Index-Läufe) über eine gemeinsame, speicherzugeordnete Tabelle bei ~/.tokensave/memory.mmap. Jede Instanz erfasst ihren RSS-Wert nach bestem Bemühen beim Start, bei jedem MCP-Tool-Aufruf und rund um die Sync-/Auflösungsphasen, sodass der Bericht den aktuellen und den Spitzen-RSS mit der Phase, die den Spitzenwert erzeugt hat, zeigt – die Daten, die benötigt werden, um hohe Speichernutzung zuzuordnen (siehe #253). Zeilen werden als alive, dead (ein OOM-getöteter Prozess hinterlässt seinen Spitzenwert/Phase als forensischen Datensatz) oder orphan (läuft noch, wurde aber an init umgehängt) markiert. --clean räumt tote Slots auf.

PEAK PHASE benennt die höchste Stichprobe, ist also nur so präzise wie die Stichprobenerfassung. Inkrementelle Syncs erfassen in dieser Reihenfolge: sync:extract, sync:resolve:load_nodes, sync:resolve:build_caches, sync:resolve:refs, sync:variants, sync:done. Ein vollständiger Index erfasst index:extract, index:resolve:build_caches, index:resolve:refs, index:resolve:done, index:insert, index:done.

Jeder Wert wird nach der Arbeit erfasst, die er benennt. Früher wurden sie davor erfasst, sodass jede Stichprobe den RSS des vorherigen Schritts unter dem Label des nächsten Schritts meldete – was 73 MiB der Knotenlast zuschrieb, die tatsächlich vom Laden der unaufgelösten Referenzen stammte, einem Schritt ohne eigene Stichprobe, und eine Speicheruntersuchung monatelang auf das falsche Subsystem lenkte (#409). Wenn Sie eine Phase hinzufügen, erfassen Sie die Stichprobe nach der Arbeit, nicht davor, und fügen Sie eine für jeden Schritt hinzu, der groß genug ist, um den Spitzenwert zu halten.

Sitzungs- und Lebensdauerzähler

tokensave current-counter          # show per-project session counter
tokensave reset-counter            # reset the session counter
tokensave status                   # shows project + global lifetime totals + cost

tokensave status rendert die Projektindex-Statistiken, die Sprachaufschlüsselung, die Kostenzeile (heute / 7 Tage / Effizienz) sowie die Projekt- und weltweiten Lebensdauergesamtsummen:

Weltweiter Zähler

Alle tokensave-Benutzer tragen zu einem anonymen Aggregatzähler bei. tokensave status zeigt sowohl Ihre Projektsumme als auch die weltweite Summe. Der Upload sendet nur eine einzelne Zahl (z. B. 4823) ohne identifizierende Informationen. Deaktivieren Sie dies mit tokensave disable-upload-counter.

Index-Frische

tokensave hält den Graphen ohne Hintergrund-Daemon oder Dateisystem-Watcher auf Betriebssystemebene aktuell.

Bedarfsgesteuerte Veraltungsprüfung. Jeder MCP-Tool-Aufruf prüft, ob indizierte Dateien seit dem letzten Sync geändert wurden. Wenn veraltete Dateien gefunden werden, werden sie vor der Rückgabe der Tool-Antwort neu extrahiert. Eine 30-Sekunden-Abklingzeit verhindert, dass aufeinanderfolgende Aufrufe den Baum bei jedem Tastendruck erneut durchlaufen.

Aufhol-Sync beim Verbinden. Wenn der MCP-Server startet, führt er sofort einen nicht blockierenden Aufhol-Sync aus, der alle Änderungen aufnimmt, die vorgenommen wurden, während kein Agent angeschlossen war – ein git pull, eine IDE-Bearbeitung, ein Build-Schritt – sodass der allererste Tool-Aufruf einer Sitzung einen frischen Index sieht.

Multi-Agent-Arbeit und Git-Worktrees. Wenn mehrere Agenten gleichzeitig am selben Projekt arbeiten, ist die starke Annahme, dass jeder Agent in seinem eigenen Git-Worktree arbeitet. Worktrees sind unabhängige Dateisystem-Checkouts desselben Repositorys: Agent A und Agent B haben jeweils ihre eigene Kopie jeder Datei, sodass sie sich nie gegenseitig laufende Bearbeitungen überschreiben. tokensave erkennt automatisch, wenn eine Abfrage aus einem Worktree stammt, der im Haupt-Checkout verschachtelt ist, und liefert Ergebnisse aus dem korrekten Branch-Graphen. Änderungen akkumulieren unabhängig und werden schließlich über Git-Merge oder Rebase abgeglichen – derselbe Prozess wie bei jeder anderen parallelen Entwicklung. Dieses Design vermeidet die Komplexität und Fehlermodi von agentenübergreifendem Sperren über ein gemeinsames veränderliches Verzeichnis.

Nur-CLI-Workflows. Wenn Sie tokensave-Befehle ohne angeschlossenen Agenten (kein MCP-Server) ausführen, läuft die Veraltungsprüfung zwischen den Befehlen nicht. Installieren Sie Git-Hooks, um den Index nach jedem Commit oder Klon automatisch frisch zu halten:

cp scripts/post-commit scripts/post-checkout .git/hooks/
chmod +x .git/hooks/post-commit .git/hooks/post-checkout

Upgrade von 5.x

Der eigenständige tokensave daemon-Befehl und sein launchd/systemd/Windows-Dienst-Autostart wurden in 6.0.0 entfernt. Der eingebettete Dateisystem-Watcher auf Betriebssystemebene, der den Daemon ersetzte, wurde selbst in 6.1.1 entfernt (er verursachte übermäßige CPU- und Speichernutzung auf großen Monorepos mit tiefen node_modules- oder target-Bäumen). Das oben beschriebene bedarfsgesteuerte Veraltungsmodell ist das aktuelle Design.

Wenn Sie noch einen Daemon-Autostart von 5.x haben, entfernen Sie ihn:

• macOS: launchctl unload ~/Library/LaunchAgents/com.tokensave.daemon.plist && rm ~/Library/LaunchAgents/com.tokensave.daemon.plist
• Linux: systemctl --user disable --now tokensave-daemon && rm ~/.config/systemd/user/tokensave-daemon.service
• Windows: sc.exe delete tokensave-daemon (aus einem Terminal mit erhöhten Rechten)

Wenn Sie sich nicht an den genauen Namen erinnern: launchctl list | grep tokensave / systemctl --user list-units | grep tokensave / sc.exe query state= all | findstr -i tokensave.

Selbst-Upgrade

tokensave upgrade                  # upgrade to latest in current channel
tokensave channel                  # show current channel (stable/beta)
tokensave channel beta             # switch to beta channel
tokensave channel stable           # switch back to stable

tokensave upgrade lädt das korrekte Plattform-Binary von GitHub-Releases herunter und ersetzt das laufende Binary direkt. Unterstützt Stable- und Beta-Kanäle unabhängig.

Versionierung & Upgrades

tokensave-Versionsnummern sehen aus wie SemVer, folgen ihr aber nicht: Die Komponente, die sich ändert, kodiert die Wartung, die das Update erfordert, die tokensave automatisch beim nächsten Start durchführt – Sie führen nie eine Neuinstallation oder Neuindizierung von Hand durch.

Globale Neuinstallation. Beim ersten Start eines neuen Minor- oder Major-Builds führt tokensave still install für jeden registrierten Agenten erneut aus, sodass die Agentenkonfiguration immer auf das aktuelle Binary zeigt und den aktuellen Tool-Satz bereitstellt. Patch-Bumps überspringen dies – der Versionsmarker wird einfach weitergeschaltet.

Die Neuinstallation ist wirklich still: Die pro-Agenten-Setup-Ausgabe, die Sie bei einem expliziten tokensave install sehen, wird hier unterdrückt, sodass sie nie vor einem gewöhnlichen tokensave init oder tokensave sync erscheint. Wenn die Konfiguration eines Agenten nicht aktualisiert werden kann – die App ist nicht installiert oder ihre Konfiguration liegt an einem schreibgeschützten Ort – erhalten Sie eine Zeile, die die fehlgeschlagenen Agenten benennt:

warning: could not refresh tokensave config for: copilot.
  Run tokensave install to see the error.

Führen Sie tokensave install aus, um den zugrunde liegenden Fehler zu sehen. Die Versionsmarker werden in beiden Fällen weitergeschaltet, sodass ein Konfigurationspfad, der nie beschrieben werden kann, einmal pro Upgrade gemeldet wird, statt bei jedem nachfolgenden Befehl erneut versucht zu werden.

Projekterzwungene Neuindizierung (nur Major). Ein Major-Bump bedeutet, dass Projektindizes neu aufgebaut werden müssen. tokensave tut dies verzögert und pro Projekt: Beim ersten MCP-Tool-Aufruf in einem Projekt nach einem Major-Upgrade startet es eine Hintergrund-Neuindizierung (äquivalent zu tokensave sync --force), die die Tool-Antwort nie blockiert.

Brew-/Cargo-Fallback. Externe Upgrades, die das Binary außerhalb von tokensave upgrade ersetzen – brew upgrade tokensave oder cargo install tokensave – werden auf dieselbe Weise erkannt: Wenn die laufende Version neuer ist als die letzte Version, die eine Installation durchgeführt hat, läuft die Neuinstallation beim nächsten Start, genau wie nach einem Selbst-Upgrade.

Siehe TOKENSAVE-VERSIONING.md für die Gründe, warum tokensave von SemVer abweicht (das Kodieren der Wartung in der Version ist es, was Upgrades ohne Zutun möglich macht), die Marker-Mechanik, die unabhängige Datenbankschema-Version und die Maintainer-Regeln für Releases.

CLI-Referenz

tokensave init [path]              # Initialize a new project (full index)
tokensave sync [path]              # Incremental sync (must be initialized first)
tokensave sync --force [path]      # Force a full re-index
tokensave sync --doctor [path]     # Sync and list added/modified/removed files
tokensave status [path]            # Show statistics + cost summary
tokensave status [path] --json     # Show statistics (JSON output)
tokensave status --details         # Include node-kind breakdown
tokensave cost [range]             # Token cost summary (default: 7d)
tokensave cost --by-model          # Cost grouped by model
tokensave cost --by-task           # Cost grouped by task category
tokensave cost --export json|csv   # Export cost data
tokensave query <search> [path]    # Search symbols
tokensave files [--filter dir] [--pattern glob] [--json]   # List indexed files
tokensave affected <files...> [--stdin] [--depth N]        # Find affected test files
tokensave install [--agent NAME]   # Configure agent integration
tokensave reinstall                # Refresh settings for all installed agents
tokensave uninstall [--agent NAME] # Remove agent integration
tokensave serve [--idle-timeout-secs N]   # Start MCP server (N: exit after N idle seconds)
tokensave servers [--json]         # List running servers and the index each one holds
tokensave monitor                  # Live TUI showing MCP calls across all projects
tokensave memory [--clean]         # Per-instance RSS report for all tokensave processes
tokensave upgrade                  # Self-update to latest version
tokensave channel [stable|beta]    # Show or switch update channel
tokensave doctor [--agent NAME]    # Check installation health
tokensave githooks [on|off] [--local]  # Manage git hooks (--local: this repo only, no core.hooksPath)
tokensave branch add|list|remove|removeall|gc   # Multi-branch management
tokensave current-counter          # Show per-project token counter
tokensave reset-counter            # Reset per-project token counter
tokensave disable-upload-counter   # Opt out of worldwide counter uploads
tokensave enable-upload-counter    # Re-enable worldwide counter uploads

tokensave doctor

Führen Sie einen umfassenden Gesundheitscheck Ihrer tokensave-Installation durch:

tokensave doctor

Prüfungen: Binary-Speicherort, Projektindex, globale DB, Benutzerkonfiguration, Agentenintegration (MCP-Server, Hooks, Berechtigungen, Prompt-Regeln) und Netzwerkkonnektivität. Wenn nach einem Upgrade Tool-Berechtigungen fehlen, werden Sie aufgefordert, tokensave install auszuführen. Verwenden Sie --agent, um nur einen bestimmten Agenten zu prüfen.

Doctor validiert außerdem, dass jeder installierte Hook den korrekten tokensave-Unterbefehl verwendet, und repariert defekte Hooks automatisch.

So funktioniert es mit Claude Code

Nach der Konfiguration verwendet Claude Code automatisch tokensave, anstatt Rohdateien zu lesen, wenn es Ihre Codebasis verstehen muss. Drei Ebenen verstärken sich gegenseitig:

Das Ergebnis: Claude erhält dasselbe Codeverständnis mit weit weniger Tokens. Ein typischer Explore-Agent liest 20–50 Dateien; tokensave liefert die relevanten Symbole, Beziehungen und Code-Ausschnitte aus seinem vorgebauten Index.

Netzwerkaufrufe & Datenschutz

Die Kernfunktionalität von tokensave (Indizierung, Suche, Graph-Abfragen, MCP-Server) ist zu 100 % lokal – Ihr Code verlässt nie Ihren Rechner.

Der weltweite Zähler-Upload sendet ein einzelnes HTTP-POST mit einem JSON-Body wie {"amount": 4823}. Keine Cookies, kein Tracking, keine Benutzer-ID. Der Cloudflare-Worker protokolliert das Land Ihrer IP-Adresse (aus Anfrage-Headern abgeleitet) für aggregierte geografische Statistiken – Ihre tatsächliche IP-Adresse wird nicht gespeichert.

Die Modellpreis-Aktualisierung ruft eine öffentliche JSON-Datei von GitHub ab (raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_context_window.json), um die Claude-Modellpreise für tokensave cost aktuell zu halten. Es werden keine Daten gesendet – es ist ein einfaches HTTPS-GET. Die Antwort wird bei ~/.tokensave/pricing.json für 24 Stunden zwischengespeichert. Wenn der Abruf fehlschlägt, verwendet tokensave seine eingebettete Preistabelle.

50+ Sprachen

tokensave unterstützt mehr als 50 Programmiersprachen, organisiert in drei Stufen, die über Cargo-Feature-Flags gesteuert werden. Jede Stufe enthält alle Sprachen der darunterliegenden Stufe. Markdown-Header werden als Module-Knoten mit hierarchischen Contains-Kanten extrahiert, sodass die Dokumentstruktur neben Quellcode an Graph-Abfragen teilnimmt.

Lite – --no-default-features

Immer kompiliert. Das kleinste Binary für die beliebtesten Sprachen, plus Svelte und Astro (Skriptblock-Extraktion über den TypeScript-Extraktor, keine zusätzliche Grammatik-Abhängigkeit).

Mittel (Lite + 9 weitere) – --features medium

Voll (Medium + alles andere) -- Standard

Einzelne Sprachen können auch ohne eine vollständige Stufe gezielt ausgewählt werden:

cargo install tokensave --no-default-features --features lang-nix,lang-bash

Alle Extraktoren teilen dieselbe Tiefe: Funktionen, Klassen, Methoden, Felder, Importe, Aufrufgraphen, Vererbungsketten, Docstrings, Komplexitätsmetriken, Dekorator-/Annotations-Extraktion und sprachübergreifende Abhängigkeitsverfolgung.

tokensave vs. CodeGraph

tokensave ist eine vollständige Rust-Neuimplementierung von CodeGraph (Node.js/TypeScript). Beide erstellen semantische Codegraphen für KI-Codierungsagenten, unterscheiden sich jedoch erheblich in Umfang und Fähigkeiten.

CodeGraph hat den Ansatz Pionierarbeit geleistet und bleibt eine solide Wahl, wenn Sie npm-Tooling bevorzugen und nur eine Claude-Code-Integration benötigen. tokensave erweitert das Konzept um tiefere Analysen, mehr Agenten, Multi-Branch-Unterstützung und ein natives Binärprogramm ohne Laufzeitabhängigkeiten.

Für detaillierte Vergleiche mit CodeGraph, Dual-Graph (GrapeRoot), code-review-graph und OpenWolf siehe docs/COMPARABLE-TOOLS.md.

Warum tokensave gegenüber den Alternativen

Mehrere Tools reduzieren die Token-Nutzung für KI-Codierungsagenten. Hier ist, warum tokensave sich abhebt.

Ein einziges natives Binärprogramm, null Abhängigkeiten

Jede Alternative erfordert eine Laufzeit: Python, Node.js oder beides. tokensave wird als ein einziges ~25 MB großes Rust-Binärprogramm mit allen 50+ gebündelten Tree-Sitter-Grammatiken ausgeliefert. Nichts anderes muss installiert werden.

Tiefste Code-Intelligenz

tokensave arbeitet auf Symbolebene: Funktionen, Strukturen, Felder, Aufrufkanten, Typhierarchien, Komplexitätsmetriken. Alternativen wie Dual-Graph (GrapeRoot) arbeiten auf Dateiebene – sie wissen, welche Dateien existieren, können aber nicht beantworten: „Wer ruft diese Funktion auf?“ oder „Was bricht, wenn ich diese Struktur ändere?“ tokensaves 80+ spezialisierte MCP-Tools decken Aufrufgraphen-Traversierung, Auswirkungsanalyse, Erkennung von totem Code, Test-Zuordnung, Umbenennungsvorschau, Typhierarchien, Erkennung zirkulärer Abhängigkeiten, Komplexitäts-Ranking, Code-Gesundheitsanalysen (Gini, DSM, Abhängigkeitstiefe, risikogewichtete Testlücken), atomare Bearbeitungsprimitive und mehr ab. Der nächste Konkurrent (code-review-graph) hat 22 Tools; andere haben 5–9.

Breiteste Agentenunterstützung

Mehr als ein Dutzend KI-Codierungsagenten-Integrationen mit pro-Agent nativen Konfigurationsformaten. Kein anderes Tool deckt so viele Agenten mit einer so tiefen Integration ab. Claude Code erhält Hooks, Prompt-Regeln und automatisch erlaubte Tool-Berechtigungen. Kiro erhält globale MCP-Konfiguration, tokensave.md-Steuerung als Ressource geladen, einen verwalteten Agenten mit großzügiger integrierter/tokensave-Tool-Genehmigung sowie Hooks für Delegations-Schutzmaßnahmen und Post-Write-Synchronisierung. Andere Agenten erhalten die MCP-Server-Registrierung in ihrem nativen Konfigurationsformat.

Multi-Branch-Indizierung

Das einzige Tool in diesem Bereich mit optionalen Pro-Branch-Graphdatenbanken und Cross-Branch-Diff und -Suche. Wenn aktiviert, ist der Wechsel zwischen Branches sofort – keine Neuindizierung erforderlich.

Token-Verfolgung pro Aufruf

Das einzige Tool, das genau meldet, wie viele Token jeder einzelne MCP-Tool-Aufruf gespart hat, plus einen Live-TUI-Monitor über alle Projekte und Lebensdauerzähler.

Vollständig Open Source

MIT-lizenzierter Rust-Code, Ende-zu-Ende prüfbar. Dual-Graphs Kern-Engine (graperoot auf PyPI) ist proprietär – Sie können nicht sehen, was sie mit Ihrem Codegraphen macht. OpenWolf ist AGPL-3.0, was erfordert, dass abgeleitete Werke Open Source sein müssen.

Leistung

Vollindex-Benchmark auf einer 1.782-Dateien umfassenden gemischten Rust/Java/Scala-Codebasis (57K Knoten, 103K Kanten):

Fehlerbehebung

„tokensave not initialized“

Das .tokensave/-Verzeichnis existiert nicht in Ihrem Projekt.

tokensave init

MCP-Server verbindet nicht

Der KI-Agent sieht die tokensave-Tools nicht.

1. Stellen Sie sicher, dass die Agentenkonfiguration den tokensave-MCP-Server enthält (führen Sie tokensave doctor aus)
2. Starten Sie den Agenten vollständig neu
3. Überprüfen Sie, dass tokensave in Ihrem PATH ist: which tokensave

Fehlende Symbole in der Suche

• Führen Sie tokensave sync aus, um den Index zu aktualisieren
• Überprüfen Sie, ob die Sprache unterstützt wird (siehe Tabelle oben)
• Stellen Sie sicher, dass die Datei nicht durch .gitignore ausgeschlossen ist

Indizierung ist langsam

Große Projekte benötigen beim ersten vollständigen Index länger.

• Nachfolgende Ausführungen verwenden inkrementelle Synchronisierung und sind viel schneller
• Verwenden Sie tokensave sync (nicht --force) für tägliche Aktualisierungen
• Veraltung wird automatisch bei jedem MCP-Tool-Aufruf geprüft, während ein Agent verbunden ist

Deaktivieren von tokensave für bestimmte Projekte

Wenn ein Projekt zu groß ist und tokensave zu viel RAM verwendet, können Sie den MCP-Server pro Projekt deaktivieren, indem Sie TOKENSAVE_DISABLE_SERVER=true in dessen Umgebung setzen. Der Server beendet sich sauber, ohne zu initialisieren.

Claude Code – fügen Sie zu Ihrer Projekt-.claude/settings.json hinzu:

{
  "mcpServers": {
    "tokensave": {
      "command": "tokensave",
      "args": ["serve"],
      "env": {
        "TOKENSAVE_DISABLE_SERVER": "true"
      }
    }
  }
}

Andere Agenten – setzen Sie die Umgebungsvariable in der Konfiguration, die Ihr Agent zum Starten von MCP-Servern verwendet.

Sie können sie auch global über die Shell setzen (TOKENSAVE_DISABLE_SERVER=true claude), aber dies deaktiviert den tokensave-MCP-Server für jedes Projekt in der Sitzung.

DISABLE_TOKENSAVE=true bleibt als veralteter Kompatibilitäts-Alias für Konfigurationen unterstützt, die erstellt wurden, bevor diese Variable mit Namespace versehen wurde.

Ursprung

Dieses Projekt ist ein Rust-Port der ursprünglichen CodeGraph-TypeScript-Implementierung von @colbymchenry. Der Port behält dieselbe Architektur und MCP-Tool-Schnittstelle bei, nutzt jedoch Rust für Leistung und native Tree-Sitter-Bindungen.

Erstellung

cargo build --release                          # full (50+ languages, default)
cargo build --release --features medium        # medium tier
cargo build --release --no-default-features    # lite (smallest binary)

cargo test                                     # run all tests (requires full)
cargo check --no-default-features              # verify lite compiles
cargo clippy --all

Stern-Verlauf

Sponsoren

Kostenlose Codesignierung unter Windows bereitgestellt von SignPath.io, Zertifikat von SignPath Foundation

Lizenz

MIT-Lizenz – siehe LICENSE für Details.

tokensave.dev