Onbegrensd AI-geheugen: het Pinecone + Claude-systeem dat ik heb gebouwd
Vorige week dinsdag zat ik zes prompts diep in een strategische sessie met Claude voor een klant, toen het contextvenster zijn limiet bereikte. Weer. Het gesprek dat we drie dagen eerder hadden over hun ICP — verdwenen. De Gmail-thread waarin de oprichter hun grootste reden voor klantverloop uitlegde — verdwenen. De notities die ik had geplakt van een salescall van 90 minuten — samengeperst tot een vage samenvatting waar Claude details bij bleef verzinnen.
Ik sloot de chat. Opende een nieuwe. Begon opnieuw dezelfde achtergrondinformatie te typen die ik die week al vier keer had ingevoerd.
Dat was het moment waarop ik besloot dat ik klaar was met het oplossen van Claude’s geheugenprobleem op pure wilskracht. Het contextvenster wordt niet snel genoeg langer voor de manier waarop ik daadwerkelijk werk — namelijk over tientallen projecten, honderden e-mails en jaren aan notities die ik niet elke ochtend opnieuw aan een AI wil uitleggen. Dus bouwde ik iets wat ik al twee jaar wilde: een écht onbeperkt AI-geheugen met Pinecone en Claude, dat alles onthoudt wat ik invoer, zoekt op betekenis in plaats van op trefwoord, en integreert met Claude Code, Claude for Work en de desktop-apps zonder te breken.
Dit is geen theorie. Ik draai het nu drie weken op een echte workload — 200+ onderzoeksdocumenten, mijn laatste 90 dagen Gmail, projectnotities van klanten en chatlogs van lopende Claude-sessies. Hier lees je precies hoe ik het gebouwd heb, wat het kost, waar het misging, en het ene advies dat ik iedereen zou geven voordat ze hetzelfde proberen.
Waarom Claude’s Geheugenprobleem Eigenlijk Geen Geheugenprobleem Is
Laat me dit eerst anders formuleren voordat we verdergaan, want de manier waarop de meeste mensen praten over “AI-geheugen” is verkeerd — en dat heeft me een heel jaar weerhouden om het juiste te bouwen.
Claude heeft geen geheugenprobleem. Claude heeft een opvraagprobleem.
Het model zelf blinkt uit in redeneren over alles wat zich in het contextvenster bevindt. Opus 4.6 verwerkt nu een miljoen tokens. Sonnet kan moeiteloos 200K aan. Dat is al genoeg context voor de meeste klantprojecten, een paar boeken, of een maand aan e-mailthreads. Het probleem is niet dat Claude geen context kan vasthouden. Het probleem is dat jij, de mens, geen praktische manier hebt om te bepalen welke context je op een willekeurig moment in het venster stopt.
Denk eens aan je eigen workflow. Op dit moment is jouw “tweede brein” verspreid over Gmail, Notion, Google Docs, Slack-threads, een rommelige Downloads-map vol PDF’s, en waarschijnlijk een paar Claude-gesprekken die je liever had opgeslagen. Wanneer je een nieuwe sessie met Claude start en vraagt “help me een follow-up te schrijven naar die investeerder die vorig kwartaal afhaakte,” heeft Claude geen idee over welke investeerder het gaat, welk kwartaal, welke e-mailthread, of wat je in die vorige strategiesessie hebt gezegd.
Je zou alles kunnen plakken. Maar dan ben je weer zelf de bibliothecaris — precies het werk dat je eigenlijk aan de AI wilde overlaten.
Een vectordatabase lost dit op door Claude de bibliotheek te laten raadplegen, in plaats van dat jij met de boeken moet sjouwen. Dat is het hele spel. En toen ik dat eenmaal begreep, werd alles aan de setup eenvoudiger. Voordat je ook maar één regel config schrijft, moet je begrijpen wat semantisch zoeken daadwerkelijk doet — want het verschil tussen een Pinecone-geheugen dat magisch aanvoelt en eentje die als weggegooid geld van $25/maand voelt, komt neer op dit ene concept.
Semantisch zoeken vs. zoeken op trefwoorden: het onderscheid dat alles verandert
Hier is een test die ik vorige maand heb uitgevoerd en die het kwartje deed vallen. Ik nam dezelfde vraag en voerde deze uit in de Gmail-zoekfunctie en in een Pinecone-index met mijn laatste 90 dagen aan e-mails.
De vraag: "Wat zei de oprichter van de fintech-startup over hun churn-probleem?"
Resultaat van Gmail: niets. Geen enkele match. Ik moest handmatig zoeken op "churn", daarna op "retentie", vervolgens op de voornaam van de oprichter, en daarna op de naam van de startup. Vier afzonderlijke zoekopdrachten om één antwoord bij elkaar te puzzelen. Gmail zoekt op letterlijke tekst. Als de oprichter zei "gebruikers blijven vertrekken na maand twee" zonder het woord churn te gebruiken, zal Gmail het nooit vinden. Dat is een zoekmachine op trefwoorden die zich voordoet als een kennisinstrument.
Resultaat van Pinecone: drie e-mails, gerangschikt op relevantie. De beste hit was een thread waarin de oprichter schreef: "retentie is ons #1 probleem op dit moment — we verliezen 40% van de gebruikers tussen week twee en week vier." Het woord churn komt nergens voor in die e-mail. Semantisch zoeken vond het omdat het begreep dat churn, verlies van retentie en gebruikers die vertrekken allemaal in dezelfde betekenisregio liggen.
Dat is het verschil. Zoeken op trefwoorden matcht de letters die je hebt getypt. Semantisch zoeken matcht wat je bedoelde. Wanneer Claude bovenop die tweede optie zit, kun je vragen stellen als "wat waren mijn beste leadgeneratiestrategieën afgelopen kwartaal" of "welke klanten maakten bezwaar tegen mijn prijsstelling" en echte antwoorden krijgen uit je daadwerkelijke geschiedenis — geen verzonnen gok.
De magie die dit mogelijk maakt, zijn embeddings. Een embedding-model leest een stuk tekst en zet het om in een lijst van 1.024 getallen die de betekenis ervan weergeven in een wiskundige ruimte. Twee stukken tekst die ongeveer hetzelfde betekenen, komen dicht bij elkaar te liggen in die ruimte, zelfs als ze geen enkel woord delen. Pinecone slaat die vectoren op en laat je ze doorzoeken met een tweede vector (jouw vraag, ook ge-embed) en geeft de opgeslagen vectoren terug die het dichtst in betekenis liggen.
Klinkt dat abstract? Onthoud dan alleen dit: Pinecone is een database waarbij de zoekindex betekenis is, geen woorden. Alles wat je verder in deze post leest, is de infrastructuur. En juist bij die infrastructuur raken de meeste mensen de weg kwijt, dus ik neem je stap voor stap mee door wat ik precies heb opgezet.
De Volledige Stack Die Ik Gebruik
Voordat ik je stap voor stap laat zien hoe het werkt, volgt hier een overzicht van hoe het systeem er op mijn machine uitziet per april 2026, zodat je weet waar je naartoe werkt:
- Pinecone Starter-abonnement — gratis, 2GB opslag, 5 miljoen embedding tokens per maand op het gehoste multilingual-e5-large model, 2 miljoen write units en 1 miljoen read units per maand. Dat is ruim voldoende voor persoonlijke geheugenopslag op mijn schaal. In drie weken heb ik geen enkele limiet bereikt.
- Pinecone Plugin voor Claude Code — Anthropic en Pinecone hebben samen een officiële plugin uitgebracht die Pinecone-operaties beschikbaar maakt als slash-commando’s en natuurlijke taaltools.
/pinecone:quickstartbegeleidt je letterlijk door je eerste index. Dit bestond nog niet toen ik vorig jaar begon te experimenteren. - Drie aparte indexes: één voor onderzoeksdocumenten, één voor Gmail-archieven, één voor opgeslagen Claude-gesprekken. Ik heb eerst geprobeerd alles in één index te stoppen. Doe dat niet — ik leg hieronder uit waarom.
- Antigravity IDE als visuele laag voor het bulk uploaden van bestanden naar Pinecone. Je kunt hetzelfde direct vanuit Claude Code doen, maar Antigravity is sneller als je in één keer 200 PDF’s sleept.
- Een aangepaste "onthoud dit"-skill in Claude die op commando het huidige gesprek doorstuurt naar Pinecone.
Totale installatietijd op een schone machine: ongeveer 45 minuten als je Claude Code al hebt geïnstalleerd en een Pinecone-account hebt. Totale maandelijkse kosten tot nu toe: $0. Ik verwacht dat dit ongeveer $25/maand wordt zodra ik het indexeren van e-mails opschaal naar meer dan 10.000 berichten, maar op dit moment is het echt gratis.
Laten we het nu bouwen.
Stap 1: Pinecone-account en API-sleutel
Ga naar pinecone.io, meld je aan, kies het Starter-abonnement en maak een API-sleutel aan via het dashboard. Kopieer de sleutel direct — Pinecone toont deze slechts één keer, en als je hem kwijtraakt moet je hem roteren.
Stel deze in als een omgevingsvariabele op je machine voordat je Claude Code start:
export PINECONE_API_KEY="jouw-sleutel-hier"
Op macOS of Linux zet ik dit in ~/.zshrc, zodat het in elke nieuwe terminalsessie beschikbaar is. Op Windows gebruik je Systeemomgevingsvariabelen. De reden dat dit een omgevingsvariabele moet zijn en niet in een configuratiebestand geplakt mag worden: de officiële Pinecone-plugin leest PINECONE_API_KEY uit de omgeving bij het opstarten, en Claude Code zal er later niet meer om vragen. Sla je deze stap over, dan zal elk Pinecone-commando mislukken met een verwarrende authenticatiefout.
Pro tip die mij een uur heeft bespaard: als je Claude Code al open had staan toen je de omgevingsvariabele instelde, moet je het programma volledig afsluiten en opnieuw openen. Claude Code neemt nieuwe omgevingsvariabelen niet over bij een hot reload. Ik heb zeker een half uur verspild door mezelf ervan te overtuigen dat mijn API-sleutel kapot was, voordat ik besefte dat ik gewoon de CLI opnieuw moest starten.
Stap 2: Installeer de Pinecone-plugin voor Claude Code
Installeer binnen Claude Code de officiële plugin:
/plugin install pinecone
Dit onderdeel bestond een jaar geleden nog niet, en het is precies wat deze hele setup mogelijk maakt voor mensen die geen Python-gluecode willen schrijven. De plugin voegt een reeks slash-commando’s toe zoals /pinecone:query, /pinecone:upsert, /pinecone:list-indexes, en het commando dat je als eerste zou moeten uitvoeren: /pinecone:quickstart. Quickstart doorloopt een klein voorbeeld zodat je kunt bevestigen dat je API-sleutel werkt en je omgeving klaar is.
Belangrijker nog: de plugin registreert Pinecone ook als een tool die Claude in natuurlijke taal kan aanroepen. Zodra hij geïnstalleerd is, kan ik gewoon typen "doorzoek mijn research-index op alles over klantacquisitie in B2B SaaS" en Claude voert automatisch de juiste query uit op de achtergrond. Geen commando-syntaxis meer onthouden.
Als je liever een pure MCP-setup gebruikt, of je werkt met Claude for Work waar de plugin nog niet beschikbaar is, kun je handmatig een Pinecone MCP-server configureren. Maar voor de meeste lezers is de plugin de weg van de minste weerstand.
Pinecone-plugin voor Claude Code
https://github.com/pinecone-io/pinecone-claude-code-plugin
Stap 3: Maak je eerste index aan (en waarom ik de mijne verkeerd noemde)
Een "index" in Pinecone is simpelweg een benoemde verzameling vectoren met een vaste dimensionaliteit en afstandsmaat. Je hebt er één nodig per logisch geheugenblok. Ik ga je een fout besparen die ik op dag één maakte:
Noem je index niet naar een project, onderwerp of stad.
De persoon in de video die deze hele setup inspireerde, noemde zijn eerste index "Los Angeles" en dat is een perfect voorbeeld van wat je juist niet moet doen. De naam moet het geheugencategorie beschrijven die het bevat, omdat je deze naam zult intypen in queries en delen over verschillende sessies heen. Ik begon met my-stuff — net zo slecht. Zes dagen later migreerde ik alles naar drie indexes met echte namen:
research-library— PDF’s, artikelen, boekensamenvattingen, transcriptiesgmail-archive— e-mailinhoud met metadataclaude-conversations— opgeslagen AI-chathistorie
In Claude Code is het aanmaken van een index een one-liner zodra de plugin is geïnstalleerd:
Maak een Pinecone-index aan genaamd "research-library" met het
multilingual-e5-large gehoste embeddingmodel, 1024 dimensies, cosine
metric, serverless op AWS us-east-1.
Claude handelt de API-aanroep af en geeft een bevestiging terug. Het multilingual-e5-large model is degene die ik de meeste mensen aanraad, omdat Pinecone het host, je geen aparte embedding API-sleutel hoeft te beheren, en de gratis tier je 5 miljoen embedding tokens per maand geeft op dit model. Dat is ongeveer 3,5 miljoen woorden. Je zult tijdens de setup niet zonder komen te zitten.
Let op: je kunt de dimensionaliteit of het embeddingmodel van een index niet meer wijzigen nadat je deze hebt aangemaakt. Als je een index aanmaakt met het ene model en later probeert vectoren van een ander model toe te voegen, zal Pinecone ze weigeren. Kies je embeddingmodel één keer, commit, en gebruik overal in die index hetzelfde model.
Stap 4: Vectoriseer je eerste batch content
Dit is het punt waar de meeste mensen vastlopen, dus ik neem je mee door mijn daadwerkelijke workflow in plaats van een hypothetisch verhaal.
Dit is wat ik op dag één deed. Ik had ongeveer 40 PDF’s in een map genaamd ~/research — een mix van marketing playbooks, een paar boeken die ik had samengevat, en transcripties van YouTube-video’s die ik had gedownload. Ik opende Antigravity IDE, wees naar die map, en sleepte alles in één keer naar een Claude Code-sessie met deze prompt:
Lees elke PDF in deze map. Hak elk bestand op in secties van ongeveer 500 tokens met 50 tokens overlap. Genereer embeddings met het gehoste multilingual-e5-large model, en upsert elke chunk in de
research-libraryindex. Voeg bij elke vector metadata toe:source_file,chunk_index,titleendate_added. Sla elk bestand over dat al in de index staat op basis vansource_file.
Claude werkte het in ongeveer zes minuten af. 40 bestanden werden zo’n 1.800 vector entries. Het metadata-gedeelte is wat mensen vaak overslaan, en ik smeek je: doe dat niet. Metadata is wat je later in staat stelt om queries te filteren — "doorzoek de research library, maar alleen de chunks uit bestanden die ik in de afgelopen 30 dagen heb toegevoegd" — zonder metadata zit je elke keer vast aan het doorzoeken van de hele index.
Een paar regels die ik op de harde manier heb geleerd over chunking:
- Te klein en je verliest context. Ik probeerde chunks van 200 tokens en de resultaten waren betekenisloze fragmenten. 400 tot 600 tokens is de ideale range voor de meeste teksten.
- Overlap is belangrijk. Een overlap van 10% tussen chunks betekent dat een zin die over een grens heen loopt, toch als geheel kan worden opgehaald. Geen overlap, en je verliest de samenhang.
- Tabellen en codeblokken worden verminkt door naïeve chunkers. Voor documenten met veel tabellen of code, geef Claude expliciet de instructie om codeblokken als één geheel te bewaren en ze niet over meerdere chunks te splitsen.
Als je nu denkt: "dit is precies wat RAG Anything oplost voor gescande PDF’s," dan heb je gelijk — die post behandelt de multimodale versie van hetzelfde probleem. Voor platte tekst volstaat de eenvoudige chunker die Claude inline draait prima.
Je kunt Claude nu natuurlijke vragen stellen over je research library en echte antwoorden krijgen uit je eigen bronmateriaal. Dat alleen al is die 45 minuten waard. Maar hier gaat het systeem van “leuk trucje” naar “verandert echt hoe je werkt” — en dit is precies het deel dat niemand in de YouTube-tutorials duidelijk uitlegt.
Stap 5: Claude zijn eigen gesprekken laten onthouden
Een Pinecone-index van onderzoeksdocumenten is handig. Een Pinecone-index van je eigen gesprekken met Claude is ronduit transformerend. Hier is waarom.
Elke keer dat ik een probleem oplos met Claude — een vreemde Postgres-fout debuggen, een positioneringsoefening doorlopen, een campagnstrategie uitwerken — bevat dat gesprek signalen die ik over 30 dagen opnieuw nodig heb wanneer een vergelijkbaar probleem opduikt. Op dit moment wordt 95% van die signalen weggegooid zodra ik de chat sluit. Ik heb deze oplossing voor hetzelfde probleem waarschijnlijk twaalf keer het afgelopen jaar opnieuw gebouwd, omdat Claude zich niet herinnert wat we vorige maand hebben uitgezocht.
De oplossing is beschamend eenvoudig. Ik heb een aangepaste skill toegevoegd in Claude Code die één ding doet: wanneer ik typ "onthoud dit gesprek als [onderwerp]", neemt het het huidige transcript, splitst het in stukken, embedt het, en upsert het in de claude-conversations-index met metadata zoals de datum, het door mij opgegeven onderwerp en het project waar ik aan werkte.
Vervolgens, aan het begin van elke toekomstige sessie, vertelt mijn standaard systeem prompt aan Claude: "Voordat je een inhoudelijke vraag beantwoordt, controleer de claude-conversations-index op eerdere discussies over gerelateerde onderwerpen. Als er relevante resultaten zijn, lees deze en verwijs naar het eerdere denkwerk."
Hoe dat er in de praktijk uitziet: vorige week vroeg ik Claude om mee te denken over de prijsstelling van een nieuwe dienst. Voordat het antwoordde, raadpleegde het zijn eigen geheugen, vond een gesprek van zes weken eerder waarin we de prijspsychologie voor een andere dienst hadden uitgewerkt, en begon zijn antwoord met "op basis van het prijsmodel dat we op 24 februari voor de auditdienst hebben ontwikkeld, is dit hoe dat van toepassing zou kunnen zijn op deze nieuwe dienst."
Ik heb niets gezegd over 24 februari. Ik heb niets geplakt. Ik herinnerde me het gesprek niet eens tot het naar boven kwam. Dat is wat een echt onbeperkt AI-geheugen Pinecone Claude-systeem mogelijk maakt, en het is de functie waardoor ik ben gestopt met het gebruik van andere oplossingen. Als je dieper wilt ingaan op dit specifieke patroon, heb ik mijn eerdere experiment ermee beschreven in de Claude Code Autodream memory system post — deze Pinecone-aanpak is in wezen de productieklare versie van dat idee.
Stap 6: Gmail vectoriseren (de stap die alles brak)
Alles tot aan deze stap werkte in één keer. Deze stap niet.
De API van Gmail is een vijandige omgeving voor bulkexports. Er zijn agressieve limieten op het aantal verzoeken, geen goede endpoint voor "geef me alles sinds datum X" voor de body-inhoud, en de afhandeling van bijlagen kan je script laten crashen als je niet oppast. Mijn eerste poging — gewoon Claude een script laten schrijven dat de laatste 500 berichten ophaalt en upsert — mislukte drie keer achter elkaar. Het script liep steeds tegen de limiet van 250 verzoeken per gebruiker per seconde aan en leverde slechts gedeeltelijke resultaten op.
Dit is wat uiteindelijk werkte. Ik gebruikte de Gmail MCP-server die al beschikbaar is binnen Claude om e-mails in batches van 50 op te halen, telkens één batch, met een pauze van 5 seconden tussen de batches. Voor elke e-mail haalde ik de volgende gegevens op: onderwerp, afzender, datum, body (platte tekst, geen HTML) en eventuele labels. Ik verwijderde geciteerde reply-threads — als je dat niet doet, wordt dezelfde inhoud vijf keer gevectoriseerd omdat elke reply in dezelfde thread zichzelf citeert. Vervolgens splitste ik de body in stukken van 500 tokens (de meeste e-mails passen in één chunk) en upsertte ze naar de gmail-archive index met rijke metadata.
Het verwerken van 250 e-mails duurde ongeveer vier minuten. Het verwerken van 2.000 e-mails duurde ongeveer 40 minuten. Ik zou niet proberen om 10.000+ e-mails in één keer te verwerken zonder een goede queue en resume-logica — zodra de sessie van Claude halverwege verloopt, raak je je plek kwijt en moet je opnieuw beginnen.
De opbrengst is absurd. Ik kan nu dingen vragen als "vind alle e-mails waarin iemand aangaf te willen samenwerken, maar waar we nooit op hebben gereageerd" en krijg een gerangschikte lijst van echte threads van echte mensen. Geen enkele Gmail-zoekfunctie ter wereld kan dat.
Eén eerlijke beperking voordat iemand te enthousiast wordt: als je e-mails vectoriseert, maak je een doorzoekbare kopie van elke e-mailbody op de infrastructuur van Pinecone. Denk na over wat er in je inbox staat. Klant-NDA’s. Persoonlijke gezondheidsinformatie. Financiële overzichten. Voor mij, op een persoonlijk Pinecone-account met gratis tier, was de afweging prima omdat ik het account beheer en geen gereguleerde data opsla. Voor zakelijk gebruik moet je het compliance-vraagstuk bespreken voordat je dit doet — zeker als je werkt met gezondheids-, juridische of financiële gegevens die onder HIPAA, GDPR of vergelijkbare kaders vallen. Als jouw bedrijf zich in die sectoren begeeft, praat dan met iemand als xCyberSecurity voordat je een productie-mailbox upsert.
Wat Ik Fout Deed Bij De Eerste Poging
Ik wil je de specifieke fouten besparen die ik heb gemaakt, want de meeste hebben me echt tijd gekost.
Fout 1: Eén gigantische index voor alles. Mijn eerste index heette mejba-brain en bevatte PDF’s, e-mails, chats en projectnotities allemaal door elkaar. De zoekresultaten werden steeds slechter naarmate de index groeide, omdat een e-mail van een vriend over dinerplannen moest concurreren met een marketing playbook op semantische relevantie. Splits je indexes per categorie. Dit is geen prestatiekwestie — het gaat om precisie.
Fout 2: Geen metadata. Op dag één voegde ik gewoon ruwe vectoren toe. Geen bronbestand. Geen datum. Geen tags. Na drie dagen had ik 2.400 vectoren en geen enkele manier om ze te filteren. Uiteindelijk heb ik de index gewist en opnieuw opgebouwd met de juiste metadata-schema’s. Doe dit de eerste keer meteen goed.
Fout 3: Vertrouwen op de standaard chunk-grootte. De eerste tool die ik probeerde gebruikte chunks van 1.000 tokens zonder overlap. De opgehaalde resultaten waren technisch gezien accuraat, maar te lang om bruikbaar te zijn — Claude kreeg enorme lappen tekst bij elke query en besteedde het grootste deel van zijn tokenbudget aan ophalen in plaats van redeneren. Chunks van 400-600 tokens met 10% overlap is het bereik dat daadwerkelijk werkt.
Fout 4: Niet opschonen. Na drie weken realiseerde ik me dat sommige van mijn oudste vectoren afkomstig waren uit experimenten die ik allang had opgegeven — half afgemaakte notities, dubbele chunks uit rommelige imports, zelfs wat testdata die ik had toegevoegd tijdens het leren van de API. Ze vervuilden de resultaten. Nu voer ik maandelijks een opschoonactie uit waarbij ik alles opvraag met een date_added ouder dan 60 dagen dat niet is aangeraakt, en het opnieuw valideer of verwijder. Dit kost tien minuten en houdt het systeem eerlijk.
Fout 5: Het behandelen als een back-up. Een vectordatabase is geen back-up. Het is een verlieslatende, doorzoekbare representatie van je data. Verwijder de originelen niet nadat je ze hebt gevectoriseerd. De vectoren kunnen de bron niet reconstrueren. Als je wilt dat het systeem dat ik uiteindelijk heb gebouwd betrouwbaar aanvoelt, bewaar dan de originele bestanden in een simpele map op je schijf en beschouw Pinecone als de zoeklaag erbovenop.
Geen van deze fouten is rampzalig. Elke fout kostte me tussen de 30 minuten en twee uur om uit te zoeken. Nu hoef jij dat niet meer te doen.
Wat er Echt Veranderde na Drie Weken
Ik ben hier voorzichtig, want in de meeste AI-artikelen worden in de sectie “resultaten” de cijfers vaak verzonnen. Ik heb geen voor-en-na dashboards. Wat ik wél heb, zijn drie weken aan daadwerkelijke workflow-verandering, en ik zal je vertellen wat ik daadwerkelijk heb gemerkt.
De grootste verandering is dat ik niet meer begin met het dumpen van context. Voorheen opende ik een nieuw Claude-gesprek en besteedde ik de eerste drie tot vijf minuten aan het plakken van achtergrondinformatie, projectstatus en eerdere beslissingen. Dat is nu verleden tijd. Ik stel nu gewoon mijn vraag, en Claude haalt de context direct uit Pinecone. Mijn gemiddelde “tijd-tot-eerste-bruikbaar-antwoord” op een complexe vraag is gedaald van ongeveer vijf minuten naar minder dan één.
De tweede verandering is moeilijker te kwantificeren, maar belangrijker: ik ben vragen gaan stellen die ik eerder oversloeg. Als het stellen van een vraag betekent dat je vijftien minuten door je e-mail moet spitten om jezelf te herinneren wat er ook alweer was gebeurd, stel je minder vragen. Als de drempel daalt naar “typ de vraag”, stel je er meer. Meer vragen betekent betere beslissingen. Ik kan daar geen getal aan hangen, maar ik merk het elke dag sinds ik dit systeem gebruik.
De derde verandering had ik niet verwacht. Een permanente geheugenlaag veranderde wat ik überhaupt bewaar. Ik maak nu bewust notities die ik anders nooit zou hebben opgeschreven, omdat ik weet dat ze terug te vinden zijn. Snel notities van een sales call. Half uitgewerkte ideeën die ik later wil herzien. Klantcitaten die ik later wil kunnen aanhalen. De geheugenlaag verhoogde de waarde van dingen opschrijven, wat de kwaliteit van mijn aantekeningen verbeterde, wat de geheugenlaag weer betere input gaf. Een vliegwiel.
Als je op zoek bent naar exacte cijfers: branchebenchmarks laten doorgaans zien dat RAG-systemen de zoektijd voor kenniswerk met 60-80% verminderen ten opzichte van handmatig zoeken — dat komt overeen met mijn ervaring, maar ik heb geen formele studie gedaan. Wat ik met zekerheid kan zeggen, is dat ik dit systeem sinds de installatie geen enkele keer heb uitgezet, en elke keer dat Claude iets van twee weken geleden spontaan naar boven haalt, heb ik nog steeds dezelfde reactie als de eerste keer: “wacht, heb je dat echt onthouden?”
Veelgestelde Vragen
Wat kost een opstelling met onbeperkt AI-geheugen via Pinecone nu echt?
Voor persoonlijk gebruik kost het $0/maand op het Starter-abonnement van Pinecone (april 2026). De Starter-laag omvat 2GB opslag, 5 miljoen embedding-tokens per maand op multilingual-e5-large, en voldoende lees-/schrijfunits voor het geheugenwerk van één persoon. Je stapt pas over op het $25/maand Standard-abonnement als je meer dan circa 10.000 documenten verwerkt of een meerjarige e-mailarchief vectoriseert. Zie de sectie "Full Stack" hierboven voor de volledige kostenanalyse.
Is Pinecone beter dan alleen het ingebouwde contextvenster van Claude gebruiken?
Pinecone vervangt het contextvenster van Claude niet — het selecteert wat daarin komt. Het contextvenster van Claude verzorgt het redeneren; Pinecone bepaalt welke delen van je kennisbank op dat moment in het venster geladen worden. Voor workflows die langer duren dan één sessie of meer dan enkele documenten omvatten, heb je beide nodig. Zie de sectie "Waarom Claude’s geheugenprobleem eigenlijk geen geheugenprobleem is" voor het volledige denkmodel.
Kan ik dit gebruiken met Claude for Work in plaats van Claude Code?
Ja, maar de officiële Pinecone-plugin werkt vandaag het makkelijkst binnen Claude Code. Voor Claude for Work kun je Pinecone als MCP-server configureren of de Pinecone-skill gebruiken die dezelfde bewerkingen afhandelt. De kernarchitectuur — indexen, embeddings, semantische queries — is identiek bij beide. Het enige verschil is hoe je het aanroept.
Welk embedding-model kies ik voor een persoonlijk geheugensysteem?
Gebruik multilingual-e5-large, gehost op Pinecone, voor persoonlijk gebruik. Dit is gratis tot 5 miljoen tokens per maand op het Starter-abonnement, ondersteunt meer dan 100 talen en levert 1024-dimensionale vectoren die uitstekend werken voor algemene kennisopslag en -opvraging. Schakel alleen over naar OpenAI’s text-embedding-3-large of Voyage’s voyage-3 als je gespecialiseerd domeinwerk doet waar e5 moeite mee heeft.
Werkt dit met mijn bestaande Obsidian vault of NotebookLM-bibliotheek?
Ja. Obsidian-markdownbestanden laten zich eenvoudig vectoriseren — wijs Claude Code naar je vault-map, chunk en upsert naar een aparte index. NotebookLM integreert via een eigen skill die broninhoud naar Pinecone kan doorsturen. Ik behandel de Obsidian-versie in mijn post Obsidian en Claude Code persistent geheugen, en de NotebookLM-versie in NotebookLM + Claude Code.
Het Ding Dat Ik Wou Dat Iemand Mij Had Verteld
Hier is de herformulering die ik graag een jaar geleden voor me had gehad, want het had me twaalf maanden aan context-overdracht bespaard.
Je AI is niet vergeetachtig. Je leven is ongeorganiseerd. De context ontbreekt niet — hij is verspreid over Gmail, Slack, Notion, een downloadmap en een stapel gesloten Claude-tabbladen. Een vector-database geeft Claude geen geheugen. Het geeft jou een manier om te stoppen met de bibliothecaris te zijn voor een briljante assistent die daar zit te wachten tot jij hem het juiste boek aanreikt.
Op het moment dat je ophoudt dit te zien als "Claude repareren" en het gaat zien als "een tweede brein bouwen waar Claude toevallig uit leest", wordt alles aan de setup makkelijker. Je stopt met proberen alles in één gigantische index te proppen. Je begint dingen goed te benoemen. Je gaat meer notities schrijven omdat je weet dat ze vindbaar zullen zijn. Je gaat betere vragen stellen omdat de kosten van een vraag dalen.
Meld je vanavond nog aan bij Pinecone. Installeer de plugin. Maak één index aan — slechts één — genaamd research-library. Vectoriseer de vijf belangrijkste PDF’s op je computer, die waar je steeds naar terug wilt grijpen. Stel Claude vervolgens één vraag aan die index. Dat is de hele tutorial. De rest van dit artikel is optimalisatie bovenop die eerste vijf minuten.
En de volgende keer dat je Claude-sessie iets belangrijks vergeet, voel je niet langer die zinkende frustratie. Je zegt gewoon "check de research library voor alles wat we hier eerder over hebben gezegd" — en je ziet drie weken van je eigen denkwerk terugkomen, gerangschikt op relevantie, klaar voor gebruik.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io