Einem KI-Agenten Kontext eines großen Repos geben, ohne lokalen Indexer

Ein großes Repository passt nicht in ein Kontextfenster, und wenn du je einen Laptop-Indexer auf ein echtes Monorepo losgelassen hast, weißt du, dass es dort auch nicht bequem hineinpasst – der RAM schnellt hoch, der erste Index dauert eine Stunde, und dein Agent rät in der nächsten Sitzung immer noch, welche Dateien wichtig sind.

Die übliche Antwort ist, einen Indexer neben dem Editor laufen zu lassen, und für ein Repo, das bequem auf eine Maschine passt, ist das eine gute Antwort. Wenn dein Monorepo in Cursor schon schnell indiziert und das der einzige Ort ist, an dem du die Karte brauchst, hat dieser Beitrag nichts hinzuzufügen – überspring ihn.

Dieser Beitrag handelt vom anderen Fall – wenn ein Agent eine abfragbare Karte eines großen Repos braucht und du dafür keinen lokalen Indexer laufen lassen willst.

Wann ein lokaler Indexer das falsche Werkzeug ist

Ein lokaler Index setzt voraus, dass der Code auf der Maschine liegt, die ihn abfragt, und bei echter Monorepo-Größe gerät diese Annahme selbst innerhalb eines einzigen Editors ins Wanken. Das Repo ist schlicht größer, als du auf einem Laptop warmhalten willst: Du arbeitest in einem Paket, während der Auswirkungsradius drei Verzeichnisse weiter liegt, und einen kalten Erstindex eines Zwei-Millionen-Zeilen-Baums willst du dir nicht zweimal antun – weder auf deiner Maschine noch auf einem CI-Runner, der den Baum nie zuvor geklont hat. Oder ein Teammitglied sollte dieselbe Karte abfragen können wie du, ohne darauf zu warten, dass die eigene Maschine sich erst durch denselben Index arbeitet.

Nichts davon ist ein Grund, einen guten Editor-Indexer wegzuwerfen. Es ist ein Grund, zusätzlich eine gehostete Karte zu haben, die jeder deiner Agenten über MCP abfragen kann.

Und das Skalierungsproblem reicht tiefer als „zu viele Dateien zum Einfügen“. Auf einem großen Baum ist die interessante Frage fast nie „zeig mir diese Datei“ – sondern welche Datei, welches Symbol, welche Aufrufer, welche Tests. Ein Agent, der damit anfängt, src/ aufzulisten und die ersten drei Treffer zu lesen, verpasst mit Freude den Handler in apps/api und den generierten Client in packages/sdk. Was du brauchst, ist Retrieval, das aus dem gesamten Baum gebaut, dann gerankt, dann zitiert wurde.

Was „Kontext eines großen Repos“ wirklich bedeutet

Dateien in den Prompt zu kippen ist kein Kontext – es ist eine kleinere, schlechtere Kopie des Baums. Was dein Agent tatsächlich braucht, ist, Fragen zu stellen und zitierte Antworten zurückzubekommen: Wo ist dieses Symbol definiert und wer ruft es auf, was hängt von dem Modul ab, das ich gerade ändern will, welche Testdatei deckt dieses Verhalten ab, und wie sieht der Baum jetzt aus, nicht letztes Quartal.

Diese Antworten müssen aus einem Index kommen, der aus deinem Repo gebaut wurde, statt aus der Erinnerung des Modells an fremde Repos, und der Index muss anderswo leben als im Kontextfenster des Agenten. Für dieses Problem sollte er auch anderswo leben als auf deinem Laptop.

Noch etwas, was Instruktionsdateien nicht für dich leisten können: CLAUDE.md und AGENTS.md sind der richtige Ort für Konventionen und Verhalten, aber sie sind keine lebendige, gerankte, abfragbare Karte eines Zwei-Millionen-Zeilen-Baums. Nutze Regeln für Verhalten; nutze Repo-Intelligenz für Fakten.

Die Karte in der Cloud bauen, von jedem Client abfragen

Maguyva ist eine entfernte MCP-Codebase-Context-Schicht. Du verbindest GitHub, wählst deine Repositories, und gehst weg, während Cloud-Pipelines den Baum parsen, die Symbole und Graphkanten bauen und eine gerankte Karte pflegen – nie ein lokaler Indexer.

Wenn du Code pushst, werden geänderte Dateien inkrementell geparst, und die Graph- und Ranking-Schichten bauen sich nach einem Zeitplan neu auf: täglich im kostenlosen Plan, stündlich in bezahlten Plänen. Jeder Snapshot ist zeitgestempelt, sodass dein Agent erkennen kann, welche Version des Baums er liest. Die ehrliche Grenze hier ist unsynchronisierte lokale Arbeit – eine Änderung, die nur in deinem Arbeitsverzeichnis existiert und nie gepusht wurde, ist noch nicht in der gehosteten Karte.

Dann verkabelst du, welchen Client du auch nutzt, indem du einen API-Schlüssel zu dessen MCP-Konfiguration hinzufügst. Es gibt Einrichtungsanleitungen für 24 dokumentierte MCP-Clients, und jeder andere MCP-kompatible Client, der Standardkonfiguration unterstützt, kann sich ebenfalls verbinden. Wenn Cursor dein Zuhause ist, geht die Cursor-Seite diesen Weg; derselbe Server bedient Claude Code, VS Code, Windsurf, Codex CLI und den Rest.

Du wechselst den Editor nicht. Du gibst deinem Agenten eine Werkzeugoberfläche – 11 MCP-Tools über Suche, Symbole, Abhängigkeitsanalyse, Dateiabruf und Repository-Kontext – mit Abdeckung über 279+ Sprachen und textbasierte Technologien, was auf einem Monorepo, das schon lange keine einzelne Sprache mehr ist, mehr zählt, als man denkt.

Antworten kommen fundiert zurück, als Dateipfade mit Zeilennummern. Semantisches, strukturelles, Graph- und Textretrieval werden zu gerankten Ergebnissen fusioniert, sodass eine Frage wie „was hängt von parseConfig ab“ weder einen Grep-Dump noch einen einzelnen semantischen Chunk liefert, sondern die Handvoll Stellen, die tatsächlich zählen.

Eine konkrete Anleitung

Fang nicht damit an, die ganze Firma zu indizieren. Hier ist der Weg, der funktioniert:

1. Wähle ein Repository, das du schon gut kennst – ein Paket, das du von Hand beurteilen kannst, schlägt den größten Baum, den du hast.
2. Starte kostenlos: 3 Repos, 50.000 indizierte Zeilen, alle 11 Tools, kein monatliches Abfragelimit. Wenn dein repräsentatives Repo größer ist, listet die Preisseite die Workspace-Stufen ($0, $19, $49, $149) nach indiziertem Umfang – nicht nach Sitzplatzzahl.
3. Verbinde GitHub und warte, bis der erste Index fertig ist. Du kompilierst dabei nichts lokal.
4. Verkabele den MCP-Client – ein paar Zeilen Konfiguration. Maguyva ist ein entfernter MCP-Server, also gibt es keine Plugins, keine Erweiterungen und keinen zweiten Editor, den du übernehmen musst.
5. Stelle eine Frage, die du prüfen kannst. „Was hängt von parseConfig ab?“ oder „Wo wird der Ablauf der Login-Sitzung behandelt?“ Öffne dann die zitierten file.ext:line-Ergebnisse und prüfe sie gegen den Baum vor dir.
6. Erst wenn die Zitate diesen Kontakt überstehen, lässt du den Agenten editieren.

Wenn das erste Repo gut passt und dein Baum groß ist, erhöhe den Workspace passend zu deinen indizierten Zeilen und dem Rebuild-Rhythmus. Menschen und Agenten teilen sich dieselbe Nutzerzahl – Maguyva berechnet pro Workspace, nicht pro Sitzplatz –, sodass ein dritter Agent in der Schleife dich nichts kostet.

Der Aktivierungstest ist derselbe, den die Docs für jeden ersten Lauf empfehlen: ein Repo indizieren, das du schon kennst, eine Frage stellen, die du prüfen kannst. Ein großes Repo ändert den Test nicht; es macht nur eine falsche erste Datei teurer.

Worauf nach dem Verkabeln achten

Behalte drei Dinge im Blick. Aktualität: bezahlte Pläne bauen stündlich neu, kostenlose täglich, und ungepushte lokale Arbeit wird nicht in der Karte sein – das ist der Kompromiss, den du eingehst. Umfang: indiziere eine repräsentative Menge an Repos, nicht jeden archivierten Fork; die kostenlose Stufe ist bewusst so bemessen, dass du herausfindest, ob die Antworten das Behalten wert sind. Und Verifikation: eine Große-Repo-Karte, die keine Pfade und Zeilennummern zitieren kann, ist nur eine langsamere Rate-Maschine, also lass deinen Agenten den Ort zeigen, bevor er den Patch ausliefert.

Dann führe denselben Test durch, den du bei einem kleinen Repo durchführen würdest. Indiziere ein Repo, das du schon kennst. Stelle eine Frage, die du prüfen kannst. Wenn die Karte echt ist, hört dein Agent auf, von einem kalten Baum aus zu starten.

// no laptop got hot building this map.