AI Data Privacy Improves in Claude PDF Workflows
Marktechpost AI Media Inc. released Token Saver on July 30, 2026, an open-source MCP extension for Claude Desktop that uses local hybrid RAG to cut PDF token costs by 92% to 99%. For teams working through legal filings, annual reports, and research PDFs, the bigger story is AI data privacy: the file stays on the machine while Claude sees only the passages needed to answer the question. According to Marktechpost’s release coverage, the tool ships as an MIT-licensed extension and needs no Python environment or terminal setup.
Token Saver lands as a local MCP extension for Claude Desktop
I pay attention when a document tool changes both cost and architecture. Token Saver was developed by Arnav Rai during an internship at Marktechpost AI Media Inc., under the supervision of Jean-marc Mommessin and Asif Razzaq, and targets a familiar pain point: every follow-up question on a long PDF can re-trigger context costs.
The release matters because it does not just compress prompts. It changes the path the data takes. Instead of shipping a full PDF across the provider boundary, Token Saver runs as a local Model Context Protocol server and returns only selected passages. In the source article, the team says token consumption is “slashed by 92% to 99%,” which is a large enough delta to matter in real document-heavy workflows.
Why Claude PDF chats burn tokens on every follow-up
In client environments, I usually see the same misconception: people think uploading a PDF is a one-time event. It often is not. Once a long document becomes part of the conversation state, the model can end up paying for that context again on later turns, especially when users keep asking for clarifications, summaries, or page checks.
That gets expensive fast with PDFs because the payload is not tiny. Marktechpost notes that Claude’s default handling can include page images plus extracted text, and the text alone may run 1,500 to 3,000 tokens per page. Even with features such as prompt caching, the document still crosses into provider infrastructure. For organisations trying to build private AI solutions or evaluate on-premise AI patterns, that distinction matters more than the token bill.
From the Encorp playbook: In document AI, the first architecture question is not model quality. It is where retrieval happens, what crosses the boundary, and how you can prove that later. Teams that decide this early avoid expensive rewrites when security asks for access control, auditability, and support. A useful implementation reference is AI Compliance Monitoring Tools.
How local hybrid RAG keeps the file on your machine
The implementation pattern here is straightforward and solid. Token Saver searches locally, then sends Claude only a narrow answer set. That is the right move when the full corpus is large but the user’s question is small.
According to the source, the retrieval stack blends keyword matching through SQLite FTS5 at 0.4 weight and semantic search using the local all-MiniLM-L6-v2 embedding model at 0.6 weight. This kind of AI integration architecture is practical because exact-term lookup catches citations, statute names, and product codes, while embeddings catch paraphrases.
I also like one detail that often gets skipped in demos: the system applies a gate. If a passage shares no exact keywords, it must clear a semantic similarity threshold of 0.25. That is not a guarantee against errors, but it is a concrete way to reduce low-confidence retrieval before the LLM starts answering. For secure AI deployment, that is a better story than simply saying the model will figure it out.
What the eight-stage pipeline does before Claude answers
Marktechpost’s writeup gives enough detail to audit the flow. Before Claude sees anything, Token Saver extracts text with pypdfium2 with a fallback path, chunks passages into roughly 180 words with 40-word overlap, scores them with hybrid retrieval, gates low-quality matches, deduplicates near-identical passages, trims to only the relevant sentences, caps the payload at 8,000 characters, and wraps the result with page metadata.
That pipeline matters because every stage does a different job:
- extraction reduces manual prep work
- chunking preserves local context without dragging whole pages around
- gating and deduplication reduce repeated noise
- trimming and budgeting put a hard ceiling on outbound context
- page envelopes make verification possible
In practice, the 8,000-character cap is one of the most important controls. I have seen internal document assistants fail not because retrieval was bad, but because nobody put a budget on what could be passed downstream. Once that happens, costs creep up again and answer quality gets less stable.
How big are the savings on real documents?
The benchmark numbers in the source article are directionally strong, even with the stated caveat that tiktoken and cl100k_base were used as a stand-in. On a 33-page FDA drug label, whole-document tokens were listed at 23,959, versus 1,021 returned tokens, for 95.7% savings. On the 88-page GDPR text, the gap was 70,260 versus 996, or 98.6%. On the 233-page SFFA v. Harvard opinion, the article reports 133,349 versus 740, or 99.4%.
The pattern is the real headline: bigger documents save more because retrieval does not grow linearly with total page count. If the answer lives in two paragraphs, the outbound context can stay small whether the source is 30 pages or 300. That is useful for legal services, financial services, and research teams where one source file can drive dozens of follow-up questions.
There is still a trade-off. Local retrieval quality depends on extraction quality, chunking choices, and file naming discipline. If the source PDF is badly scanned or the allowed folder is a mess, users can still get weak results.
What privacy controls make Token Saver enterprise-ready?
This is where the release gets more interesting than a normal token-optimization story. The source describes three practical controls: zero uploads, folder allowlisting, and stdio-only communication with no listening network ports.
For enterprise AI security, those are meaningful choices. Folder allowlisting narrows what the tool can touch. Stdio-only communication shrinks the attack surface compared with services that expose local ports. And keeping the file local answers a basic procurement question faster: where did the document go?
I would still treat this as an implementation component, not a complete control framework. Teams need to test endpoint hardening, extension rollout, update handling, support ownership, and logging policies before broad deployment. That is especially true in regulated functions, where AI implementation services often fail on operations, not demos.
What teams should do before adopting a local MCP extension
If I were piloting this next week, I would start with one narrow document class: court opinions, board packets, policy manuals, or technical standards. Then I would measure four things in week one: returned-token volume, answer verification rate, average time per question, and how often users had to restate the file name or question.
The teams most likely to benefit first are the ones asking repeated questions against long, sensitive PDFs. That includes legal analysts reviewing opinions, finance teams reading annual reports, and research groups working through papers and standards. The news to watch next is whether local MCP extensions like this stay easy to maintain as usage grows, and whether desktop AI clients expose better admin controls around allowed tools, folders, and telemetry.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation