nicola_alessi

Fair point, appreciate the callout. I'll dial it back.

Interesting framing — hadn't thought about it from the inference routing angle but it maps well to what the data shows. On latency variance: yes, significantly. Cost standard deviation across runs dropped 6-24x depending on task type. The most extreme case was a refactoring task: baseline sigma $0.312 vs $0.013 with pre-indexed context. Duration variance also dropped in 6 out of 7 tasks. I didn't measure TTFT specifically but the overall duration went from 170s → 132s with much tighter clustering around the mean. The stabilization effect is probably the most underrated finding. Everyone focuses on the average cost reduction, but the predictability improvement matters more for production workloads — you can actually forecast spend instead of hoping the agent doesn't go on an exploration tangent. What's SDAG? Curious about your setup.

vexp works regardless of how you organize files. The graph is at the symbol level (functions, classes, types) not the file level, so whether you have one function per file or 50, it resolves the same dependency chain and serves the same capsule.

The savings actually increase with larger files because that's where the baseline wastes the most, Claude reads a 500-line file to use 20 lines of it.

vexp is an MCP server that gives AI coding agents structural awareness of your codebase. Instead of letting the agent read entire files, it pre-computes a dependency graph with tree-sitter and serves only the relevant code nodes — full source for what matters, signatures for everything else.

Benchmarked on FastAPI (800 files, 42 runs, Claude Sonnet 4.6): 58% cheaper, 22% faster, 63% fewer output tokens per task.

Also does cross-session memory — observations are linked to code graph nodes. When the code changes, stale context is auto-flagged.

Single Rust binary + SQLite. Zero cloud, zero telemetry. Works with any MCP agent (Claude Code, Cursor, Copilot, Windsurf, aider, etc).

Free tier, no account needed.

Gating completion on the observation write is smart — you're turning the model's task-completion drive against itself. Have you run into the problem where forced observations degrade to "completed task successfully, no issues noted" though? Technically passes the schema, zero actual information.

That's what killed the approach for me. I spent weeks tuning schemas and rejection criteria and the models just got better at producing plausible-sounding observations that said nothing. Passive extraction ended up more reliable — watch the AST diffs, infer what the agent learned from what it actually changed, skip the self-report entirely.

Curious what your checker validates against. If it's structural completeness of the fields you'll hit the gaming problem fast. If it's semantic quality... how? That's basically asking another model to judge whether an observation is useful, which is its own rabbit hole.

You are 100% correct, and this is the central limitation. An LLM like ChatGPT, trained on general web text, is a terrible movie recommendation engine for exactly the reasons you state. Its knowledge is broad but shallow, skewed toward popular discourse, and it will happily confabulate titles.

Our approach with lumigo.tv is different by necessity, and it's a direct response to the problem you've nailed. We don't use an LLM for knowledge.

Here's the technical split:

The LLM is strictly a query translator. Its only job is to take your messy, natural language prompt ("a gloomy noir set in a rainy city") and convert it into a structured set of searchable tags, genres, and metadata filters. It is forbidden from generating or hallucinating movie titles, actors, or plots. The recommendations come from a structured database. Those translated filters are executed against a traditional database of movies/shows (we've integrated with TMDB and similar sources). The results are ranked by existing metrics like popularity, rating, and release date. The LLM never invents a result; it can only return what exists in the connected data. You're right that pure collaborative filtering (like Netflix's) has a massive data advantage for mainstream tastes. Where it falls short is for edge cases and specific intent. If you want "movies like the third act of Parasite," a collaborative filter has no vector for that. Our hypothesis is that a human can describe that intent, an LLM can map it to tags (e.g., "class tension," "thriller," "dark comedy"), and a database can find matches.

So, it's not AI vs. collaborative filtering. It's AI as a natural-language front-end to a traditional database. The AI handles the "what I want" translation; the database handles the "what exists" retrieval. This avoids the hallucination problem but still allows for queries that a "Because you watched..." algorithm could never process.

Does that distinction make sense? It's an attempt to use each tool for what it's best at.