GottZ/ctx
Live in production> Knowledge store with weighted 4-way RRF retrieval, multi-tenant scope isolation, multi-dimensional cyclic temporal gravity, and autonomous cross-referencing.
The memory your LLM pretends to have.
No GitHub topics on this repo.
- Go81.6%
- PLpgSQL11.0%
- Shell7.2%
- Dockerfile0.1%
1 Review
ctx is an ambitious and surprisingly deep project for something created only recently. The pitch, “the memory your LLM pretends to have,” is backed by real implementation work rather than just a wrapper around a vector store: the repo includes a Go CLI and daemon, MCP/HTTP access, PostgreSQL + pgvector storage, scoped API keys, hybrid RRF retrieval, temporal scoring, background “Dream Mode” relationship discovery, embedded migrations, Docker deployment, and a substantial test footprint. The README does a good job explaining not only what the system does, but also the failure mode it is trying to solve: LLM memory drift, stale stored claims, and the need to verify remembered context against live state.
What stood out most is the engineering seriousness. There are 56 Go test files, integration tests with Testcontainers/Postgres, a shell benchmark suite covering auth, scope isolation, CRUD, retrieval, and MCP behavior, plus GitHub Actions for linting, race-tested unit tests, integration tests, Docker builds, and multi-platform releases. The code is organized into clear internal packages for retrieval, storage, handlers, CLI, ingest, auth, digest, dream logic, and LLM plumbing, which makes the project feel maintainable despite the complexity.
The main adoption gap is onboarding. The README is detailed, but it is dense and assumes a fairly advanced operator who is comfortable wiring PostgreSQL 18, pgvector, model endpoints, env vars, Docker profiles, API keys, and Claude/MCP integration. A shorter “first successful local run in 10 minutes” guide would help a lot, especially with expected outputs for ctx health, ctx save, and ctx query. Community signals are still early: GitHub metadata shows 4 stars, 1 fork, no open issues, and the default branch is root, which may surprise contributors looking for main. A CONTRIBUTING guide, security notes, and a small architecture diagram for the retrieval pipeline would make it easier for outsiders to participate.
Overall, ctx looks like a serious personal-infrastructure project that is becoming a reusable open-source tool. Its strongest quality is that it treats LLM memory as an auditable system with scope, time, retrieval quality, and maintenance behavior, rather than a vague “save notes to embeddings” feature. Its next big win would be making that sophistication easier to try without reading the whole system first.
Thank you! Indeed the onboarding is quite rough at the moment, thus I made a local pre-commit hook, that demands that the readme.md has to be staged. this ensures updates are carefully added to the readme too, in order to have it as best entry-point to the project. If someone would instruct Claude Opus to set this up, it would likely do a good job, as I've made a section LLM's can refer to, in oder to get a deeper understanding in how this could be integrated into themselves. I'm missing an update hook tho, so Users of ctx would currently need to seek out for updates, rather than getting informed by the cli about dangling updates. Essentially, ctx is tailored to my current working environment. I do have a friend running it in a MacOS environment too, but apart from that, I hope some more testers with diverse environments may join the fun! All in all, I also have more than 2 gb of internal project documentation, test run data and benchmarks, which led to the current project quality. For obvious reasons of them containing personal data about myself, as I just use my actual and real dataset for testing, I'm not releasing it publically. ctx is just the reflection of what I'm using actively every single day.