How Briglia remembers

One conversation, no sessions

Most assistants start every chat empty and throw it away when it fills. Briglia keeps a single conversation from install onward. You can talk to it from the terminal, from Telegram or from the phone app; it is the same conversation, and it does not matter which device you used yesterday.

What makes this possible is a distinction Briglia draws that session-based tools do not: the difference between the conversation and the work.

Conversation versus work

A day of agent work can be tens or hundreds of millions of tokens — tool calls, command output, file contents, web pages, reasoning. The messages you and Briglia actually exchanged that day are about ten thousand tokens. And those messages contain everything that matters afterwards: what you asked for, what you decided, what you prefer, what was left open.

So Briglia treats the two differently:

• The work — tool calls and results, reasoning, media — lives in a working context with a budget. When the budget fills, the oldest of it is pruned or compacted into a short summary (see Storage & privacy for snapshots and long turns). The work is never what Briglia remembers by. Since CLI 0.2.48 only the three newest of these past-turn summaries stay in full; older ones shrink to a one-line stub (time span, files touched, and a link to the snapshot holding the full text, which Briglia can open when it needs the detail). A snapshot that a stub still points to is kept out of the usual snapshot cleanup.
• The conversation — your messages and Briglia's replies — is never dropped. It is archived.

Chunks and summaries

When the live conversation grows past about 20,000 tokens of messages, the oldest 10,000 or so become a chunk: the full transcript is saved verbatim as a plain-text file, and a summary of about 1,500 tokens is written next to it. The newest messages stay live, so the model always has the recent exchange word for word.

Chunks roll up as they age. Four temporary chunks consolidate into one consolidated chunk (triggered once six have accumulated, keeping two as a buffer); older consolidated chunks roll into meta-summaries in batches of five. The result is a timeline that gets coarser the further back it goes — like your own memory — while the underlying transcripts stay intact. Since CLI 0.2.45 every summary, and the facts Briglia extracts about you, are written from the whole chunk; earlier versions read only its first 100,000 characters, which left out roughly the last 40% of each consolidated chunk.

The chunk size is configurable (archive_chunk_size, default 10,000 tokens, minimum 5,000). Summarisation runs in the background with retries; if the summarising model is unreachable, the raw messages wait rather than being lost, and Briglia tells you.

Since CLI 0.2.50 Briglia does not stop to wait for an archive. It keeps working with the conversation exactly as it was — same messages, same summaries — while the chunk is summarised, for as many turns as that takes; /status shows the job. The new summary and the removal of the archived messages happen together at the start of the next turn after it finishes, so the model never sees a summary and its original messages at once. The retries and alerts are the same as before. On a local model server that can only handle one request at a time, /archiveinline on restores the old behaviour of waiting for the archive before replying.

What the model sees on every request

Every request Briglia sends to the model carries, inside the system prompt:

1. A chronological timeline of archived history: the newest five consolidated chunks, every temporary chunk not yet consolidated, and up to ten meta-summaries covering everything older — each row with its date range and summary.
2. A profile of you, distilled from the archives as they are written: the people in your life, your preferences, decisions and ongoing projects. Once it passes about 40,000 characters it is tidied back toward 30,000 (see Keeping the profile lean).
3. The live conversation: the most recent messages verbatim, plus the current turn's work.

Nothing has to be retrieved first. The model reads the timeline the way you would read a diary index, and modern models reconstruct what they need from it: a decision from months ago is on the page, in order, next to what came before and after.

Since CLI 0.2.53 the system prompt stays the same for the whole turn: the profile, your names and the pointer to retired facts are read once when a turn starts (and once per subagent run). If a background archive updates the profile in the middle of a turn, the update shows from the next turn. This keeps the provider's prompt cache valid during long turns, instead of a mid-turn profile change making the whole conversation be billed again.

Also since CLI 0.2.53, on OpenAI routes — the OpenAI API, the ChatGPT subscription, GPT Luna on OpenCode Go and OpenRouter's openai/… models — the short status note listing running background jobs and subagents is sent as a system message instead of a user message. The text is the same; on OpenAI's cache a user-role note at the end of each request kept the cache from growing during long turns with background work. Other providers keep the note as before. On every route, command names inside that note are shown as quoted, cleaned, length-limited data, with secrets redacted.

Keeping the profile lean

Each time a chunk is archived, Briglia adds the new facts it learned about you to the end of your profile. Because the profile is sent with every request, it is meant for lasting things — who you are, the people around you, how you like to work, what you are building — not for the details of one finished task, which the summaries and transcripts already hold.

Since CLI 0.2.49 the profile is tidied by editing, not by rewriting:

• When: only when the profile grows past about 40,000 characters, and then it aims for about 30,000. Right after updating, a profile already over 30,000 characters is tidied once, at the next archive. Below those sizes nothing happens.
• How: Briglia shows the model the profile as a numbered list, together with the same archive summaries the fact extraction already sees and today's date. The model answers only with what to remove, what to shorten, and short new lines that replace several removed ones. Briglia applies those changes; every line the model did not touch stays exactly as it was. It is told to drop finished one-off investigations and to keep people, preferences and upcoming events.
• Nothing is thrown away: every removed or shortened line is first copied word for word into ~/.local/share/briglia/archive/retired_user_facts.jsonl. That file is never trimmed, Briglia can search it like the transcripts, and /exportmind carries it.
• Bounded: at most two passes per tidy-up. If one fails, Briglia waits (an hour, then six, then a day) before trying again; if it could not shrink the profile, it waits until the profile has grown further. It never retries on every message or restart.

What did not change: how chunk, consolidated and meta-summaries are written, and how new facts are extracted — same prompts, same requests. Earlier versions rewrote the whole profile once it passed 20,000 characters, again after every consolidation, and kept doing so on later archives and restarts; that extra work, which could delay a reply by several minutes, is gone.

Behind a summary

Summaries are the index, not the record. When the model needs more than a row gives it, it has three ways down:

• read_chunk_summaries expands a meta-summary row into its full per-chunk summaries, by chunk id or by date range — including chunks older than the oldest row shown.
• The verbatim transcripts are plain-text files in ~/.local/share/briglia/archive/, one per chunk. Briglia searches them with its ordinary grep and read_file tools, so a half-remembered name or a date is enough to find the exact exchange.
• The newest 300 conversation snapshots keep the full tool work of a period — what was run and what came back — for the cases where the work itself matters.

Moving, tuning, erasing

• /exportmind carries the whole memory — conversation, archives, transcripts, profile, snapshots — to another machine, including a Raspberry Pi or a phone.
• /prune frees working context by hand; it touches the work, not the conversation.
• /deleteuserdata erases everything.