Viktor.comAn AI coworker that actually does the work
Satori
Semantic and Symbol-aware repo context for AI coding agent
10 followers
Semantic and Symbol-aware repo context for AI coding agent
10 followers
Satori helps MCP coding agents move from plain-English intent to precise repo evidence without grep chains or giant file dumps. It indexes code with AST-aware chunks, semantic search, symbol ownership, exact reads, caller/callee context when supported, freshness checks, and recovery guidance, so agents spend fewer tokens getting the right context before edits.
Hi, I’m Hamza, the maker of Satori.
Most AI coding agents can search files.
That is not enough.
Real codebases are not flat text dumps. They have symbols, ownership boundaries, wrappers, callers, callees, stale files, generated output, and implementation details spread across folders.
Without structured repo context, agents fall into grep chains.
They search one file.
Then another.
Then another.
Then they edit from fragments.
I built Satori to give MCP-compatible coding agents a more efficient investigation path through real codebases.
Satori indexes a repo with AST-aware chunks, semantic retrieval, symbol ownership, exact symbol and line-range reads, caller/callee context when supported, freshness checks, and recovery guidance when context is stale or incomplete.
The agent can move from plain-English intent to precise code evidence without dumping huge files into context.
The goal is simple:
Less grep chaining.
Less context waste.
Fewer blind edits.
More visible evidence before the first diff.
Satori does not edit your source code. It gives agents better repo context so developers can steer and approve changes with more confidence.
I’d love feedback from developers using Codex, Claude Code, OpenCode, Cursor-style workflows, or other MCP clients:
Where do your agents usually lose context?
This is currently in pre-alpha stage.
And planned offline support
Curious how this handles monorepos with multiple languages mixed in, does the AST chunking work across boundaries or do I need to set up separate indexes per project. Also wondering if there's a hosted version or if it runs fully on my own infra.
@erdemzdzmxx3
Great question.
For monorepos, you usually index the repo root once—no separate index per language. Mixed-language trees are fine: chunking is per file with the right parser for that file. Semantic search with the default scope=runtime is enough for most discovery (“where is auth handled?”) without any extra filters.
When the agent (or you) already knows the package or language, optional operators like path: / lang: cut noise. Separate indexes only really make sense for hard isolation or different indexing configs, not just because languages are mixed.
Satori itself is self-hosted and free/open: the MCP server runs next to your agent. You bring an embedding provider and a Milvus/Zilliz-compatible vector store. A practical free-tier path today is Voyage + Zilliz Cloud (check their current free limits—e.g. collection caps mean you may need to drop one project to add another). Indexing and semantic query on the Satori side don’t add a SaaS bill; provider/cloud free tiers are what set the ceiling. https://cloud.zilliz.com/, voyageai.com
No hosted Satori SaaS dependency is required. Longer term I want more provider choice, offline-friendly setups, and cloud as opt-in—not a hard requirement.
Finally something that stops my agent from blindly greping the whole repo. The AST-aware chunks actually return the right symbol and its callers in one call, which shaved a ton of tokens off my last refactor.
@devransvi4 That’s exactly the loop I wanted to fix.
Grep is great when you already know the string. It gets expensive when the agent has to discover ownership — the right symbol, then callers — by dumping half the repo into context.
Satori’s path is meant to be: semantic search → exact symbol → nearby call-graph context → bounded read, so the first useful result is something you can open and edit without burning a huge token budget.
Glad it helped on a real refactor — feedback from that kind of use is gold.
The AST-aware chunking actually made a difference on a gnarly refactor I threw at it, way less back-and-forth than my usual grep routine. Really curious how it handles monorepos once the index gets large.
@recep763495
Appreciate it — that’s exactly the kind of test I want it to handle well.
For large monorepos, you usually index the repo root once. Day to day, semantic search with scope=runtime should be enough for discovery. You shouldn’t need a separate index per package or language. Satori chunks per file, and grouped results are meant to point you toward the owning symbol instead of dumping a huge file on you.
When the index gets big, the useful levers are:
use runtime scope so docs and noise don’t dominate
use .satoriignore or index profiles so junk never gets indexed
add path:, lang:, or must: when you already know the package, language, or identifier
use sync for normal changes, and only reindex when fingerprint or sidecar state requires it
Separate indexes mostly make sense for hard isolation or different configs. They usually aren’t needed just because a monorepo is large or mixed-language.
If you hit a concrete pain point, like latency, bad top hits, or index size, send me the repo layout and I can give a more specific recommendation.