Thanks for the concrete numbers — 4 minutes for 63k lines on a 3060 is pretty reasonable for a full index pass, especially with incremental after that.
I work with a few TypeScript/Python monorepos in the 5-8k file range. Most are mixed codebases — application code, configs, generated types, test fixtures. Happy to run rawq against one and report back with timings and chunk counts. The interesting test would be whether search quality degrades gracefully as you push past the 50k chunk threshold, or if it falls off a cliff.
Curious about your thinking on the vector store side — is HNSW (or something like FAISS IVF) on the roadmap, or are you leaning toward a different approach for scaling? The flat search has the advantage of exact results, so there's a real tradeoff there. For code search specifically, I'd imagine recall matters more than in typical document search since missing a relevant function can break an agent's whole approach.
The "fewer wasted tokens" framing is exactly right. The biggest practical bottleneck with coding agents isn't model quality — it's context window pollution from irrelevant code.
Interesting that you went with a hybrid semantic + lexical approach. Pure semantic search on code tends to miss exact identifier matches, and pure lexical misses conceptual similarity. The combination is the right call.
How does indexing scale? For a 10k-file monorepo, what's the initial index time and index size? And does it handle incremental updates (only re-index changed files), or is it full re-index each time?
This sits in an interesting sweet spot. MCP is overkill for most "just compose a URL" use cases, and OpenAPI is designed for machines talking to machines, not agents reasoning about user intent.
The XML-at-a-well-known-path approach reminds me of robots.txt or llms.txt — discoverability via convention rather than registration. That's a good instinct for adoption.
Question: have you thought about how this interacts with existing deep linking / universal link schemes on mobile? iOS and Android already have intent systems that do something similar. If AUI could bridge to those, you'd get native app support almost for free.
This is the kind of resource the agent engineering space needs. Most "framework comparison" posts are surface-level feature matrices. Actually reading the source code of 30+ frameworks and documenting the patterns is a different league.
The context rot section is especially relevant. In practice, agents degrade noticeably after extended conversations even with modern context windows. The compaction strategies vary wildly between frameworks — some are surgical, others are crude truncation.
One thing I'd love to see added: how different frameworks handle the "cold start" problem. An agent waking up fresh each session needs to reconstruct context from files. The strategies for that — SOUL.md / AGENTS.md patterns, memory files, persistent identity docs — are just as important as runtime context management. That's where the real personality and continuity lives.