PDF‑arbejde bliver ofte dyrere og langsommere end planlagt. Derfor er Token Saver interessant: et open‑source værktøj, der kobler sig på Claude Desktop lokalt og, ifølge udgiverne, reducerer tokenforbruget ved PDF‑spørgsmål med 92–99 procent. Tallene skal stå deres prøve i praksis – og det kræver også en driftsplan.
Udgiveren er Marktechpost AI‑teamet. Version 1.0. MIT‑licens. Projektet er bygget som en Model Context Protocol‑server (MCP) til Claude Desktop. Hovedudvikler er Arnav Rai under opsyn af Jean‑marc Mommessin og Asif Razzaq. Kernen er en lokal Hybrid RAG‑pipeline, der henter og klipper de relevante afsnit ud, før noget sendes til modellen. Løftet er, at dokumenter bliver på maskinen.
Hvad Token Saver konkret er
Token Saver kører som en let MCP‑server i baggrunden, som Claude kan kalde som et værktøj. I stedet for at sende en hel PDF ind i chatten stiller man sit spørgsmål, og serveren returnerer smalle, relevante tekstuddrag med kilde og sidetal. RAG‑ideen er velkendt; forskellen er, at hele forløbet sker lokalt.
Marktechpost beskriver opsætningen som “zero‑install” for brugeren – ingen Python‑miljøer eller terminaltrin. Det er en stærk påstand for udrulning uden for udviklerteams. Om det holder bredt, skal testes på tværs af platforme.
Den tekniske kerne
Løsningen er en Hybrid RAG, der kombinerer BM25 via SQLite FTS5 (vægt 0,4) med semantisk søgning via lokale embeddings med all‑MiniLM‑L6‑v2 (vægt 0,6). Målet er at dække både nøgleord og betydning – et fornuftigt trade‑off for PDF’er, hvor terminologi er præcis, men formuleringerne varierer.
Pipeline‑beskrivelsen er detaljeret for et v1.0‑projekt: 1) Extract med pypdfium2 (pypdf fallback). 2) Chunk i bidder omkring 180 ord med 40 ords overlap. 3) Score med hybrid‑modellen. 4) Gate med kvalitetskrav, bl.a. en semantisk tærskel på 0,25 for passager uden nøgleords‑overlap. 5) Deduplicate af næsten identiske bidder. 6) Trim af sætninger, så kun det nødvendige sendes. 7) Budget, der kapper samlet payload til cirka 8.000 tegn. 8) Envelope, som pakker tekst med kilde og side. Fejler embeddings, falder systemet tilbage til rene nøgleord.
De lovede besparelser
Marktechpost rapporterer 92–99 procent lavere tokenforbrug i PDF‑arbejde med Claude. Kilden er deres egen artikel; der findes endnu ikke uafhængige benchmarks. Eksemplerne i deres tekst viser, at hård beskæring af retur‑tekst kan drive store besparelser – især når hele dokumenter ellers ville blive holdt i konteksten ved hvert spørgsmål.
Det er plausibelt, fordi chats ofte gensender konteksten for hver tur. Skifter man til små citater, falder forbruget kraftigt. Men 99 procent er et top‑tal; det bør testes på tværs af dokumenttyper – teksttunge rapporter, scannede pdf’er, tabeller og blandede sprog – før man lægger det i budgetter.
Hvor omkostningen egentlig opstår
Claude håndterer PDF’er ved både at udtrække tekst og generere billeder pr. side for at bevare layout og grafer. Tekstudtrækket alene kan ifølge Marktechpost nå 1.500–3.000 tokens pr. side, før billedtokens tælles. Store dokumenter bliver derfor dyre, hvis de kastes direkte ind i en samtale.
Fordi hele samtalehistorikken typisk sendes igen for hver tur, betaler man gentagne gange for den samme tekst. Tiltag som prompt caching og projekter kan dæmpe det, men ikke eliminere det. Arkitektur slår ad hoc‑chat her.
Hvad “kører lokalt” faktisk betyder
Token Saver er en lokal baggrundsproces. PDF’en bliver på disken. Spørgsmål kører retrieval lokalt og returnerer smalle bidder til Claude. Ressourceforbrug flytter dermed fra tokenbetaling til CPU, RAM og disk‑I\/O. Kilden nævner ikke GPU‑krav – faktisk nævnes ingen hardwarekrav.
Zero‑install lyder godt, men i praksis er der stadig afhængigheder: pypdfium2, SQLite FTS5 og en embeddings‑model. Spørgsmålet er, om alt er pakket, så en ikke‑udvikler undgår friktion. Det kan kun bekræftes ved test på rene maskiner – også på låste enterprise‑pc’er med begrænsede rettigheder.
Sikkerhed og privatliv
Lokalt reducerer dataeksponering: Ingen fil forlader maskinen, hvis opsætningen holder. Det er en fordel for compliance, research, juridiske sager og følsomme kontrakter. Samtidig åbnes en ny angrebsflade: værktøjsadgang via MCP.
Uafhængig dækning af MCP‑integrationer peger på en gennemgående svaghed: autorisation, der ikke genforhandles eller tilbagekaldes korrekt, så agenter kan beholde unødig adgang. Det er et state‑ og governance‑problem, ikke kun kode. Relevante spørgsmål til Token Saver er derfor, hvordan værktøjsadgang styres, logges og kan tilbagekaldes fra klienten.
Drift og vedligehold
Lægger man Token Saver i drift, følger opgaver med: vedligehold og opdatering af embeddings‑modellen, genopbygning af indeks ved dokumentændringer, backup af lokale metadata og cache, samt overvågning af latenstid, fejl og outputkvalitet. Det kræver en plan, selv om det ikke er komplekst.
Mål også “tokens saved” entydigt. Er det en estimat baseret på tekstmængde, eller faktiske kald mod modellen? Uden en standardiseret tæller risikerer man skæve konklusioner. Log input‑ og outputtokens pr. tur – før og efter indførsel – for at komme i gang.
Hvornår giver Token Saver mening
Alternativer findes: klassisk RAG med vektor‑database, progressiv opsummering, session‑cache, on‑prem‑LLM for højfrekvente data og strammere prompt‑styring. Token Saver giver mest mening, hvor Claude Desktop allerede er valgt, og PDF‑spørgsmål er gentagne og dyre.
Som lavrisiko‑proof of concept er casen stærk: hurtig gevinst, hvis zero‑install holder, og retrieval‑kvaliteten er stabil. I større miljøer med eksisterende dataplatforme kan Token Saver blive et sideværktøj – eller en bro til en mere robust, centralt drevet RAG‑tjeneste.
Begrænsninger og åbne spørgsmål
Tre huller springer i øjnene. For det første mangler uafhængige benchmarks, der separat dækker teksttunge, billedtunge, tabeltunge og scannede pdf’er. Ellers kan 92–99 procent skjule store variationer. For det andet er hardware‑ og ydeevnekrav udokumenterede: hvor lang tid tager indeksbygning på 1.000 sider, og hvad bruger det af RAM?
For det tredje er håndtering af billeder, diagrammer og OCR uklar. Marktechpost beskriver, at Claude default bevarer sider som billeder, men det er ikke tydeligt, om Token Saver lokalt kører billed‑til‑tekst, eller om komplekse figurer ignoreres i retrieval. Hvis det sidste, får man lavere omkostning, men risikerer at misse indhold.
Hvad indkøb og økonomi bør gøre
Hvis tallene holder, flytter økonomien sig. Budgetter, der tidligere tog højde for tusindvis af tokens pr. side, kan justeres til et retrieval‑baseret overhead. Det påvirker både prisforhandlinger og kapacitetsplaner. Man kan presse på for lavere priser for store kontekstvinduer, hvis behovet reduceres markant.
Procurement kan kræve reproducerbare benchmarks fra leverandør‑ eller interne tests: tokens pr. side før\/efter, samlet tokenforbrug pr. 10 spørgsmål over samme dokument, gennemsnitlig latenstid pr. forespørgsel, CPU\/RAM‑forbrug ved indeksbygning og søgning – samt bevis for, at PDF’er forbliver lokale i hele kæden.
Praktiske pointer til implementering
Nogle valg giver outsized effekt. Bevar sidetal i metadata og viste citater. Hold chunk‑størrelse stabil og test få varianter – 140, 180, 220 ord – i stedet for at finjustere pr. filtype. Log tydeligt, når systemet falder tilbage til nøgleord, så man ved, hvornår embeddings var frakoblet.
Hav også en plan for konflikter: Hvis to passager scorer næsten ens, så returnér begge med tydelig markering. Brug et enkelt overlap‑filter, så der ikke sendes dobbelt tekst, der spilder budgettet. Det er små ting, men de betyder noget, når en jurist leder efter en præcis sætning midt i en tabel.
Sikkerhedscheck før produktion
Kør et MCP‑security‑review: hvordan tildeles værktøjsadgang, hvordan tilbagekaldes den, og findes der audit‑log for kald? Sæt timeouts på sessions og gør adgang eksplicit og revokerbar – især i miljøer, hvor skrivebordet har adgang til delte drev.
Fastlæg også politik for metadata: gem ikke udtrukket tekst i klartekst i logs uden kryptering. Brug maskinkonti eller lokale certifikater. Test håndtering af password‑beskyttede pdf’er og scannede dokumenter med lav OCR‑kvalitet.
Hvad man kan gøre i næste uge
Planlæg en lille test med tre dokumenttyper: en teksttung rapport, en billedtæt præsentation og en scannet pdf med OCR‑støj. Mål fem ting: 1) tokens pr. side i baseline, 2) tokens pr. svar med Token Saver, 3) latenstid pr. spørgsmål, 4) CPU\/RAM‑peak ved indeksering, 5) svarenes præcision vurderet af en fagperson. Stil ti spørgsmål pr. dokument – ikke kun ét.
Kør et sikkerhedsreview af MCP‑adgang: tildeling, tilbagekaldelse, logging. Notér, hvornår embeddings falder tilbage til nøgleord, og hvordan det påvirker kvalitet. Hvis tallene holder, har man en sag. Hvis ikke, har man stadig lært, hvor regningen opstår, og hvor man kan optimere i pipeline.
Kilder og det der bør undersøges videre
Marktechposts egen gennemgang dokumenterer open‑source‑status, licens, udviklere, pipeline og de rapporterede besparelser. Et særskilt indlæg om MCP‑svagheder peger på autorisations‑ og state‑risici, der er relevante for lokale værktøjer via modeller. Der mangler uafhængige målinger af tokenbesparelse, latenstid og maskinforbrug. Indtil de foreligger, bør Token Saver vurderes med samme skepsis som andre unge open‑source‑projekter med store løfter.
Konklusionen er praktisk: test på egne dokumenter, mål nøgletal nøgternt, og bind det op på en driftbar sikkerhedsmodel. Forskellen ses først, når man kører det selv.
