Interlinked.

The vault series · 3 of 5

The machine gets biographies.

You have a dozen repositories on this machine. Ask any tool what they are and you get the same answer: a list of folder names and timestamps. Not what each one is about. Not which are alive and which you abandoned in March. Not where they ship. That identity isn't missing; it's written in plain sight inside each repo's own history. Nothing reads it for you, across the whole machine, until you ask the right layer. Day one, Interlinked answers with twelve biographies, in 1.7 seconds.

12 / 12
repos read into biographies, not a directory listing
1.7s
to seed every repo on the machine at install
0
language models: every fact is read from git

TL;DR · Key takeaways

  • Every repository already broadcasts its own identity (what it's about, active or dormant, where it pushes, who owns it), recorded as plain fact inside its own git history.

  • git log and GitHub Insights read that one repo at a time and only see what's committed or pushed. Interlinked reads every repo on the machine at once, on day one, and hands your agent an identity card for each.

  • Zero language models. Every field is derived from git history, not guessed: nothing to hallucinate, nothing to double-check.

  • The biography compounds: a save is folded into the graph in ~1 ms, so the machine knows itself a little better every week, automatically and offline, across a 4.47M-file disk.

  • Everything local free forever. Hosting starts at $5.99/mo.

What a repo already tells you about itself

Every repo broadcasts who it is. You just have to dig for it.

Think about what you actually want to know about a repository. Four facts cover it: what it's about (the words that keep recurring across its code and its commit messages), whether it's active or dormant (how recently anyone touched it), where it pushes (its remote), and who owns it (the commit author). None of this needs a model to infer: it's sitting in the repo as recorded fact. The only reason you don't have it at a glance is that reading it means archaeology, one repo at a time.

ifile-mcpACTIVEABOUT← recurring words in code + commitssearchindexquerymcpPUSHES TOgit.local:3000/ifileOWNERvlad · 214 commitsPULSE2 days agoui-spike-2024DORMANTABOUTdemopocdraftPUSHES TOnever pushedOWNERvlad · 11 commitsPULSEidle 8 months

An identity card: derived, not guessed. The active repo shows a rising pulse and a live remote; the dormant one has been idle for months and never left the disk. Every field is read from the repo's own history: keywords from its vocabulary, status from its last commit, the remote from its config, the owner from its authorship. No language model is anywhere near it.

How you'd reconstruct this today

git log archaeology, and the Insights tab.

There are two honest ways to answer "what is this repo" today. Both are good. Both stop at exactly the same wall.

ANCHOR 01: GIT LOG
Archaeology, by hand

git log, git shortlog -sn, and a careful read of the commit messages to reconstruct what a repo was for and whether anyone still touches it. It works: it's ground truth. But it's one repo at a time, you have to already know the repo is there, and it only ever sees what's inside git.

THE CEILING
One repo at a time · only what's committed
ANCHOR 02: GITHUB INSIGHTS
The dashboard view

The contributors graph, the language bar, the commit-activity chart, the dependency graph: genuinely good, visual answers to the same question. But it's one repo per page, it only knows what you've pushed, and it needs a browser, an account, and a network.

THE CEILING
One repo per page · only what you pushed

Neither is wrong. They're the right tools for a human reading about one project. But a working machine isn't one project: it's a shelf of a dozen, plus the unpushed spike, plus the 90% of the disk that was never in git at all. Run the archaeology across all of them and it's an afternoon. Open the Insights tab a dozen times and you still can't see the repo you never pushed.

The same question, answered across the whole machine

One question. Twelve biographies. Day one.

The first time Interlinked runs, it reads the deepest history already on the disk (your git commits) for every repo at once, and hands back an identity card for each. No browser, no push, no account, no model. On a real machine that was 8,455 git events across 12 repos, replayed in 1.7 seconds, seeding 26,958 relationships before a single search was run. And unlike a git log you re-run or an Insights tab you refresh, it doesn't stop at day one: the biography keeps getting sharper on its own.

KNOWLEDGE IN THE VAULT →the vault: keeps compoundinggit log · GitHub Insights: one snapshotre-run it and you land right back here+ files you save together+ docs opened together+ shared symbols & config→ and it keeps climbingDAY ONE · GIT SEED8,455 git events → 26,958 pairsevery repo on the machine · 1.7 sDAY ONEWEEK 1WEEK 2WEEK 3WEEK 4

Day one is a snapshot of your git history: the same ground truth git log reads, for every repo at once. Every week after, the vault folds in what git never saw: the files you actually save together, the documents you open in one sitting, the rare symbols two repos share. The anchors are a flat line you re-run for the same answer. The vault is the line that keeps climbing.

Methodology: measured on a fresh install (Ryzen 9 9950X3D, 64 GB DDR5, NVMe, Windows 11, 4.47M files); 12 repositories on disk; the seed timed from the service log. Weekly increments are qualitative: the kinds of relationships added, not a projected count.

Why this can only happen locally

GitHub sees one repo. Your machine holds the whole shelf.

A single-repo tool (the Insights tab, an in-repo index, a cloud code graph) is structurally blind to the thing that matters most on a working machine: how the repos relate to each other. It can't see that a folder is a collection of separate repos that ship together, not a monorepo. It can't see the unpushed prototype that shares hundreds of identical files with your main app. It can't see the 90% of the disk that was never in git. A local index reads every repo on the disk at once, and because the biography is keyed to the file's own OS identity, it survives when you rename or move the folder.

And the biographies sharpen without you. As you work, the vault records what actually happens (a save folded in about a millisecond later) and each week the machine knows itself a little better. Nothing to configure, nothing to feed it, and none of it ever leaves the machine.

Day one is the worst it will ever be

A snapshot you re-run. Or a memory that grows.

git log and GitHub Insights are snapshots: accurate the second you run them, stale the second you stop. The vault is the other shape. It starts from the same git history everyone can read, then keeps going, quietly, from your behavior. The longer Interlinked lives on the machine, the better it knows it: automatically, offline, and owned by no vendor.

1.7 s
every repo on the machine biographied at install, from its own git history
~1 ms
a save folded into the graph, about a millisecond after you hit save
0 LLMs
every biography is read from history, never a model's guess you can't check

THE VAULT COMPOUNDS. GIT LOG DOES NOT.

Common questions

The questions people ask.

Does this use an LLM to describe my repositories?

No. Every field on a repo's identity card (what it's about, active or dormant, where it pushes, who owns it) is read directly from its git history. There are zero language models anywhere near it, so there's nothing to hallucinate and nothing to verify.

How is it different from git log or the GitHub Insights tab?

Both are excellent, but they answer one repo at a time and only see what's committed or pushed. Interlinked reads every repo on the machine at once on day one (including the unpushed prototype and the large share of the disk that was never in git) and keeps every biography current as you work.

Does it stay accurate after day one?

Yes, and it sharpens. A save is folded into the graph in about ~1 ms, so the biographies compound from what you actually do (files saved together, documents opened side by side) with nothing to configure and nothing to feed it.

Does any of this leave my machine?

Not unless you publish a project yourself. The index and the relationship graph live entirely on the local disk, and search needs no account and no network. It was measured on a Ryzen 9 9950X3D across 4.47M files, fully offline.

What does it cost?

Everything (the desktop app plus the MCP layer that hands these biographies to Claude Code, Cursor, Codex and the rest) is free forever, no card. Hosting starts at $5.99/mo.

See your own machine's biographies

Install once. Ask "what am I working on?"

1

Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Codex, Cline and the rest. No JSON to edit, no keys to paste.

2

Let it read your history. Day one it replays every repo's git commits and hands your agent an identity card each: what it's about, active or dormant, where it pushes, who owns it.

3

Then just keep working. Every week the biographies sharpen from what you actually do (files saved together, documents opened side by side), automatically, and none of it leaves the machine.

Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows · Previously: files that find each other

Measured July 2026 · fresh install · 12 repos · Ryzen 9 9950X3D · Windows 11← All research