> ## Documentation Index > Fetch the complete documentation index at: https://docs.xynthis.com/llms.txt > Use this file to discover all available pages before exploring further. # Why Xynthis exists > The bet behind Xynthis: intelligence that accumulates on your machine instead of staying frozen in someone else's datacenter. ## The problem Every large language model you use today is frozen. It was trained once, on a snapshot of the world, and its weights have not moved since. It knows the world in general and you not at all. It does not know what you decided last Tuesday, which approach failed twice before, or that "the app" means one specific repository on your disk. The industry's answer is context: paste your life into the prompt, every session, forever. But context is rented memory. It dies when the session ends. And the deeper answer is worse: your usage becomes training signal for someone else's next model, computed on someone else's servers, and you rent the result back by the token. You do the teaching. Someone else keeps the student. ## The bet Xynthis is built on the opposite bet: intelligence should accumulate on your machine. Not your transcripts in a cloud bucket. Your machine, your disk, your model. That bet has two halves. **Memory that compounds.** Everything you tell Xynthis lands in the Binary Memory Core as fixed-width binary records: 64 bytes per fact, carrying a 256-bit signature derived from its embedding. Search is a SIMD Hamming pass over those signatures followed by a precise re-score, in-process, no network. Typical recall completes in under a millisecond. A fact you stored six months ago costs the same to find as one you stored this morning, and it never expires with a session. **Models that evolve.** The same records are training data. A recall reranker, a per-user phrase model, and the on-device language model all train from the memory store, locally. The model is not a frozen artifact you query. It is a student that lives next to its textbook. ## How it gets better day by day This is not roadmap. Every loop below ships today. Five run automatically on the exhaust of normal use; the sixth, on-device fine-tuning, is one toggle away. **The reranker trains on your recall traffic.** Every recalled fact generates a label: used by the conversation scores 1.0, ignored scores 0.0. A background learner wakes every 10 seconds and takes an optimizer step whenever labeled samples exist, and the dream cycle takes another step each pass. The dream gate is 30 minutes of use or one session, whichever fires first, so steps accumulate daily. The reranker's influence is capped at ±0.25 per result: it reorders close calls, it cannot bury a direct match. **Memory consolidates while you work.** Each dream cycle runs a supersession sweep that retires facts newer, contradicting facts have replaced, then consolidates recent working memory into long-term stores. Yesterday's correction quietly outranks last month's mistake. **Successful tool sequences become learned actions.** When the agent completes a task, the exact approach that worked (tool plus argument template) is cached. The next similar request replays the cached action directly, no model call at all. Repetition gets cheaper, then free. **Durable lessons promote to skills.** A lesson the agent has verified as durable can be synthesized into a full skill file under `~/.xynthis/skills/`, complete with activation hints and the recovery steps that made it work. Hard-won knowledge stops being a memory and becomes a capability. **A per-user phrase model accrues training data from every recall.** Each recall appends a training row on disk. A small model trained on those rows learns how you phrase things, and its score blends into ranking, so retrieval converges on your vocabulary, not the average user's. **The on-device model fine-tunes from brain data, behind an eval gate.** Training is off by default and opt-in. When you enable it, a trainer polls its config every 5 seconds, pulls working memory and knowledge-graph facts from the brain, and runs LoRA fine-tuning steps on schedule. Every tick saves a versioned candidate, but the live checkpoint only advances when the candidate beats the previous version on a held-out probe. A worse candidate never ships. Checkpoints survive restarts, so learning is cumulative, not per-boot. Six loops, one property: the system trains itself on the byproduct of you using it. ## Where this goes What follows is direction, not shipped software. It is also the entire point. The destination is your own model: distilled from your own binary memory, self-evolving, small enough to live on the machine. Not another frozen multi-gigabyte checkpoint you download and watch go stale, but a base model plus a few megabytes of adapter deltas that move every day, trained on records of what you actually said, decided, and did. No cloud in the training loop. No one else's servers holding the student you taught. This changes what "making a model" means. Today a model is made once, by a lab, from the internet. On this path a model is made continuously, by your machine, from your memory, in binary, at a fraction of the size. The eval gate that ships today is the safety mechanism that makes continuous self-training sane: every candidate must prove itself before it replaces what came before. The interesting question is no longer how big a model is. It is how fast it learns you. ## Why binary None of this works on prose. A pile of markdown notes is storage; it is not a substrate a training loop can consume without an LLM in the middle to parse it, and an LLM in the middle means cost, latency, and drift. Binary records are different in kind. They are fixed-width and typed: a training loop can iterate them, batch them, and score them directly, the same way it iterates tensors. The 256-bit signature that makes search a few XOR and popcount instructions is the same representation the learners train against. Compact storage is the side effect. The trainable substrate is the design. That is the whole architecture in one sentence: memory and training data are the same bytes. Read how the records work in [Binary Memory Core](/concepts/bmc), and see the loops in detail in [Learning](/concepts/learning).