Vinv ties live runtime traces to the exact source symbols that produced them, feeds this precise evidence to your coding agent, and independently verifies whether its generated fix actually holds.
The context itself is dynamically learned. Vinv uses Thompson sampling to determine the optimal amount of code and runtime evidence to provide to the agent, actively measuring when additional runtime context helps versus when it hurts.
Demonstration Results :-
Tested on FastAPI's full-stack-fastapi-template (one trial per condition, a demonstration rather than a benchmark):
Beyond bug fixing, Vinv found and proved a performance fix in Hugging Face's smolagents:
Reduced transient allocations from 36.27 KB to 0 KB per 4 KB log line.
Verified byte-identical output across 2,015 distinct inputs.
Key Capabilities
Advanced Code Intelligence: Detects dead code and performance bottlenecks.
Universal Integration: Works inside your IDE or with any coding agent/application via MCP.
Open Source: Apache 2.0.
Nothing ever leaves your laptop. All code processing and local indexing happen completely offline. It downloads a one-time 500 MB local embedding model on first setup.
The flame graphs are generated from the runtime traces Vinv collects.
After you run your service with Vinv, open the Vinv panel in the editor. The runtime traces collected from your services are shown there, including the flame graphs for the observed execution paths.
It is for the local embedding model Vinv uses to index and retrieve relevant code and runtime context.
We keep that model local so code and runtime data do not need to be sent to a remote embedding service. The 500 MB download is only required once during setup, and after that the model runs locally.
We are looking at smaller embedding models as well, but the current one gives us better retrieval quality for code and runtime context.
Try It Out :-
* GitHub: https://github.com/VinvAI/VinvAI
* VS Code & Cursor Extension: https://open-vsx.org/extension/VinvAI/VinvAI (3.5k+ downloads)
* Demo Video: https://www.youtube.com/watch?v=EkUjPWKHAvI
Vinv ties live runtime traces to the exact source symbols that produced them, feeds this precise evidence to your coding agent, and independently verifies whether its generated fix actually holds.
The context itself is dynamically learned. Vinv uses Thompson sampling to determine the optimal amount of code and runtime evidence to provide to the agent, actively measuring when additional runtime context helps versus when it hurts.
Demonstration Results :-
Tested on FastAPI's full-stack-fastapi-template (one trial per condition, a demonstration rather than a benchmark):
* Grok 4.5 + Vinv context: 4 bugs + 1 optimization
* Grok 4.5 (no context): Nothing
* Fable 5 (no context): 1 bug
Real-World Impact :-
Beyond bug fixing, Vinv found and proved a performance fix in Hugging Face's smolagents:
Reduced transient allocations from 36.27 KB to 0 KB per 4 KB log line.
Verified byte-identical output across 2,015 distinct inputs.
Key Capabilities
Advanced Code Intelligence: Detects dead code and performance bottlenecks.
Universal Integration: Works inside your IDE or with any coding agent/application via MCP.
Open Source: Apache 2.0.
Nothing ever leaves your laptop. All code processing and local indexing happen completely offline. It downloads a one-time 500 MB local embedding model on first setup.
I saw in the demo video flame graphs of all services , how can I access them and where will they come ?
The flame graphs are generated from the runtime traces Vinv collects.
After you run your service with Vinv, open the Vinv panel in the editor. The runtime traces collected from your services are shown there, including the flame graphs for the observed execution paths.
Why is it asking me to download a 500MB model ?
It is for the local embedding model Vinv uses to index and retrieve relevant code and runtime context.
We keep that model local so code and runtime data do not need to be sent to a remote embedding service. The 500 MB download is only required once during setup, and after that the model runs locally.
We are looking at smaller embedding models as well, but the current one gives us better retrieval quality for code and runtime context.
I saw in the demo video flame graphs of all services , how can I access them and where will they come ?