Graphify macht Ordner zu Wissensgraphen. Die 71.5x brauchen Kontext

Graphify hat diese Woche rund 7,300 Sterne eingesammelt, steht damit weit oben in GitHubs Wochentrend und hat die Gesamtzahl über 137,000 geschoben. Der Werbesatz ist eine Zeile lang: den Coding-Agenten auf einen Ordner richten, /graphify . tippen, und man bekommt einen Wissensgraphen über alles, was darin liegt.

Interessant ist nicht der Graph. Interessant ist die Zahl daneben: 71.5x weniger Token pro Abfrage, gemessen gegen das Lesen der Rohdateien. Wenn das allgemein hält, ist das kein Bequemlichkeitswerkzeug, sondern eine Veränderung dessen, wie viel Kontext ein Agent tragen muss.

Woher es kommt

Der Autor safishamsi rahmt das Projekt als Antwort auf eine sehr konkrete Angewohnheit von Andrej Karpathy: einen /raw-Ordner zu unterhalten, in dem Papers, Tweets, Screenshots und Notizen landen, und darin später nichts mehr wiederzufinden. Das Problem ist nachvollziehbar, und es ist eine ehrlichere Herkunftsgeschichte als die meisten, weil sie ein Fehlermuster beschreibt und keinen Markt.

Das erklärte Ziel ist enger als „durchsuche deine Dokumente“. Es geht darum, etwas Dauerhaftes zu erzeugen, das Sitzungen überlebt, und ausdrücklich zu benennen, was extrahiert und was erschlossen wurde. Jede Kante im Graphen trägt ein Label: EXTRACTED, INFERRED oder AMBIGUOUS. Das ist eine ungewöhnliche Designentscheidung und meiner Ansicht nach der wertvollste Teil des Ganzen.

Was es tatsächlich tut

Die Installation sind zwei Befehle, und ja, der PyPI-Paketname ist vorübergehend falsch:

pip install graphifyy && graphify install

Das doppelte Y ist ein Namensstreit, kein Tippfehler. CLI und Skill-Befehl heißen weiterhin beide graphify. Unter Windows muss der Python-Scripts-Ordner in den PATH, wenn der Befehl nach der Installation nicht erkannt wird – oder man nimmt pipx install graphifyy und umgeht das Problem.

Dann, in Claude Code, in einem beliebigen Verzeichnis:

/graphify .
/graphify ./raw --mode deep
/graphify query "what connects attention to the optimizer?"
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

Die Ausgabe landet in graphify-out/. Dort liegen eine interaktive graph.html, durch die man sich klicken kann, ein obsidian/-Ordner, der sich als Vault öffnen lässt, eine persistente graph.json, die man auch Wochen später abfragen kann, ohne irgendetwas neu zu lesen, ein cache/ mit SHA256 als Schlüssel, damit Wiederholungsläufe nur geänderte Dateien anfassen, und eine GRAPH_REPORT.md, die die sogenannten God Nodes auflistet – die Konzepte mit dem höchsten Grad – dazu „überraschende Verbindungen“, sortiert nach einem zusammengesetzten Score, in dem Kanten von Code zu Paper schwerer wiegen als Kanten von Code zu Code.

Der multimodale Teil ist kein Marketing. Codedateien laufen durch tree-sitter zur AST-Analyse plus einen Durchlauf über den Callgraph. Markdown, PDFs und Bilder laufen durch Claude: Konzepte und Beziehungen aus Prosa, Zitations-Mining aus Papers, und Bildverstehen für Screenshots, Diagramme, Whiteboard-Fotos und Bilder in anderen Sprachen.

Dazu kommen Exporte, die für alle wichtig sind, die nicht in diesem Werkzeug wohnen wollen: --svg, --graphml für Gephi oder yEd, und --neo4j, das eine cypher.txt erzeugt, statt eine laufende Datenbank zu verlangen. Der Stack ist NetworkX, Leiden-Clustering über graspologic, tree-sitter und vis.js. Kein Server. Nichts verlässt die Maschine außer den Claude-Aufrufen.

Die 71.5x, nachgerechnet

Der Benchmark-Korpus umfasst 52 Dateien: Karpathys Repositories, fünf Papers, vier Bilder. Ergebnis: 71.5x weniger Token pro Abfrage im Vergleich zum Lesen der Rohdateien.

Das Repository ist ungewöhnlich ehrlich dabei, wie sich das skaliert, und das ist selten genug, um den Kern zu zitieren: Die Token-Ersparnis wächst mit der Korpusgröße, und bei sechs Dateien liegt der Wert des Graphen in struktureller Klarheit statt in Kompression, weil sechs Dateien ohnehin in ein Kontextfenster passen. Ihr eigenes Beispiel, graphify-Quellcode plus das Transformer-Paper, ergibt 5.4x. Bei sechs synthetischen Bibliotheksdateien etwa 1x.

Die Form stimmt. Liegt der Korpus schon innerhalb eines Kontextfensters, spart man keine Token, man kauft eine Karte. Bei fünfzig Dateien gemischter Typen ist die Ersparnis real und groß, weil die Alternative nicht darin besteht, die Dateien einmal zu lesen, sondern sie über mehrere Turns hinweg immer wieder zu lesen, jedes Mal, wenn ein Agent den Faden verliert.

Der Vergleich schmeichelt graphify in die eine Richtung und verkauft es in der anderen zu billig. Rohdateien sind die schlechtestmögliche Baseline; ein gut abgestimmter Retrieval-Index sähe im Vergleich besser aus als Rohdateien. Aber ein Retrieval-Index liefert Passagen, und graphify liefert Beziehungen: Die Antwort auf „was verbindet Attention mit dem Optimizer“ ist keine Passage, sondern ein Pfad. Das sind unterschiedliche Abfragetypen, und ein Vektorspeicher bedient nur einen davon.

„Kein Vektorspeicher“ ist eine echte Architekturposition

Die meisten Retrieval-Systeme zerlegen Text in Chunks, betten ihn ein und machen Nächste-Nachbarn-Suche. Graphify überspringt all das: lokale, deterministische AST-Analyse für Code, LLM-Extraktion für Prosa und Bilder, dann ein Graph. Kein Embedding-Schritt, keine Ähnlichkeitssuche.

Was man stattdessen bekommt, ist Erklärbarkeit. Fragt man, warum zwei Dinge verbunden sind, bekommt man die Kanten, jede davon beschriftet damit, ob sie aus der Quelle extrahiert oder vom Modell erschlossen wurde. Ein Vektorindex kann das nicht sagen. Er kann nur sagen, dass die Kosinusdistanz klein war.

Der Preis ist Abdeckung. Ein Graph weiß nur, was der Extraktor gefunden hat. Hat der Extraktionslauf eine Beziehung übersehen, bringt keine Abfrage sie zutage, und es gibt keinen unscharfen Fallback. Das Label AMBIGUOUS ist das ehrliche Eingeständnis davon, und das Flag --mode deep existiert, weil der Standardlauf beim Erschließen von Kanten zurückhaltend ist.

Wo es seinen Platz verdient

Zwei Workflows, nach meiner Erfahrung mit solchen Werkzeugen.

Der erste ist das Einarbeiten in eine unbekannte Codebasis. Nicht „wo ist Funktion X“ – dafür reicht grep –, sondern „welche tragenden Konzepte gibt es hier, und welche davon berühren den Abrechnungscode“. Das ist eine Graphfrage, und der God-Node-Report beantwortet sie in einer Form, die man in zwei Minuten gelesen hat.

Der zweite ist der Multi-Agent-Fall. Wenn mehrere Agenten parallel Code schreiben, veraltet das Bild, das jeder von ihnen vom Repository hat, innerhalb von Minuten. Ein Graph, der bei jedem Commit neu gebaut wird (graphify hook install richtet einen Post-Commit-Hook ein) oder beim Speichern einer Datei (--watch), gibt jedem Agenten dieselbe aktuelle Karte statt fünf auseinanderlaufender Vermutungen.

Die offensichtliche Grenze: Das Ding ist zuerst als Claude-Code-Skill gebaut. Der manuelle Installationsweg legt eine SKILL.md in ~/.claude/skills/graphify/ ab und ergänzt eine Zeile in CLAUDE.md. Es gibt einen MCP-Server-Modus (--mcp), den andere Clients nutzen können, aber die Ergonomie ist erkennbar auf ein Ökosystem optimiert, und die Abhängigkeit von Claude bedeutet, dass der Extraktionslauf bei großem Korpus echtes Geld kostet.

Das ehrliche Urteil

Graphify ist keine Suchmaschine und sollte nicht als solche bewertet werden. Es ist ein dauerhaftes, prüfbares Modell davon, was in einem Ordner liegt, mit der ungewöhnlichen Eigenschaft, dass es sagt, welche Teile geraten sind. Bei einem Projekt mit 137,000 Sternen, das eine Woche lang trendet, ist die spannende Frage nicht, ob der Graph beeindruckend ist, sondern ob die Gewohnheit, Inferenz zu labeln, den Kontakt mit Nutzern übersteht, die einfach nur Antworten wollen.

Meine Vermutung: Die meisten werden query benutzen, die Kantenlabels ignorieren und graph.json nie öffnen. Diejenigen, die dabeibleiben, sind die, die die Karte brauchten, nicht die Lösungen.