EONYX memory: AGENTS.md, sessions and context compaction

Every turn starts with the model receiving context.
EONYX builds it from three parts.
AGENTS.md carries the project’s standing instructions.
Sessions hold the full history on disk.
Auto-summarization compacts the older turns as the window fills.

1 📌 AGENTS.md: project instructions

AGENTS.md holds the project’s rules and context.
EONYX finds these files while building the system prompt.
It walks up the directory tree from the working directory and collects one at every level.

1.1 Traversal rules

• The walk stops at the project root, the directory holding eonyx.json. Or at a directory with .git. Or at the filesystem root.
• Files attach from the outermost inwards. The nearest one comes last, so local rules refine the general ones.
• Each file enters the system prompt under # Project context: <relative path>.

Keep general rules at the repository root.
Keep specifics next to the code they describe.

my-project/
├── AGENTS.md            ← stack, conventions, prohibitions
└── services/
    └── billing/
        └── AGENTS.md    ← specifics of a particular service

1.2 What to write

# Project: My App

## Stack
- Go 1.26, PostgreSQL via pgx.

## Rules
- Run `go test ./...` and `go vet ./...` before committing.
- Do not refactor what you were not asked to.

## Prohibited
- Do not edit .env directly.
- Never run migrations without confirmation.

2 💾 Conversation memory

2.1 Sessions on disk

Every conversation is a session, fully persisted.
The format is JSONL: one message per line, tool calls and results included.

The store is shared across projects and sits with the global data.
On Windows that is %LOCALAPPDATA%\eonyx\.
On Linux and macOS it is $XDG_DATA_HOME/eonyx/, which defaults to ~/.local/share/eonyx/.
Session ids sort naturally: 20260705T091500-1a2b3c4d.

Writing is the source of truth.
If a message cannot be saved, the turn aborts rather than running past the disk.
Empty sessions, the ones that never got past the system prompt, are cleaned up on their own.

2.2 Working in the TUI

EONYX resumes the most recent session on startup.
From there:

New sessions get plain sequential titles: 1, 2, 3.
They never change on their own — only an explicit rename touches them.

2.3 Working from the console

eonyx sessions                  # list: id, date, message count, title
eonyx sessions --search parser  # search over titles and text
eonyx sessions delete <id>      # delete

eonyx run -c "continue"         # continue the most recent session
eonyx run -s <id> "and now…"    # continue a specific one

2.4 Auto-summarization

Set context_window on a model and EONYX starts tracking the history size.
It estimates about 4 characters per token and shows {ctx N%} in the header.
At 80% the indicator lights up, and summarization fires at the same threshold.

How it works:

• The last 3 user turns stay verbatim. Everything older goes to the model to be compacted into a running summary: decisions, facts, changed files, open tasks.
• The summary is appended to the system prompt under # Summary of earlier conversation. The next compaction folds in the previous summary.
• The boundary runs only along user messages, so a tool call is never split from its result.
• All of this is in memory only. The JSONL on disk keeps the full history, so an export or a reopened session shows the whole conversation.

3 📋 Summary