deniz.in

Markets

Weather

Loading weather

· via Hacker News – Front Page (native)

Lossless-memory: open-source AI memory that keeps every line and never summarizes

A Hacker News-featured project stores every conversation line verbatim with timestamps and searches time-first, arguing that summarization is what makes AI assistants feel forgetful.

Lossless-memory: open-source AI memory that keeps every line and never summarizes

A project called lossless-memory, featured on Hacker News through its GitHub repository, takes a contrarian position on long-term memory for personal AI: never summarize anything. According to the project's README, the two approaches that dominate current memory systems — compressing conversations into compact notes, or embedding them and retrieving similar chunks — both discard the details a daily user cares most about, namely exactly what was said and when. The repository's answer is to store every line verbatim, timestamp every record, and make time the primary axis of retrieval.

The scope is deliberately narrow: one person, one AI assistant, one machine, with no server and no cloud dependency. The README reports that this implementation has run every day since July 2026 for a single user, with raw logs going back to June 2026, and that the design lineage reaches back to a December 2025 prototype and a predecessor in daily use from January 2026.

Three components

The design rests on three parts.

First, a lossless raw log. Every conversation turn becomes a fixed seven-field record — timestamp, actor, role, record type, verbatim text, model identifier and session identifier — appended to a per-day JSONL file. The logs are the source of truth: every index can be deleted and rebuilt from them, and nothing else is required to survive a failure.

Second, what the project calls the Temporal Backbone. Time is the primary axis rather than metadata. The exact-match index is SQLite FTS5, bigram-tokenized to handle both Japanese and English, with the timestamp stored alongside every row. A query parser converts time expressions into a date range before any ranking happens, so a query like yesterday evening plus a keyword first narrows the window and then ranks words within it, returning results in chronological order and unmodified. Semantic search through sqlite-vec exists only as a fallback when the exact index finds too little inside the range, and the README states the fallback is disclosed in the output header.

Third, LLL, a small index of timestamped topic markers that is injected into the model's context on every turn. This is what lets the assistant resume a thread after its context window is compacted or a session ends. An unusual constraint applies: the human writes the markers and the model only reads them, so the model never edits its own sense of what matters.

A daemon re-indexes incrementally on a default ten-minute interval and reprocesses only the days whose source files changed.

An operating record, failures included

The README publishes measurements from the running instance rather than projections. After a redesign, the exact-search index rebuild dropped from 40 seconds to 1.24 seconds. The vector index told a messier story: 447,013 rows on 2026-08-31, swelling to 865,588 rows on 2026-09-04 at its worst because of contaminated data, then falling to 124,174 rows after a fix. The vector store on disk shrank from 2.54 GB to 337 MB. The project keeps the bad numbers on purpose and documents the failures in a lessons file.

Stated limitations

The README is blunt about scope. The system is single-user and single-machine with no multi-tenant story. Relative time phrases such as yesterday or 3 days ago are parsed in Japanese only; English speakers must use absolute dates for now, with English relative phrases on the roadmap. The primary ingest path targets Claude Code's JSONL format, though a plain importer is included. There are no benchmarks — the numbers are operational measurements, not comparisons. Semantic search depends on a local sentence-transformers embedding model, with CPU sufficient and GPU optional. A quickstart example and a round-trip test cover the ingest-index-query path in about five minutes.

Why it matters

Most memory layers shipping with AI assistants today treat compression as the feature: summarize, embed, retrieve approximately. Lossless-memory is a working counterargument built from ordinary parts — JSONL, SQLite FTS5, sqlite-vec — and run in production by exactly one person. That is both its limit and its interest. With no benchmarks and a Japanese-first parser, it is a data point rather than a validated alternative, but it sharpens a design question the field keeps deferring: if what users experience as memory is the exact words and the time they were said, then summarization may not be the fix for forgetting — it may be the forgetting. The stated long-term goal is a companion AI for people who live alone, remembering on hardware the user owns, and this repository is positioned as that memory layer.

  • #ai-memory
  • #open-source
  • #sqlite
  • #local-first
  • #personal-assistants

Related posts