Every LLM conversation disappears the moment you close the tab. Ask something today, revisit the same idea next week, and it has no memory of ever having thought about it with you. Each thread is an island.
I wanted something different: conversations that accumulate into an actual picture of what I care about, not a transcript archive, but something closer to how memory itself works.
That's what led to Asterism.
What it does
Asterism parses your exported Claude conversation history and builds a local knowledge graph. It extracts (entity, relationship, entity) triples, and every time a concept resurfaces in a later conversation, the connection to it strengthens. Stop engaging with an idea, and it fades, eventually dropping off the graph entirely.
The result renders as an interactive constellation. Concepts you return to often glow brighter and sit more centrally. Concepts you've moved on from dim and drift into the dark.
How it works
-
Hebbian learning — edges strengthen each time the LLM traverses them (
weight += 0.2per traversal). Concepts left unrevisited for 3 hours of session time decay and vanish. - You are the central node — your own node sits at the center of the graph at full brightness, always. It never decays.
-
Local SQLite storage — the entire graph lives in
~/.asterism/asterism.db. No cloud, no sync, no accounts. - LLM context injection — relevant nodes and edges get injected into the Claude prompt automatically, so the model has implicit awareness of your past thinking.
- Triple extraction — a fast extraction model (local Ollama or Anthropic Haiku) pulls structured relationships out of each exchange.
Built local-first, on purpose
The only external calls are to the Anthropic API for chat responses and, optionally, Haiku for extraction. Extraction can also run fully offline via Ollama. No telemetry, no accounts, delete ~/.asterism/ for a clean slate.
Stack
| Layer | Tech |
|---|---|
| Storage | SQLite |
| Graph | NetworkX |
| Visualization | Vanilla JS force simulation |
| LLM | Anthropic SDK |
| Extraction | Ollama llama3.2:3b or Anthropic Haiku |
| UI | Streamlit |
| CLI | Click |
Where it's headed
This is v0.1.0, early and rough. Here's the direction:
- Beyond Claude — a memory layer that works across whichever frontier LLM you're using, not locked to one provider.
- Zero-friction install — no API keys, no local Python setup, cached in-browser.
- Simpler onboarding — fewer steps between finding it and running it.
If you've worked on local-first tools, LLM memory/context systems, or graph-based retrieval, I'd genuinely value your take on what to prioritize next.
Repo: https://github.com/biditdas18/asterism
Top comments (6)
I found the concept of Asterism to be really intriguing, particularly the way it utilizes Hebbian learning to strengthen connections between concepts as they resurface in conversations. I've worked on a few projects involving graph-based data structures and I'm curious to see how you plan to handle scalability and potential graph complexity as the user's conversation history grows. Have you considered implementing any mechanisms for pruning or consolidating nodes and edges to prevent the graph from becoming too dense or unwieldy?
Really glad this resonated, and good question; this is something I've thought about.
Pruning is already implemented: concepts that aren't traversed for a set window of session exposure time (currently 3 hours) decay and drop off the graph entirely. So the working assumption is that if you're not returning to an idea across sessions, it's no longer relevant enough to keep live. You can see the decay logic here: github.com/biditdas18/asterism/blo...
That pruning is really the answer to both questions; scalability today comes down to how well decay keeps the active graph small rather than any special infrastructure. The whole thing still runs on a single local SQLite file. Since pruning keeps the working set to what's still relevant, the graph should, in practice, remain bounded even over long periods of use.
One edge case I don't have a good answer for yet: someone interacting broadly across many parallel topics rather than deeply in a few could end up with a wider, denser graph that doesn't prune down as aggressively, and that could hit performance limits on retrieval/rendering before decay catches up. On my list to stress-test.
The local-first approach is what makes Asterism interesting to me. Most LLM memory systems focus on storing everything forever, but human memory is selective — things become stronger through repeated use and weaker when they are no longer relevant.
The Hebbian-style weighting combined with decay feels like a better direction than a simple vector database of past conversations. One challenge I’m curious about is how you handle conflicting memories over time. For example, if someone changes their opinion, architecture choice, or project direction, does Asterism currently distinguish between “old but historically useful” knowledge and “outdated context that should no longer influence future responses”?
A temporal layer on top of the graph could make this even closer to how real memory works.
Please confirm my profile.
Good catch, and no, it doesn’t distinguish those right now. The current model is purely frequency and recency based: traversal strengthens an edge, disuse decays it. There’s no mechanism for detecting that a stance actually changed versus just went quiet.
So today if you flip a decision, say switch from Postgres to SQLite, the old edge would just decay naturally over time from disuse rather than being explicitly superseded. That’s a real limitation: until it decays out, both could still surface as relevant context, with no signal to the model about which one is current.
A temporal/versioning layer like you’re describing, explicit “this supersedes that” edges rather than relying purely on decay, is exactly the kind of thing I’d want to add. Appreciate you naming it, it’s going on my list.
Hey Luis, quick update. I ended up implementing the versioning idea you suggested.
Now, when a fact changes, the old one is marked as superseded instead of simply fading through decay. It no longer gets passed to the model as current context, but it stays in the graph, so Asterism can still answer historical questions like "what did I use before?"
Thanks for the idea. I think this gets Asterism a little closer to what I originally wanted it to be: a memory system that can evolve as the user's context changes, rather than just storing and forgetting information.
I also added a few other things since then, including entity resolution to reduce duplicate concepts, some scaling benchmarks, and an experiment comparing the weighted graph against flat memory.
I wrote everything up in a short paper here if you're interested, or for anyone else reading this who wants to take a look:
github.com/biditdas18/asterism/blo...
I'd love to hear any other thoughts on where this could be improved. Feedback like this has been genuinely useful in shaping the project.
The versioning update is a really nice evolution of the original idea. Explicitly separating “current context” from “historical context” makes the memory layer much more useful for real-world agent systems.
I’d actually be interested in exploring this further together. I work on LLM/RAG and agentic systems, and I think there are some interesting directions here around temporal retrieval, memory evaluation, and integrating graph memory with production agent workflows.
If you’re open to collaboration, I’d be happy to contribute ideas or implementation work. I’m also interested in taking on paid AI/LLM engineering projects where this kind of memory or knowledge infrastructure could be useful.
If you’re planning the next stage of Asterism or have related projects/opportunities, feel free to reach out. I’d be glad to compare ideas and see if there’s a good fit.