VibeThrift — Context, Sifted.

Inspiration

I kept running into the same problem with AI coding tools: the task might be small, but the repository context is not.

A request like “fix coupon removal and update the regression test” can cause a coding workflow to pull in thousands of irrelevant files, dependencies, generated artifacts, and old tests. That costs money, but it also makes the important details harder for the model to find.

VibeThrift started with a simple question:

What if an AI coding assistant could inspect a large repository without forcing the final reasoning model to read the entire thing?

The name is intentional. Like a good thrift store, VibeThrift sifts through a large collection, keeps the valuable pieces, and brings forward only what is useful.

What it does

VibeThrift is a VS Code and Cursor developer tool for making AI coding more context-efficient, transparent, and reviewable.

Instead of sending an entire repository to a final coding model for every task, VibeThrift uses Mercury 2 to investigate bounded broad context and identify the files, symbols, tests, and constraints that matter. It then gives GPT‑5.6 a focused evidence brief to produce a structured implementation plan.

Here is the workflow I built:

1. Describe a coding task in the VibeThrift chat.
2. Map repository context and compare a broad-context baseline with the focused workflow.
3. Let Mercury 2 create a compact context memo.
4. Let GPT‑5.6 turn that evidence into an implementation plan.
5. Review native diffs for every proposed file change.
6. Explicitly approve edits and optionally run an allowlisted test.
7. Inspect token estimates, forecast cost, and provider-reported usage for each run.

A developer can continue related work in the same chat or start a new chat when a task needs fresh context.

How I built it

I built VibeThrift with Codex and GPT‑5.6 as core development collaborators.

Codex helped me take the project from idea to working product: planning the architecture, implementing the extension and CLI, generating test repositories, debugging the webview, refining the developer experience, writing documentation, and preparing the demo workflow.

The project has three connected surfaces:

• A VS Code/Cursor extension for the main workflow: chat, context controls, provider-key setup, native diffs, run history, and approval controls.
• A Node.js orchestration layer that maps repository files, estimates context size, filters low-value or sensitive files, invokes providers, and creates focused evidence packets.
• A CLI and dashboard that make the forecasting logic and workflow easy to inspect, test, and demonstrate.

Mercury 2 is the broad-context investigator. GPT‑5.6 is the final reasoning model. I deliberately kept that division of responsibility: Mercury helps narrow the search space, while GPT‑5.6 makes the final implementation plan from focused, source-cited evidence.

In my generated context-maze demo repository, VibeThrift compares:

$$ 98{,}986 \text{ broad-context tokens} $$

with:

$$ 629 \text{ focused GPT-5.6 evidence tokens} $$

That is about a 99% reduction in GPT input context for that example. The forecast includes the Mercury investigation cost rather than showing only the final GPT‑5.6 cost.

Challenges I ran into

The hardest part was making the savings claim honest.

It would have been easy to compare a large GPT‑5.6 context window against a tiny VibeThrift prompt and call it a win. That would not reflect how developers actually work. Repositories contain secrets, generated files, lockfiles, and unrelated modules. Broad context can hit limits. Mercury has a cost. And developers need to know what was left out.

I addressed that by:

• Comparing equivalent broad-context and focused-context paths.
• Including the Mercury investigation cost in the forecast.
• Separating list-price forecasts from provider-reported usage.
• Warning when context is truncated and reporting omitted files.
• Excluding secrets, lockfiles, dependencies, and generated assets from provider context.
• Requiring explicit diff review before applying changes.
• Making Apply use the already-reviewed proposal instead of quietly making another model call.

The other challenge was developer experience. The dashboard is useful for showing the idea, but I did not want developers to leave their editor to benefit from it. That is why I made the VS Code/Cursor extension the main product surface.

Accomplishments I’m proud of

• I built a working VS Code/Cursor extension, CLI, and interactive dashboard—not just a concept demo.
• I created an end-to-end flow from task prompt to repository mapping, focused evidence, GPT‑5.6 planning, native diff review, explicit apply, and test execution.
• I made token and cost trade-offs visible per task instead of hiding them behind a generic “AI optimization” claim.
• I added persistent chats for related work and fresh chats for unrelated tasks.
• I added context limits, truncation warnings, and omitted-file reporting so VibeThrift never implies it saw context it did not receive.
• I kept provider keys in VS Code SecretStorage rather than project files or source control.
• I made review a first-class part of the workflow: the extension requires diff review before applying edits.

What I learned

I learned that efficient AI coding is not only a model-selection problem. It is a context-design problem.

The goal is not simply to use a cheaper model or send fewer tokens. The goal is to send the right evidence to the right model at the right time.

For VibeThrift, that means:

• Use broad investigation to understand the repository.
• Use GPT‑5.6 for high-value reasoning on focused evidence.
• Make cost, context limits, and uncertainty visible.
• Keep the developer in control through review and approval.

What’s next for VibeThrift

Next, I want to add:

• Repository-aware caching for repeated tasks.
• Quality benchmarks across real open-source repositories.
• More model providers and configurable pricing.
• Richer multi-turn context controls.
• Team-level analytics for token spend and savings.
• VS Code and Cursor marketplace distribution.

I also want to add a lightweight feedback and evaluation loop. After each run, developers could rate the context memo and implementation plan, report missing files or constraints, and mark whether the proposed diff was useful.

That would let VibeThrift measure four things over time:

• Efficiency: GPT input-token reduction, total workflow cost, and latency.
• Quality: plan ratings, diff approval rate, and test pass rate.
• Context relevance: relevant files included, missing-context reports, and irrelevant-file rate.
• Developer trust: feedback ratings, acceptance rate, and post-apply edits.

The long-term goal is a transparent per-run Context Score, such as:

92% context relevance · 99% GPT input reduction · tests passed

This would be an evaluation layer, not a claim that VibeThrift automatically retrains Mercury 2 or GPT‑5.6. I want developers to be able to verify that lower-context coding is genuinely useful, not merely cheaper.

Built With

• ai-agents
• automated-testing
• cli
• codex
• context-engineering
• css
• cursor
• developer-tools
• diff-review
• diffusion-based-llms
• gpt-5.6
• html
• javascript
• mercury-2
• node.js
• prompt-engineering
• rest-api
• secretstorage
• token-optimization
• vs-code
• vs-code-extension-api
• webview-api