I got tired of re-explaining my projects to Claude — so I built context-window

Every time I opened up a new Claude conversation, I find myself re-telling it the same things. Who I am. What stack this project uses and more importantly, for business context, I find myself resharing the same business rules. The two odd conventions we picked up six months ago. That one third-party API quirk that bit us last quarter.

It's not Claude's fault. It can't remember things across sessions — that's how the model works. But it means I'm doing the same warm-up exercise every single time. Multiply that by however many projects I touch in a week and it adds up to hours of wasted effort.

So I built a small tool to fix it for myself, and I've open-sourced it:

The dashboard is server-rendered HTML with SVG charts. No client-side framework, no build step beyond tsc. There's a sparkline for activity over time, four bar charts (top tools, top contexts, top projects, top clients), and a row of summary stat cards. It runs at http://127.0.0.1:5173/dashboard after context web.

A few interesting design choices

The manifest is derived state. If you update a context that's attached to three projects, all three manifests rewrite themselves automatically. Same for archive, delete, attach, detach, reorder. There's exactly one source of truth — the SQLite DB — and the on-disk manifest is always a fresh projection of it. No staleness, no sync command needed.

Inactive contexts are hidden, not surgically removed. Archive a context and it stays attached to whatever projects already had it, but it's filtered out of get_project_summary, get_context_budget, and search_contexts. So an LLM never sees stale knowledge as "available", but the link is preserved if you decide to unarchive later.

Token counts are pre-computed on write. Every time a context is created or updated, we tokenise it with gpt-tokenizer and store the count. That means get_context_budget can do its work entirely as a SQL query — no expensive tokenisation per request.

Storage is transport-agnostic. The whole codebase is split into core/ (business logic), storage/ (the Repository interface + a SQLite implementation), and three transports (mcp/, cli/, web/). If someone wanted to add a Postgres backend or an HTTP MCP transport for a cloud mode, they'd swap the storage + add a transport. The core services don't move.

Try it

git clone https://github.com/prodevuk/context-window.git

cd context-window

npm install

npm run build

npm install -g .

context project init       # in your project

context web                # http://127.0.0.1:5173

claude mcp add context-window --scope user context-mcp

That's the whole getting-started. It's TypeScript, Node ≥ 20, SQLite. No accounts, no API keys, no telemetry, no network calls (unless you point an MCP client at it).

The repo has a 10-test unit suite plus end-to-end smoke tests against both the stdio MCP server and the web UI.

Where to take it from here

A few things on my list:

• Better budget heuristics. Right now get_context_budget is a strict priority-then-position fit. It could be a lot smarter — maybe weight by recent usage from the analytics it already collects.


• A proper "what should I capture next?" prompt for the LLM, surfaced as an MCP tool.


• Per-project token windows that match the actual model's window, not a fixed default.


• Encrypted-at-rest contexts for the ones marked visibility: private.

If you've ever felt the same pain — "I'm pasting the same paragraph again, aren't I?" — I'd love to hear what you'd want from a tool like this.

The repo is at github.com/prodevuk/context-window. Issues, ideas, and PRs are all very welcome. MIT licence.

Thanks for reading.