tokensave: Saving Tokens When Coding With AI - Tobias Reithmeier

tr">

Zum Inhalt springen

Blog

tokensave: An MCP Server That Saved Me Millions of Tokens While Coding

10 min read · Deutsch

Own schematic illustration - real numbers from my token monitor, project name deliberately omitted

For a few weeks now, a tool has been running in my projects that is invisible in daily use - until you look at the counter. tokensave has saved me over 12 million tokens so far. It's an MCP server that gives Claude Code a local code graph to query, instead of letting the model read whole files and search through the repository as plain text. Here's what it does, how it works under the hood, what a reproducible benchmark says about it - and where its limits are.

A quick detour: why tokens are the currency

Language models don't read and write in characters or words, but in tokens - word fragments of roughly three to four characters. Everything an AI assistant gets to see counts: your question, the system instructions, and above all every file and every search result it loads into its context. As an order of magnitude, a source file with 1,000 lines costs around 10,000 tokens - per request, because the context window is transmitted anew with every API call.

That has two consequences. First, money: billing is per token, usually priced per million. If your assistant reads half a repository for every code question, you pay for it. Second, quality: a model's context window is finite - between 200,000 and one million tokens on current models - and the fuller it is with irrelevant code, the less room remains for what actually matters.

How a model splits text - and why code is expensive

The splitting into tokens is done by a tokenizer, usually based on Byte Pair Encoding (BPE): the algorithm learns from large text corpora which character sequences frequently occur together and merges them into single tokens. Common English words become one token; rare ones fall apart into several. Three things follow from this that are worth knowing when you're trying to save:

First, code tokenizes differently from prose. Indentation, brackets, and special characters are tokens of their own, and an identifier like getUserAccountBalance breaks into several fragments - source code is often more expensive per character than plain text. Second, German is more expensive than English: tokenizers are trained predominantly on English text, so long German compound words split more finely. And third, token counts are not comparable across model generations - a new tokenizer can count the same text roughly a third differently. The rule of thumb "1,000 lines ≈ 10,000 tokens" is therefore exactly that: a rule of thumb.

Less context isn't just cheaper - it makes answers better

One could object: context windows keep growing, so why save at all? Because large contexts have a documented quality problem. In 2023, Liu et al. showed in "Lost in the Middle: How Language Models Use Long Contexts" that language models use information at the beginning and end of a long context far more reliably than information in the middle - retrieval accuracy measurably drops there.

For code questions, that means: if you dump three complete files into the model's context, 95 percent of which are irrelevant, you don't just pay for the irrelevant tokens - you also risk the relevant passage drowning in the middle of the context. Fewer but better-targeted tokens are therefore not just about thrift; they're a quality lever.

What is tokensave?

Anyone who has watched an AI assistant work through a codebase knows the pattern: to answer "where is this function called?", it first reads three files end to end, then greps its way through half the repository. That works - but it burns thousands of tokens every time, most of which contribute nothing to the answer.

tokensave (github.com/aovestdipaperino/tokensave, MIT license, around 450 stars on GitHub) tackles exactly that: instead of searching code as text, it answers questions about the structure of the code - from a local graph that is built once and then queried on demand. According to the project, it supports 34 programming languages, from Rust to Python, TypeScript, and Swift.

How the code graph works

During indexing, tokensave breaks the codebase down into its building blocks: functions, methods, types, and modules become nodes; their relationships - who calls whom, who imports what - become edges. The result is stored as a libSQL database (a SQLite fork) in the project folder. If you look inside, you'll find more than just the core tables nodes, edges, and files: an FTS5 full-text index for symbol search, a vectors table with embeddings for semantic similarity, and fingerprint tables that let the incremental sync detect which files have changed - a sync after small changes takes a measured 21 milliseconds on my machine.

This architecture explains why queries are so cheap: the expensive part - parsing, indexing, embedding...