Skip to main content
Two commands teach Xynthis a codebase, and they answer different questions. xynthis corpus add indexes file content: chunks of code and prose that recall can retrieve by meaning. xynthis code scan extracts structure: a typed knowledge graph of functions, classes, imports, and call edges. Use both on a repo you work in daily.

​
Indexing content: corpus add

xynthis corpus add ~/project --name project --mask "**/*.rs"
This creates a named collection (defaulting to the folder’s basename), walks the tree, chunks each file, and ingests the chunks into the Binary Memory Core. Code files are chunked along AST boundaries so a function stays one chunk; prose falls back to heading-aware splitting. Force one strategy with --ast or --regex. Ingestion streams: files are read and chunked in windows of 64 paths at a time, ingested in batches of 128, so peak memory stays proportional to the window rather than the corpus. Chunks are deduplicated by BLAKE3 hash, which is what makes re-indexing cheap: unchanged content is skipped, not re-embedded. The caps, and what falls outside them:
LimitValue
Max size per file2 MiB (larger files are skipped; they are logs, datasets, or binaries)
Max files per ingest run20,000
Always excluded.git, target, node_modules, dist, build, venv, .venv, __pycache__, .xynthis
By default the folder is watched after indexing, so edits re-ingest automatically. Pass --no-watch to skip that, or toggle later with xynthis corpus watch <name> on|off. Give each collection a one-line description of what it is; recall uses it to route queries to the right corpus: 
xynthis corpus context set project "Rust monorepo for the Acme billing service"
xynthis corpus context check     # lists collections still missing a description

​
Managing collections

xynthis corpus list              # ID, NAME, DOCS, CHUNKS, WATCH, CONTEXT
xynthis corpus status project    # size, last update, context-present flag
xynthis corpus update project    # re-index one collection (omit the name for all)
xynthis corpus remove project    # drops the index; never touches your source files

​
Scanning structure: code scan

xynthis code scan ~/project

scanned 'project' at /Users/you/project
  files=482 funcs=2114 classes=390 imports=1268
  triples added=8730, replaced=0, elapsed=2140ms
The scanner AST-parses every supported file (Rust, TypeScript, Python, Go, and Swift) and writes typed triples into the brain’s knowledge graph: code:contains_fn, code:contains_class, code:imports, code:imported_by, code:defined_in, and code:calls (call sites resolved cross-file through a symbol table). Re-scans are incremental: each file’s extraction is cached keyed by a BLAKE3 content hash, so an unchanged file is replayed from cache instead of re-parsed. After a big refactor, pass --replace to wipe the previous scan’s triples before ingesting, which also drops that repo’s cache entries. Defaults are 10,000 files and 50,000 triples per scan; raise them with --max-files and --max-triples (the summary warns when the triple cap was hit). --label overrides the repo name baked into entity ids, which otherwise defaults to the path basename.

​
What recall can answer afterward

Recall is layered: it consults the knowledge graph and the corpus chunks in the same query, so both kinds of code knowledge surface together. 
xynthis recall "where is license validation implemented"
With the corpus indexed, questions about content work: “where is the retry backoff configured”, “show me the chunk that handles webhook signatures”. With the scan ingested, structural questions work: what functions a file contains, what a module imports, what calls a given function. Graph entities follow the pattern code:<label>::<relative-path>, and the kg_query MCP tool queries them directly if you are wiring your own client. In chat, you just ask; the agent routes to recall and the graph itself.