Every AI coding session starts from zero. The assistant that helped you trace a bug yesterday has no memory of it today. You explain the same context again, re-answer the same questions, and watch it rediscover the same facts. The tools I’ve built over the last six months — magellan, llmgrep, mirage-analyzer — solve the code structure problem. They make the codebase queryable. But they don’t solve the session continuity problem. An agent still can’t carry decisions, discoveries, or hard-won debugging context from one session into the next.

atheneum is the attempt to fix that. It’s an embedded knowledge graph that persists across sessions: tool calls, decisions, wiki content, code complexity signals, and raw session memory, all in a SQLite database with structured edges between them.

v0.5.0 is twelve days old. This is not a finished product. It is, however, running continuously and generating real data.

What’s in the graph

The live database on my machine contains 4,677 entities and 15,015 edges. Here’s the breakdown:

ToolCall      2,358   — every Claude Code tool use, timestamped and linked to session
WikiPage        280   — Logseq journal pages and wiki articles, synced in
Session         221   — coding sessions with branch, timestamps, tool counts
ReasoningLog    315   — reasoning traces stored during sessions
Reference       338   — symbol references (file:line)
Memory          130   — stable facts and dream-consolidated findings
File            198   — source files touched across sessions
Symbol          190   — code symbols (indexed via magellan)
TestRun         120   — test results linked to tool calls

Edges link these together: belongs_to_project, observed_in, wikilink, handled_by_tool, accessed, modified, CALLS, IMPORTS. The graph structure is what makes retrieval useful — you can ask “which sessions touched this symbol” or “what wiki pages link to this concept” and get answers from the edge traversal.

The two most-used CLI commands:

# Semantic search across all entity kinds
atheneum search ~/.magellan/atheneum/atheneum.db "AMD GPU inference" --limit 5

# Navigate: start from matching entities, walk edges outward
atheneum navigate ~/.magellan/atheneum/atheneum.db "session accountability" --concise --max-tokens 500

search does lexical search over stored content and returns scored results. navigate uses HopGraph — more on that below — and returns a token-budgeted subgraph. The --concise flag formats output as compact Markdown intended for paste into a language-model context window. --max-tokens 500 hard-truncates at approximately that budget.

Both work against whatever is actually in the database. The results above are real. The numbers are from a fresh process — all runtime counters start at zero, so what you see is the persisted graph state, not a cached view.

Dreaming module

v0.3.0 added a reflective memory consolidation pass. After a session ends, the dreaming module runs a 6-phase pipeline over stored memories:

SCAN → DEDUPLICATE → STALE → CONTRADICTION → VERBOSE → CONSOLIDATED

It uses trigram Jaccard similarity to detect near-duplicates, marks stale entries, flags contradictions, strips verbose redundancy, and produces consolidated Knowledge entities from surviving discoveries.

The memory-list command shows what survived:

atheneum memory-list ~/.magellan/atheneum/atheneum.db --limit 5

The current database contains complexity hotspot entries from the dreaming module — cross-project code quality signals that were extracted from session data and consolidated into stable memory. An example from the live DB:

dream/code/complexity_hotspot/abtop-draw_sessions_panel_active
  High cyclomatic complexity in abtop: 5 functions > 20
  Top: draw_sessions_panel_active=91 (loc=881, fan_in=2, fan_out=52)

dream/code/complexity_hotspot/llmgrep-search_symbols_impl
  High cyclomatic complexity in llmgrep: 6 functions > 20
  Top: search_symbols_impl=63 (loc=724, fan_in=2, fan_out=30)

These entries persist across sessions. The next agent that loads context for abtop or llmgrep gets this signal without re-running any analysis.

There’s also a dry-run mode:

atheneum dream ~/.magellan/atheneum/atheneum.db --dry-run --scope dream

which reports what would be consolidated without committing anything.

HopGraph

navigate is backed by HopGraph (v0.2.0): vector-based entry point + BFS subgraph walk + token-budgeted truncation.

The flow:

  1. Embed the query text (HashEmbedder at 128 dims by default; OllamaEmbedder at 768 dims as an optional feature)
  2. HNSW search across all indexed entities → ranked candidates
  3. BFS from top-k candidates, following allowed edge types to depth N
  4. Truncate subgraph to stay within the token budget

The HNSW index is persistent — it survives process restarts and is rebuilt during reindex. The in-process query cache (added in v0.3.1) means repeated identical queries don’t touch SQLite.

Cross-project queries (v0.5.0)

The latest release adds cross-project search. Rather than copying data between databases (which goes stale immediately), atheneum maintains a lightweight routing registry (meta.db) and lazily ATTACH DATABASE each registered project’s magellan DB on demand:

# Register once
atheneum meta-register envoy /home/feanor/Projects/envoy \
  /home/feanor/Projects/envoy/.magellan/magellan.db --language rust

# Search across all registered Rust projects
atheneum cross-search "build_router" --language rust --k 10

# Navigate with BFS walk per project
atheneum cross-navigate "error handling" --language rust --k 5 --depth 2

SQLite allows up to 10 ATTACHed databases per connection. The LRU cache defaults to 8 to stay safely under that limit. Unreadable or missing DBs are skipped with a warning — one broken project does not abort the query.

This is the piece that makes atheneum genuinely cross-project rather than per-project. A query for “error handling” can surface results from magellan, llmgrep, envoy, and rocmforge simultaneously, pulling from their live magellan symbol graphs.

Wiki sync

Logseq journal files and wiki pages can be synced directly into the graph:

atheneum sync-logseq ~/.magellan/atheneum/atheneum.db ~/wiki grounded
atheneum reindex ~/.magellan/atheneum/atheneum.db

This creates WikiPage entities from the markdown content and wikilink edges from [[...]] references. Navigate queries can then traverse from code symbols into wiki pages and back — linking a design decision in a journal to the code symbols it describes.

The 280 WikiPage entities in the live database came from this sync. Most are stub pages with link structure but limited body content; pages that have been visited recently via navigate queries have their full content indexed.

Multiple assistants

The database is not tied to a single assistant. Three consumers currently write to the same atheneum DB:

Claude Code (this environment): session data, tool calls, reasoning logs, and discoveries all go through the envoy coordination layer, which writes to atheneum.

atheneum-py: a Python port of the core atheneum library, used to connect Gemini CLI to the same graph. It implements the same memory and knowledge APIs in Python, so a Gemini session can read discoveries written by a Claude Code session and vice versa.

Hermes: an open-source Python AI assistant. The atheneum plugin at ~/.hermes/plugins/atheneum/ gives Hermes read/write access to the same graph. It uses plugin.yaml for discovery and exposes atheneum’s search and memory APIs as Hermes tools.

The multi-assistant aspect is the core design goal. The knowledge graph accumulates across every session, regardless of which assistant ran it. What Claude Code learned about llmgrep’s complexity hotspots yesterday is available to Hermes today.

MCP server

The atheneum-mcp crate (in the same repository) implements an MCP server using the rmcp library. It exposes atheneum’s memory, search, navigate, and discovery APIs as MCP tools for any MCP-compatible client.

I have not tested this end-to-end against a running MCP client in this session. The crate builds and the protocol implementation exists, but I can’t claim it’s been verified beyond compilation.

Current state

v0.5.0 — released 2026-06-09
v0.1.0 — released 2026-05-31

Twelve days of active development. It’s moving fast because it’s solving an immediate problem in my workflow. The graph is real and in use daily. The API is not stable — v0.3.x through v0.5.0 had breaking changes in store_memory, the dreaming module was added and rewritten, and cross-project queries didn’t exist a week ago.

What works: the CLI (search, navigate, memory-list, graph-stats, dream dry-run), the dreaming consolidation pass, wiki sync, memory persistence across sessions. What’s less certain: the MCP server end-to-end, atheneum-py feature parity with the Rust version, HopGraph accuracy at high entity counts.

The source is at github.com/oldnordic. The crate is on crates.io. It requires a magellan-indexed project to be most useful; read the grounded coding workflow for context on how the tools fit together.