TOKENCAP V2.7.0

We spent months teaching AI to read our codebases. We forgot to teach it how to remember.

Every developer pair-programming with AI knows this feeling.

You sit down with Claude, Cursor, or Codex and spend three hours untangling a nasty race condition in your auth layer. You try three different ideas that fail, realize why your Redis connection pool is starving, decide on a clean fix, and touch half a dozen files.

The tests pass. You commit the code. You close the chat tab.

And just like that, every piece of hard-won architectural context, every discarded dead end, and every decision you made vanishes.

Tomorrow morning, you open a new session in that same repo. The model greets you with a blank stare. It has no idea what you did yesterday. It does not know why you avoided that third-party library, and it does not know what you plan to tackle next. You are back to square one, watching it grep through your files and burn tokens rediscovering things you solved twelve hours ago.

Over the past year, our entire industry obsessed over getting context into the model. We wrote AGENTS.md files, argued about vector embeddings, and built MCP servers. We taught coding agents how to read our projects.

We completely forgot about the return trip.

Today we are releasing TokenCap 2.7.0, which we call "Loop". It is built around a simple idea: when an AI coding session ends, it should turn into a small, clean, reviewable handoff back to the codebase. No raw transcripts, no telemetry, and no silent changes to your code.

The three-hour epiphany that dies on tab close

When human engineers wrap up a tricky feature, good teams leave behind a quick pull request summary, a commit note, or a short architecture decision record. It takes two minutes, and it keeps the next person who touches that code from losing their mind.

With AI tools, we did something strange. Because chat windows feel temporary, we started treating all that problem-solving like scratch paper.

The data behind this is pretty sobering. Recent telemetry from engineering teams shows that developers using AI assistants are now juggling over 60% more pull request contexts and tasks per day than they were a year ago. Work restarts are up, and tasks sit half-finished for days simply because keeping track of scattered chat sessions is mentally exhausting.

The problem is not that the models are not capable enough. The problem is that the feedback loop between the conversation and the repository is broken.

Right now, teams usually pick one of two extremes. Either you hoard raw transcripts, saving tens of thousands of tokens of chat banter and hallucinations into documents nobody will ever read again, or you accept total amnesia and pay the inference bill to rediscover the codebase on every prompt.

Neither of those makes sense on an engineering team.

Why we refused to let AI write directly to your git history

When we started building the capture side for 2.7.0, the first suggestion people gave us was obvious: just have the AI update the memory files automatically in the background when the chat finishes.

We decided early on that we would not do that.

Models hallucinate. They claim tests passed when they did not run them. They invent dependencies out of thin air. If an agent can silently edit your repository memory or project rules without you looking, you have not built a useful loop. You have just built a machine that slowly poisons your context over time.

In TokenCap 2.7.0, captures are staged first:

When a session wraps up, you or the host submit a bounded summary (tokencap remember or via the local bridge).
It gets validated, stripped of secrets or API keys, and clamped to under 60 lines.
It lands in a local folder (.tokencap/memory/inbound/).
Nothing touches your actual repository memory until a human runs tokencap remember --approve.

If an agent generated garbage, you reject it. If it captured the right architectural decision, you approve it, and it immediately archives into .tokencap/memory/sessions/.

From there, running tokencap handoff prints a clean, 500-token summary of the latest approved work. When you start your next chat session, that handoff sits right at the top of your prompt. The agent knows exactly where you left off.

Grounding, not "truth"

One thing we had to be very careful with was the quality gate. How do you check if a session summary is actually good before you approve it?

A lot of modern tools spin up a second LLM to critique the first LLM. That adds delay, burns money, and sends your code off to another server.

Instead, TokenCap checks grounding against the AST knowledge graph you already have locally:

Did the summary reference files that actually exist in your git tree?
When it claims it modified a function, does that symbol actually exist in the AST?
Did it write something specific and technical, or did it write vague fluff like "refactored code and improved stability"?

We are not trying to evaluate whether the AI is philosophically correct. We are checking whether what it wrote is anchored to the actual structure of your repository.

Context goes stale faster than code

There is another side to this. If you give an AI assistant an intelligence snapshot that is two weeks old while your working directory has fifteen uncommitted file edits, the model gets confused, hallucinates, and gives you broken suggestions. Then everyone blames the model.

In 2.7.0, we added a build health score (tokencap health).

It gives you a plain 0 to 100 rating on your current context:

Build health: 94/100 · built 1.2h ago
  100  freshness: built 1h ago
   90  sourceDrift: 1 uncommitted change since build
   95  detection: Node.js, TypeScript detected
   90  coverage: 3/3 layers present

If the score slips because the codebase moved out from under it, it tells you why, tells you what changed, and prints the exact command to freshen it up (tokencap rebuild). That same score is piped directly into the MCP overview tool so your agent can see whether its own context is fresh before it starts writing code.

Being honest about host support

Almost every dev tool landing page right now has twenty AI logos with a badge claiming full automatic support.

We ran tokencap remember --hosts to check what tools actually support automatic session capture today. The reality is simple: almost no tool gives you a reliable, verified hook when a chat conversation ends. An editor closing or an MCP process shutting down is not a session-end signal; nine times out of ten it is just somebody reloading a window or toggling a setting. If a tool treats every window restart as a completed session, it floods your repository with junk.

So we designed 2.7.0 to be honest about it. We support seven hosts, but we treat manual and staged review as the primary path. When a host actually builds a real conversation lifecycle event, we hook into it. Until then, we do not guess.

Staying local

The easiest way to build something like this would have been to put an API key in a settings panel, ship your chat logs to our cloud database, and charge a monthly subscription per seat.

We built TokenCap under strict constraints from day one:

Zero network egress. Everything runs on your machine. No bytes leave 127.0.0.1.
Strictly four runtime dependencies. No native compilers, just pure WebAssembly.
Token budgets that respect model limits instead of blowing past them.
Everything lives inside your repo under .tokencap/.

Trying it out

If you are already using TokenCap, you can pull the update today:

npm install -g tokencap

Run tokencap health to see where your repository context stands, try capturing a session with tokencap remember, and see what it feels like to start a chat where your tools actually remember what you built yesterday.