# Ge en AI-agent kontext om ett stort repo utan en lokal indexerare

Canonical source: https://maguyva.ai/sv/blog/large-repo-context-without-a-local-indexer

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-08-14 · Author: Maguyva Team

> Hur du ger en kodande agent en sökbar karta över ett stort repo från molnet, utan att köra en lokal indexerare på din laptop.

Ett stort repo får inte plats i ett kontextfönster, och om du någonsin pekat en laptop-indexerare mot ett riktigt monorepo vet du att det inte får bekväm plats där heller — RAM-minnet skjuter i höjden, den första indexeringen tar en timme, och din agent börjar ändå nästa session med att gissa vilka filer som spelar roll.

Det vanliga svaret är att köra en indexerare bredvid editorn, och för ett repo som får bekväm plats på en maskin är det ett bra svar. Om ditt monorepo redan indexeras snabbt i Cursor och det är det enda stället du behöver kartan, har den här texten inget att tillägga — hoppa över den.

Den här texten handlar om det andra fallet — när en agent behöver en sökbar karta över ett stort repo, och du inte vill köra en lokal indexerare för att få den.

## När en lokal indexerare är fel verktyg

Ett lokalt index förutsätter att koden lever på maskinen som frågar den, och i verklig monorepo-skala spänns det antagandet även inom en enda editor. Repot är helt enkelt större än du vill hålla 'varmt' på en laptop: du arbetar i ett paket medan påverkansradien ligger tre kataloger bort, och en första kall indexering av ett träd på två miljoner rader är inte något du vill genomlida två gånger — varken på din egen maskin, eller på en CI-runner som aldrig tidigare klonat det trädet. Eller så borde en kollega kunna fråga samma karta som du, utan att vänta på att den egna maskinen ska kämpa sig igenom samma index.

Inget av detta är en anledning att kasta bort en bra editor-indexerare. Det är en anledning att dessutom ha en värdbaserad karta som vilken som helst av dina agenter kan fråga via MCP.

Och skalproblemet går djupare än 'för många filer att klistra in'. På ett stort träd är den intressanta frågan nästan aldrig 'visa mig den här filen' — det är vilken fil, vilken symbol, vilka anropare, vilka tester. En agent som börjar med att lista `src/` och läsa de tre första träffarna missar glatt handlern i `apps/api` och den genererade klienten i `packages/sdk`. Det du behöver är hämtning byggd från hela trädet, sedan rankad, sedan citerad.

## Vad 'kontext om ett stort repo' egentligen betyder

Att dumpa filer i prompten är inte kontext — det är en mindre, sämre kopia av trädet. Det din agent verkligen behöver är att ställa frågor och få citerade svar tillbaka: var den här symbolen är definierad och vem som anropar den, vad som beror på modulen jag är på väg att ändra, vilken testfil som täcker det här beteendet, och hur trädet ser ut *nu*, inte förra kvartalet.

De svaren måste komma från ett index byggt från ditt repo, inte från modellens minne av andras repon, och indexet måste leva någonstans utanför agentens kontextfönster. För det här problemet borde det också leva någonstans utanför din laptop.

Ännu en sak instruktionsfiler inte kan göra åt dig: `CLAUDE.md` och `AGENTS.md` är rätt plats för konventioner och beteende, men de är inte en levande, rankad, sökbar karta över ett träd på två miljoner rader. Använd regler för beteende; använd repo-intelligens för fakta.

## Vi bygger kartan i molnet, frågar den från vilken klient som helst

Maguyva är ett fjärranslutet MCP-lager för kodbaskontext. Du kopplar GitHub, väljer dina repon, och kan gå därifrån medan molnpipelines analyserar trädet, bygger symboler och grafkanter, och underhåller en rankad karta — aldrig en lokal indexerare.

När du pushar kod analyseras ändrade filer inkrementellt, och graf- och rankningslagren byggs om enligt ett schema: dagligen i gratisplanen, varje timme i betalplanerna. Varje ögonblicksbild är tidsstämplad, så din agent kan avgöra vilken version av trädet den läser. Den ärliga begränsningen här är osynkroniserat lokalt arbete — en ändring som bara finns i ditt arbetsträd, aldrig pushad, är ännu inte i den värdbaserade kartan.

Sedan ansluter du vilken klient du än redan använder genom att lägga till en API-nyckel i dess MCP-konfiguration. Det finns installationsguider för 24 dokumenterade MCP-klienter, och vilken annan MCP-kompatibel klient som helst som stöder standardkonfiguration kan också ansluta. Om Cursor är där du bor går [Cursor-sidan](/sv/for-cursor) igenom den vägen; samma server svarar Claude Code, VS Code, Windsurf, Codex CLI och resten.

Du byter inte editor. Du ger din agent en verktygsyta — 11 MCP-verktyg för sökning, symboler, beroendeanalys, filhämtning och repo-kontext — med täckning över 279 fler språk och textbaserade teknologier, vilket betyder mer än du tror på ett monorepo som slutade vara ett enda språk för länge sedan.

Svar kommer tillbaka underbyggda, som filsökvägar med radnummer. Semantisk, strukturell, graf- och textsökning smälts samman till rankade resultat, så att en fråga som 'vad beror på parseConfig' varken ger dig en grep-dump eller ett enda semantiskt utdrag, utan den handfull platser som verkligen spelar roll.

## En konkret guide

Börja inte med att indexera hela företaget. Här är vägen som fungerar:

1. Välj ett repo du redan känner väl — ett paket du kan bedöma för hand är värt mer än det största trädet du har.
2. Börja gratis: 3 repon, 50k indexerade rader, alla 11 verktyg, ingen månatlig frågekvot. Om ditt representativa repo är större listar [prissidan](/sv/pricing) arbetsytenivåerna ($0, $19, $49, $149) efter indexerad omfattning — inte efter antal platser.
3. Anslut GitHub och vänta tills den första indexeringen är klar. Du kompilerar inget lokalt.
4. Anslut MCP-klienten — några rader konfiguration. Maguyva är en fjärransluten MCP-server, så det finns inga plugins, inga tillägg, och ingen andra editor att anamma.
5. Ställ en fråga du kan verifiera. 'Vad beror på parseConfig?' eller 'Var hanteras utgången av inloggningssessionen?' Öppna sedan de citerade `file.ext:line`-resultaten och kontrollera dem mot trädet framför dig.
6. Först efter att citaten överlever den kontakten låter du agenten redigera.

Om det första repot passar bra och ditt träd är stort, höj arbetsytan för att matcha dina indexerade rader och ombyggnadstakt. Människor och agenter delar samma användarantal — Maguyva tar betalt per arbetsyta, inte per plats — så att lägga till en tredje agent i loopen kostar dig ingenting.

Aktiveringstestet är detsamma som [dokumentationen](/sv/docs) rekommenderar för varje första körning: indexera ett repo du redan känner till, ställ en fråga du kan verifiera. Ett stort repo förändrar inte testet; det gör bara en felaktig första fil dyrare.

## Vad du bör hålla koll på efter anslutning

Håll koll på tre saker. Fräschhet: betalplaner byggs om varje timme, gratisplaner dagligen, och opushat lokalt arbete kommer inte att finnas i kartan — det är avvägningen du gör. Omfattning: indexera en representativ uppsättning repon, inte varje arkiverad fork; gratisnivån är medvetet dimensionerad för att ta reda på om svaren är värda att behålla. Och verifiering: en karta över ett stort repo som inte kan citera sökvägar och radnummer är bara en långsammare gissningsmaskin, så låt din agent visa platsen innan den levererar patchen.

Kör sedan samma test du skulle köra på ett litet repo. Indexera ett repo du redan känner till. Ställ en fråga du kan verifiera. Om kartan är verklig slutar din agent att börja från ett kallt träd.

`// no laptop got hot building this map.`