DEV Community: VANSH ARORA

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

Stop Teaching Every New AI Your Codebase

VANSH ARORA — Fri, 26 Jun 2026 06:27:31 +0000

Every AI coding session starts the same way.

You open a new chat.

Then you spend the next few minutes explaining your project.

Here's the architecture.
These are the important folders.
Authentication works like this.
Don't touch this file.
We use services instead of controllers.
Database access goes through Prisma.
Here's how the payments flow works.

Only after all of that does the actual work begin.

Then you switch to another tool.

Or start another session.

Or come back tomorrow.

And you do it all over again.

The strange part is that nothing about the repository changed.

The knowledge already exists.

It's just trapped inside the developer's head.

We solved package management.

We solved version control.

We solved dependency management.

But we still haven't solved project knowledge.

Every repository already contains enough information to describe itself:

Its architecture
Folder conventions
Dependency graph
High-risk areas
Feature boundaries
Coding rules
Critical files

Yet every new tool has to rediscover that knowledge from scratch.

That's wasted computation.

More importantly, it's wasted developer time.

The repository should carry its own knowledge.

That idea became the foundation for TokenCap.

Instead of generating prompts, TokenCap builds a persistent knowledge layer alongside your repository.

A knowledge layer that explains:

How the project is structured
What matters
What should never change
Where specific features live
Which files belong together

Once that knowledge exists, every new session starts from understanding instead of discovery.

v1.0.0

With v1.0.0, TokenCap generates a self-loading context layer for your repository. It creates an AGENTS.md entry point and supporting project intelligence files so tools can discover the project's structure automatically rather than relying on repeated manual explanations.

The important part isn't the files themselves.

It's the shift in thinking.

Instead of teaching every new tool about your project...

Teach the repository once.

Everything else should learn from it.

Where I think this is going

I don't think the future of software development is writing longer prompts.

I think repositories will become self-describing.

A repository won't just contain source code.

It will also contain its architecture, conventions, boundaries, risks, and accumulated knowledge in a format that any tool can understand.

Code tells us what the software does.

Project intelligence explains how it should evolve.

That's the direction I'm building toward with TokenCap.

TokenCap v1.0.0 is now live.

🌐 https://tokencap.vansharora.app

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

Stop Dumping Your Entire Repository Into AI

VANSH ARORA — Wed, 17 Jun 2026 18:09:44 +0000

One of the strangest workflows in modern software development looks like this:

Ask ChatGPT a question.
Realize it doesn't have enough context.
Copy a few files.
Add architecture notes.
Paste recent changes.
Explain what you're trying to do.
Hope you included the right information.

The problem isn't the AI.

The problem is context retrieval.

After building TokenCap's Knowledge Graph, Debug Handoff, Change Intelligence, and Context Packing systems, I realized something:

We had become very good at generating context.

We were still terrible at finding it.

That's what led to TokenCap v0.7 — Smart Retrieval Engine.

The Question

Instead of asking:

Which files should I send to the AI?

What if you could simply ask:

tokencap ask "How does authentication work?"

and let the tool figure out the rest?

How It Works

The new retrieval engine searches across multiple sources of project intelligence:

Knowledge Graph relationships
Dependency chains
Project Memory
Recent code changes
Risk analysis
Impact scores

It doesn't just find matching files.

It finds the files that matter.

Beyond Keyword Search

A search for:

tokencap ask "debug login redirect"

automatically switches into debug mode.

A search for:

tokencap ask "review payment flow"

switches into review mode.

A search for:

tokencap ask "explain dashboard architecture"

switches into architecture mode.

The retrieval strategy changes based on what you're trying to achieve.

Following the Connections

One thing I wanted to avoid was returning isolated files.

Real systems are connected.

If a file is relevant, its dependencies are often relevant too.

TokenCap traverses the graph to find related files, dependents, and neighboring modules before building the final context package.

Context Isn't Free

Even after finding the right files, another challenge remains:

Token budgets.

The retrieval engine reuses TokenCap's Context Packing system to decide what deserves:

Full source code
Structural outlines
Summaries
References only

This allows larger repositories to fit into practical AI context limits without losing important information.

From Context Generation to Context Retrieval

The evolution of TokenCap has been interesting:

v0.1 — Project Snapshot
v0.2 — Knowledge Graph & Context Memory
v0.3 — Debug Handoff
v0.4 — Change Intelligence
v0.5 — Context Packing
v0.6 — Graph Intelligence
v0.7 — Smart Retrieval

For the first six versions, the focus was:

Generate better context.

With v0.7, the focus becomes:

Retrieve the right context.

That's a subtle difference.

But I think it's the difference between AI tools that know code and AI tools that understand projects.

Try It

Website: tokencap.vansharora.app

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

npm install -g tokencap

Then ask your repository a question:

tokencap ask "How does authentication work?"

Instead of manually assembling context, let the repository tell the AI what matters.

Feedback, ideas, and contributions are always welcome.

Building an Obsidian-Style Code Intelligence Graph for Any JavaScript Project

VANSH ARORA — Wed, 17 Jun 2026 08:40:50 +0000

Most dependency graphs are useless after the first 30 seconds.

They show connections.

But they don't tell you what matters.

While building TokenCap v0.6, I wanted to answer a different question:

If I open a large codebase for the first time, which files should I care about?

That led to a complete redesign of TokenCap's graph engine. Instead of building another dependency visualizer, I started building what I call a Code Intelligence Graph.

The Problem

Traditional project graphs tell you:

File A imports File B
File B imports File C
File C imports File D

After a few hundred files, the graph becomes a spiderweb.

Interesting to look at.

Not useful for decision making.

What developers actually want to know is:

Which files are high impact?
Which files are risky to change?
Which modules are tightly coupled?
Which areas of the codebase belong together?
Which files should AI see first?
The Approach

TokenCap v0.6 analyzes the repository and assigns intelligence to every node.

Each file receives:

A node type
A cluster
An importance score
A risk score
Dependency relationships

The graph currently supports 13 node types:

Routes
APIs
Components
Controllers
Services
Databases
Middleware
Configs
Utilities
Hooks
Packages
Tests
Unknown files

Instead of seeing a wall of files, you immediately understand the structure of the application.

Risk Scoring

One of the most useful additions was risk analysis.

Every file is classified as:

CRITICAL
HIGH
MEDIUM
LOW

For example:

A heavily connected authentication middleware is far more dangerous to modify than an isolated utility function.

That sounds obvious.

But visualizing it changes how you navigate a codebase.

Clustering the Codebase

The graph automatically groups related files into clusters such as:

Authentication
Payments
Dashboard
Database
API
Frontend
Config
Testing

This ended up being one of my favorite features because it makes large repositories feel significantly smaller.

Building the Viewer

The graph viewer uses a three-panel layout:

Filters and graph controls
Interactive graph canvas
Node intelligence panel

You can:

Hover nodes to reveal dependencies
Switch between global and local graph modes
Filter by type or cluster
Inspect impact, risk, and relationships
Explore architecture visually

The goal was to make code navigation feel closer to Obsidian's knowledge graph than a traditional dependency tool.

Lessons Learned

The biggest takeaway from building v0.6 is that developers don't need more information.

They need better prioritization.

A repository might contain thousands of files.

But only a small percentage actually drive architecture, risk, and decision making.

The challenge is identifying those files quickly.

That's the problem I wanted the graph to solve.

What's Next?

The graph is already functional and useful, but it's still the area I'm most interested in improving.

Future iterations will focus on richer relationships, smarter impact analysis, and tighter integration with AI-assisted workflows.

The long-term goal is simple:

Help both developers and AI understand a project faster.

Not by showing more code.

By showing what matters.

npm package - https://www.npmjs.com/package/tokencap
website - tokencap.vansharora.app

Introducing TokenCap — Context Engineering for Modern Codebases

VANSH ARORA — Wed, 10 Jun 2026 08:44:09 +0000

One of the biggest challenges in AI-assisted development isn't choosing the right model.

It's providing the right context.

As codebases grow, important information gets scattered across files, commits, architecture decisions, documentation, and debugging history. Developers spend valuable time manually gathering context before they can effectively use AI tools.

That's why I built TokenCap.

TokenCap helps developers generate structured, AI-ready project context from their codebase, making it easier for AI assistants to understand projects without consuming unnecessary tokens.

Current Features

- Project Knowledge Graph Visualizes relationships between files, components, services, routes, and dependencies.
- Context Memory Captures project decisions, architecture notes, constraints, and development history.
- Change Intelligence (tokencap diff) Transforms raw git diffs into impact analysis, risk assessment testing recommendations, and AI review prompts.
- Context Packing Prioritizes and compresses relevant project information into token-budgeted context packs optimized for AI workflows.

Why TokenCap?
Reduce context-switching overhead
Improve AI response quality
Save tokens and costs
Understand large codebases faster
Generate structured project knowledge automatically

I'm actively working on the next generation of TokenCap, including an Obsidian-style interactive graph and advanced context management capabilities.

Would love feedback from developers building with AI.

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