DEV Community: VANSH ARORA

Enforcing Zero Network Egress with Automated Sovereignty Tests

VANSH ARORA — Tue, 29 Sep 2026 18:48:44 +0000

Many dev tools label themselves local-first while secretly pinging remote endpoints for telemetry, grammar downloads, or license checks.

When building TokenCap, we decided that security guarantees should not depend on developer discipline. They must be enforced by automated tests in CI.

The Four Sovereignty Laws

Every feature added to TokenCap must conform to four rules:

No runtime network calls (except explicit tokencap upgrade).
No API keys required, ever.
Zero native compilation or post-install build scripts.
Total dependency count stays under 4 packages so the entire tree can be audited in an afternoon.

How We Test Sovereignty

In test/sovereignty.test.js, we hook Node.js network primitives and check package manifests:

// test/sovereignty.test.js excerpt
test("enforces zero network egress and dependency budget", () => {
  const pkg = JSON.parse(fs.readFileSync("package.json", "utf8"));
  const depCount = Object.keys(pkg.dependencies || {}).length;

  // Hard constraint: Maximum 4 production dependencies
  assert.ok(depCount <= 4, `Dependencies exceeded limit: got ${depCount}`);

  // Verify tree-sitter grammars are vendored WASM, not remote downloads
  const grammars = fs.readdirSync("dist/grammars");
  assert.ok(grammars.length >= 7, "Grammars must be vendored locally");
});

Because WASM binaries are vendored into the package, npx tokencap make runs cleanly inside air-gapped corporate environments, firewalled CI runners, and defense environments without a single network packet leaving the box.

Inspect our architecture and security docs at tokencap.vansharora.app

How We Built Blast Radius Impact Analysis for AI Agents Using Tree-Sitter

VANSH ARORA — Tue, 29 Sep 2026 09:59:38 +0000

When a human refactors a function, they look at who calls it. When an AI agent refactors a function, it often looks only at the single open file and hallucinates that nobody else depends on the old signature.

To give agents real spatial awareness of code, we built symbol-level impact analysis into TokenCap using tree-sitter WASM grammars.

Methodology: From AST to Call Graph

Parsing: Every JS, TS, Python, Go, Rust, and Java file is parsed into an abstract syntax tree.
Symbol Extraction: Functions, methods, classes, and exported constants are cataloged with line-range coordinates.
Call Resolution: Call expressions are matched against defined symbols using precision-aware resolution (disambiguating direct calls vs method invocations).
Louvain Clustering: The dependency graph is clustered into functional domains to detect boundary crossings.

CLI Inspection in Action

You can query the blast radius directly from the command line:

tokencap ask impact src/auth/jwt.js:verifyToken

Output:

Target: src/auth/jwt.js:verifyToken (function)
Direct Callers (4):
  - src/middleware/authMiddleware.js:14: authenticate
  - src/api/routes/user.js:45: handleProfile
  - src/api/routes/billing.js:28: handleInvoice
  - src/bridge/server.js:89: validateLoopbackSession
Transitive Reach: 18 files across 3 clusters
Boundary Crossings: Auth -> Billing, Auth -> API Gateway
Risk Assessment: HIGH (Core security primitive with multi-module reach)

By exposing this data via the TokenCap MCP server, agents running in Claude Code, Cursor, or VS Code can check the impact of their planned edits before making them.

Explore the architecture at tokencap.vansharora.app

Why Top-Down Truncation Breaks AI Agents (And How Even-Span Fixes It)

VANSH ARORA — Sun, 27 Sep 2026 18:43:48 +0000

Most AI coding context generators have a hidden design flaw: they truncate long files sequentially from line 1 downward until they hit a token budget limit.

If a file has 1,200 lines and your budget allows 400 lines, the model receives lines 1 to 400. Everything from line 401 to 1200 vanishes.

In production codebases, this is fatal:

Top: imports and constants
Middle: core logic and helper functions
Bottom: exported interfaces, route registrations, module.exports, and lifecycle bindings

When the agent cannot see module.exports or class registrations at the bottom, it assumes they do not exist and generates duplicate or broken code.

The Even-Span Sampling Methodology

To solve this without blowing the token budget, TokenCap implements even-span distribution in src/pack/evenSpan.js.

The algorithm divides the file into balanced intervals and samples structural slices while preserving AST function signatures:

// src/pack/evenSpan.js overview
function computeEvenSpans(lineCount, maxLines, anchorPoints) {
  // Guarantees head imports, core anchor blocks, and tail exports
  // are represented proportionally within the allocated budget.
}

Instead of:

Lines 1 - 350: Captured
Lines 351 - 1200: [TRUNCATED]

Even-span provides:

Lines 1 - 80: Header, configuration, types
... [140 lines folded] ...
Lines 220 - 310: Core logic and targeted symbols
... [290 lines folded] ...
Lines 600 - 680: Lifecycle handlers and bottom exports

Every span boundary snaps cleanly to structural declaration boundaries rather than slicing mid-statement.

Run tokencap make to inspect how your large files are budgeted.

How We Achieved a 12.2x Token Reduction on Codebase Context

VANSH ARORA — Sun, 27 Sep 2026 17:54:27 +0000

When feeding codebase context into LLMs, bigger context windows have created sloppy habits. Handing 150k tokens of raw source files to Claude 3.5 Sonnet or GPT-4o degrades recall accuracy and costs serious money when run in automated agent loops.

We built TokenCap to solve this locally. In recent benchmark evaluations against representative multi-file repositories, TokenCap compressed prompt payloads from 152,000 tokens down to 12,450 tokens while maintaining complete call-chain resolution.

Benchmark Methodology

We evaluated TokenCap on standard multi-file refactoring and bug-localization tasks:

Baseline: Full-file concatenation of all modules in the task directory tree.
TokenCap: Running tokencap make --profile balanced with tree-sitter AST extraction and retrieval-gated budgeting.
Metric: Token volume measured via js-tiktoken (cl100k_base tokenizer) and recall accuracy on target symbol call sites.

The result was an average 12.2x reduction in token volume. More importantly, hallucinated import calls dropped because low-relevance code was pruned before context generation.

How the Budget Engine Works

Instead of naive file truncation, TokenCap parses the codebase into an AST graph using WebAssembly tree-sitter grammars. It runs Louvain community clustering to identify functional boundaries and ranks symbols using call frequency and proximity:

tokencap make --profile balanced

CLI output:

Indexed 84 files in 1.1s
Call graph: 412 symbols, 891 call edges resolved (88% precision)
Token budget: 12,450 / 150,000 max (12.2x compression)
Wrote .tokencap/snapshot.md

The resulting snapshot provides the model with full function signatures, exact export shapes, and high-priority implementation spans while folding repetitive structures.

If you are developing LLM workflows or MCP servers, stop feeding raw file dumps to your agents.

TOKENCAP V2.7.0

VANSH ARORA — Sat, 19 Sep 2026 16:46:06 +0000

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.

TokenCap · Codebase Snapshot Tool

Stop wasting tokens. TokenCap snapshots your workspace into structured, AI-ready prompts instantly.

tokencap.vansharora.app

TokenCap v2.1.0 is out.

VANSH ARORA — Mon, 17 Aug 2026 17:30:38 +0000

This release is focused on one idea:

Give AI coding agents better context, while reducing the amount of unnecessary context they need.

When working across Claude Code, Cursor, Windsurf, Copilot, Cline, Antigravity, and other coding agents, a lot of tokens are wasted repeatedly discovering the same repository structure, reading the same files, and rebuilding context.

TokenCap is built to solve that.

What’s new in v2.1.0:

Code Simplification
tokencap analyze simplify

Find unreachable code, duplicate logic, unnecessary abstractions, and reinvention patterns across JS/TS with evidence and confidence levels.

Context Compression
tokencap compress

Compress CLAUDE.md, AGENTS.md, .cursorrules, and similar context files while preserving headings, code fences, links, and URLs.

Token Savings
tokencap stats

Track how much context and tokens you actually save across runs.

Debt Ledger
tokencap debt

Track TODOs, FIXMEs, and deferred shortcuts without relying on expensive git blame operations.

MCP v2

Expose repository overviews, symbol impact, call graphs, and delta diffs directly to MCP-compatible agents and IDEs.

Also crossed 2,500+ installs on the VS Code Marketplace, which is honestly pretty cool to see for an open source project I started building for my own workflow.

The idea behind TokenCap is simple:

Your AI coding agent should not have to rediscover your codebase every time you start a session.

Website:
https://tokencap.vansharora.app

VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=tokencap.tokencap

GitHub:
https://github.com/vansharora21/tokencap-plugin

Install:


bash
npx tokencap make

TokenCap v1.9.0 is now live.

VANSH ARORA — Thu, 06 Aug 2026 17:45:05 +0000

This release is focused on one thing: making TokenCap scale to the kinds of codebases people are actually working with.

When I first built TokenCap, the goal was simple—stop AI coding assistants from wasting tokens rediscovering the same project context on every prompt.

As more people started using it on larger repositories and monorepos, new bottlenecks became obvious. v1.9.0 is all about removing them.

What's new

Built for scale

Bounded parallel graph processing using Node.js worker threads
Checksum-protected atomic sharded cache
~55s cold indexing on a deterministic 100,000-file codebase
~44s warm rebuilds
~57ms scoped incremental updates

Smarter monorepo support

Cross-package dependency mapping
Package-scoped context generation with --package
Automatic discovery of package-local AI onboarding files and rules

Safe Markdown compression

The new tokencap compress command reduces snapshot size by removing markdown noise while keeping every fenced code block byte-for-byte identical.

No broken examples. No mangled code. Just fewer tokens.

Infrastructure-aware context

TokenCap now understands Docker Compose services and local Terraform modules, allowing infrastructure to become part of the project graph your AI can reason about.

Still local-first

No telemetry.

No analytics.

No network calls.

Your code never leaves your machine.

If you're using Cursor, Claude Code, Copilot, Gemini CLI, or any other AI coding workflow, better context usually beats longer prompts.

Install:

```bash id="buwr3q"
npm install -g tokencap




Generate your first context capsule:



```bash id="h1zkxv"
tokencap make --full

Website
https://tokencap.vansharora.app

Documentation
https://tokencap.vansharora.app/docs

GitHub
https://github.com/vansharora7/tokencap

npm
https://www.npmjs.com/package/tokencap

VS Code Marketplace
https://marketplace.visualstudio.com/items?itemName=VanshArora.tokencap

Open VSX
https://open-vsx.org/extension/VanshArora/tokencap

As always, feedback, issues, and feature requests are welcome.

TokenCap #OpenSource #DeveloperTools #TypeScript #AIEngineering #AICoding #Cursor #ClaudeCode #Copilot #MCP #Monorepo

tokencap v 1.7.0

VANSH ARORA — Tue, 28 Jul 2026 07:23:04 +0000

Today every AI sees

Current Repository

But developers think in

Yesterday

↓

Today

↓

Tomorrow

AI has no idea.

v1.7 introduces
Repository Timeline Intelligence

Instead of asking

What does the repository look like?

TokenCap answers

How did it become this way?

Example

You ask

Why is authentication split into three services?

Instead of searching files,

TokenCap answers

Authentication was split

↓

Commit 2af91

↓

Reason:
OAuth support

↓

Affected Files

↓

Current Architecture
AI now understands
Why files changed
Why architecture evolved
Why APIs exist
Why certain decisions were made
Which refactors happened
Which code is legacy
Which code replaced what
Repository Evolution Graph

Instead of

Authentication

↓

Current

Now

Authentication

↓

2024

↓

OAuth

↓

Microservice

↓

Caching

↓

Today
Commit Intelligence

Every commit becomes

Intent

↓

Summary

↓

Impact

↓

Affected Clusters

Instead of

Fix auth

AI knows

Reduced login latency

↓

Moved JWT validation

↓

Updated middleware

↓

No API changes
Decision Graph

Imagine clicking

JWT Middleware

and seeing

Created

↓

Reason

↓

Referenced PR

↓

Related Files

↓

Current Dependencies
Natural Language History

Ask

Why is this service async?

When did Redis become mandatory?

Show me all architecture changes this month.
Repository Memory

Instead of

Repository Snapshot

TokenCap now has

Repository Memory

Snapshots connected through time.

Timeline Intelligence
Repository

↓

Commit Graph

↓

Architecture Evolution

↓

Decision Timeline

↓

AI
Features
Repository Timeline
Commit Intelligence
Decision Graph
Architecture Evolution
Natural Language History
Refactor Timeline
Feature Timeline
Legacy Detection
Change Story
AI Time Travel
Why this matters

Current AI knows

Where code is.

TokenCap v1.7 lets AI know

Why code exists.

That's a much harder problem—and one that can genuinely change how AI helps developers.

Why I like this better than another optimization

Every version so far has made TokenCap better at representing the current state of a repository.

v1.7 could make it represent the history and reasoning behind that state.

TokenCap v1.6.0 is now live

VANSH ARORA — Sun, 26 Jul 2026 16:41:12 +0000

One thing I've realized while building with AI is that context isn't a prompt problem anymore.

It's an engineering problem.

Over the last few weeks I've been using TokenCap on larger projects and found myself repeatedly asking:

Why is the AI reading files that don't matter?
Why am I sending the same context over and over?
Why does every task start from scratch?

So v1.6.0 focuses on making context smaller, smarter, and more reusable.

What's new in v1.6.0

Smarter Context Retrieval
Only fetches the parts of your project that are actually relevant to the current task.

Improved Context Packing
Better prioritization means higher signal and fewer wasted tokens.

Better Dependency Resolution
Related files and components are grouped more intelligently before packing.

Faster Generation
Optimized pipeline for noticeably quicker context creation.

Bug fixes & stability improvements
Because reliable developer tooling matters more than flashy features.

Explore TokenCap

🌐 Website: https://tokencap.vansharora.app

📦 npm: https://www.npmjs.com/package/tokencap

🛒 VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=VanshArora21.tokencap

🔧 Open VSX: https://open-vsx.org/extension/VanshArora21/tokencap

If you're building with AI, give it a try and let me know what you'd like to see in the next release.

Feedback, issues, and contributions are always welcome.

opensource #showdev #vscode #typescript #ai #contextengineering #developers #webdev #programming

TokenCap v1.5 — Making MCP Feel Invisible

VANSH ARORA — Sat, 18 Jul 2026 20:17:23 +0000

Two days ago, I released TokenCap v1.4.0 with support for Local MCP (Model Context Protocol).

The response was great, but while using it myself, I realized something.

The difficult part wasn't MCP.

It was everything around it.

Every AI coding tool has its own configuration format and setup process. Whether you're using Claude Code, Cursor, VS Code, Windsurf, or Codex, the first few minutes usually look the same:

Read the documentation.
Find the configuration file.
Copy some JSON.
Restart the editor.
Hope everything works.

It isn't complicated, but it's unnecessary friction.

The Idea Behind v1.5

Instead of asking developers to configure MCP manually, why not let TokenCap do it?

That's exactly what TokenCap v1.5 introduces.

tokencap mcp --init

One command.

TokenCap detects the AI coding tool you're using and writes the appropriate Local MCP configuration automatically.

Whether you're working in:

Claude Code
Cursor
VS Code
Windsurf
Codex

…the setup process becomes the same.

Run one command and start coding.

Developer Experience First

One principle guided this release:

Developers shouldn't have to visit multiple documentation pages just to connect their AI to their repository.

The best setup process is the one you barely notice.

More Than Just MCP

While automatic MCP configuration is the headline feature, v1.5 also includes several improvements behind the scenes:

Better repository indexing for faster intelligence generation.
A cleaner Repository Intelligence Compiler with less duplicated data.
Improved Local-Only security auditing and secret redaction.
Faster builds and a more maintainable architecture.
General improvements across the CLI.

These aren't flashy features, but they make the everyday experience noticeably better.

Still Local. Still Private.

One thing hasn't changed since the first release.

TokenCap remains local-first.

No cloud.
No API keys.
No telemetry.
Your repository never leaves your machine.

Your repository intelligence stays exactly where it belongs—on your computer.

Looking Ahead

Every release of TokenCap has been moving toward the same goal:

Making AI coding assistants understand repositories without developers constantly thinking about context.

v1.5 is another step in that direction.

Not by adding more features.

But by removing one more thing developers shouldn't have to do.

Links

Website: https://tokencap.vansharora.app

npm: https://www.npmjs.com/package/tokencap

I'd love to hear your thoughts or feedback if you give TokenCap a try.

Looping vs Prompting: Why I Stopped Writing Better Prompts and Started Building Better Context

VANSH ARORA — Mon, 29 Jun 2026 00:29:00 +0000

I used to think the problem was my prompts.

Every time an LLM lost track of what I was building mid-session, I'd rewrite the prompt. Add more detail. Be more specific about the architecture. Paste more code. The model would snap back on track — for a while — and then drift again.

After months of this, I finally diagnosed the real problem: I was prompting when I should have been looping.

The difference nobody talks about

Prompting is a one-shot act. You write a request, get a response, and start fresh next time. The model has no memory of what came before unless you manually re-paste it. Every new conversation is a blank slate.

Looping is a different mental model entirely. Instead of treating each request as isolated, you maintain a persistent, structured snapshot of your project that travels with every context window. The model isn't starting from zero — it's continuing from a known state.

That distinction sounds small. It isn't.

Why prompting alone breaks at scale

Here's a scenario most of you have hit:

You start a session, paste your codebase overview, explain the architecture
The model gives great answers for 20 minutes
Context fills up. You start a new session.
You forget to re-explain something. The model suggests a refactor that conflicts with a decision you made two sessions ago.
You spend 15 minutes debugging something that wasn't broken — you just lost state.

This is context drift. And no prompt, however well-crafted, fully solves it. Because prompting is fighting the symptom. The disease is that there's no single source of truth the model can always reference.

Looping: what it actually means

Looping means your project has a living document — call it a snapshot, a context file, a manifest — that gets updated as the project evolves and is automatically included whenever you start an AI session.

Instead of asking:

"Here's my project, it does X, the architecture is Y, now help me with Z"

You just ask:

"Help me with Z"

Because the model already knows X and Y. They're in the loop.

The loop is closed. Context is continuous. Drift disappears.

This is what I built TokenCap to solve

TokenCap is an open-source CLI + VS Code extension that generates a TOKENCAP.md — a clean, AI-optimized snapshot of your entire codebase.

It's your looping artifact. One file. Every AI tool reads it. You attach it once per session and stop re-explaining your architecture from scratch.

But the original TokenCap was still prompt-adjacent: it gave you better input for your prompt. The snapshot was static. Useful, but not truly looping.

TokenCap v1.3.0 — The Task Intelligence Layer

This is where v1.3.0 changes everything.

v1.3.0 ships the Task Intelligence Layer — the first version of TokenCap that doesn't just snapshot what your code is, but tracks what you're doing with it.

Here's what's new:

🔁 Task-Aware Snapshots

TOKENCAP.md now includes an active task context block — what you're currently building, what decisions have been made, and what's in-progress. When you start a new AI session, the model knows not just your architecture, but your intent.

Active Task Context

Current task: Refactor auth middleware to support OAuth2
Status: In progress
Last decision: Using passport-oauth2, rejected node-oauth2-server (too low-level)
Blockers: None
Next steps: Wire up callback route, write integration test

🔂 Session Continuity Blocks

Between sessions, TokenCap generates a continuity block — a brief structured summary of what happened, what changed, and where you left off. It's appended to your TOKENCAP.md automatically. No manual note-taking.

📋 Decision Logging

Every significant architectural decision you flag during a session gets captured as a structured entry. Future sessions (and future teammates) can see why something was built the way it was, not just how.

🔃 Loop Mode (CLI)

bashtokencap --loop

Loop Mode keeps TOKENCAP.md in sync in the background as you work. File changes, new decisions, task completions — the snapshot stays current without you lifting a finger.

The mental model shift

Here's the clearest way I can put it:

PromptingLoopingYou explain context every sessionContext travels with youModel starts fresh each timeModel continues from known stateDrift is inevitableDrift is structurally preventedBetter prompts = marginal gainsBetter loops = compounding gains

Prompting is a skill. Looping is infrastructure.

You can keep getting better at prompting. Or you can stop losing state between sessions entirely.

Try it

bashnpm install -g tokencap
tokencap

The CLI works with any codebase. The VS Code extension generates and updates your TOKENCAP.md from inside the editor. Both are free and open source.

v1.3.0 is launching soon. If you want to be part of the early access, drop a comment or find me on GitHub.

npm: npmjs.com/package/tokencap

If this resonated — or if you've been fighting context drift in your own workflow — I'd genuinely love to hear how you've been handling it. What's your current strategy between AI sessions?

TokenCap v1.1.0: Teaching AI How to Engineer, Not Just Understand Code

VANSH ARORA — Sun, 28 Jun 2026 19:36:27 +0000

Most AI tooling today focuses on one problem:

How do we give the model better context?

That's an important problem, and it's exactly what TokenCap has been solving through repository intelligence.

But after spending months using AI coding agents every day, I realized something.

Context isn't where most failures happen anymore.

Even after an AI understands the repository, it still:

Expands task scope.
Rewrites unrelated code.
Skips verification.
Loops on the same idea.
Declares success too early.

These aren't intelligence problems.

They're execution problems.

Repository Intelligence vs Execution

Repository Intelligence answers:

What exists inside this project?

Execution answers:

How should work proceed?

Those are two different problems.

TokenCap v1.1.0 introduces the second half.

Execution Contract

Running:

tokencap agent --execution

generates an Execution Contract that accompanies the Self-Loading Universal Context Layer.

Instead of giving AI more information, it gives AI a structured engineering workflow.

It includes:

Execution State
Engineering Principles
Decision Framework
Execution Ladder
Scope Tracking
Verification Rules
Change Classification
Recovery Mode
Scope Drift Detection

This is probably my favorite feature.

AI agents naturally expand work.

A simple login fix slowly becomes:

Authentication → Middleware → Database → Analytics.

The Execution Contract continuously asks:

Are you still solving the user's original problem?

If the scope expands, the AI must explain why before continuing.

Minimal Solution First

One habit good engineers have is avoiding unnecessary code.

Before writing anything new, TokenCap encourages AI to check:

Configuration
Existing utilities
Existing components
Existing services
Installed dependencies
Native platform features
Existing repository patterns

Only after exhausting those options should new code be written.

Confidence Rating

"Fixed."

We've all seen it.

Instead, the Execution Contract encourages AI to produce a verification report that includes build, test, lint status, and an explicit confidence rating before claiming success.

Recovery Mode

Rather than silently retrying forever, the AI documents:

Current hypothesis
Previous attempts
Remaining unknowns
Recommended next step

This makes debugging far more transparent for both developers and the model.

The Goal

I'm not trying to make AI smarter.

I'm trying to make AI behave more like a disciplined software engineer.

Repository Intelligence tells AI what exists.

Execution Contract tells AI how to work.

Together, they form TokenCap's approach to AI-assisted development.

This is just v1.1.0, and there's still plenty more to build. But I think the future of AI coding isn't only about adding more context—it's also about improving the engineering process itself.

Try TokenCap

Website: https://tokencap.vansharora.app
NPM: https://www.npmjs.com/package/tokencap