Skip to main content
The completion server has a built-in memory system that tracks which completions you accept and reject, extracts patterns, and uses them to improve future suggestions. The more you use it on a project, the more accurately it predicts what you want.

How it works

Project-scoped storage

Each project gets its own memory file at ~/.local/share/zeroxzero/projects/<hash>/memory.json. Patterns learned in one project never bleed into another. When no project_root is provided, a global fallback is used.

Three signals

  1. Accepts — when you accept a ghost-text suggestion, your editor plugin calls POST /completion/accept. The server stores the prefix context, the accepted text, and auto-detects the category.
  2. Rejects — when you dismiss or overwrite a suggestion, your editor calls POST /completion/reject. This is negative signal.
  3. Rules — after 3+ accepted completions share the same structural pattern (e.g., throw new <ErrorType>(<message>)), the server automatically extracts a learned rule. Rules are weighted by the accept/reject ratio.

Categories

Every completion is auto-tagged with a category based on the prefix context:
CategoryDetected when…
importPrefix starts with import or from
error-handlingNear try/catch, throw, or guard clause (if (!x))
type-annotationAfter : with PascalCase response
returnAfter return keyword
variableAfter const x = or let x =
conditionAfter if, while, for
argumentAfter ( or ,
function-bodyInside a function definition
otherNone of the above
When fetching relevant examples for a new completion, same-category entries score higher.

Rule learning

The rule extractor identifies structural patterns in accepted completions:
Accepted textExtracted pattern
throw new NotFoundError("user")throw new <ErrorType>(<message>)
const data = await fetchUser()const <var> = await <fn>()
if (!user) { throw ... }if (!<var>) { <throw/return> }
const { name, email } = userconst { <fields> } = <source>
Rules need 3+ matching accepts to be created. They’re assigned a confidence score based on the accept/reject ratio — if you reject a pattern as often as you accept it, the rule gets dropped.

How it affects the prompt

Each completion request’s prompt is enriched with:
<learned_preferences>
The user has established these patterns through repeated use:
- [error-handling] throw new <ErrorType>(<message>) (60% confidence, 5 examples)
- [variable] const <var> = await <fn>() (75% confidence, 8 examples)
</learned_preferences>
<accepted_examples>
[error-handling] ...if (!user)  -> throw new NotFoundError("user not found")
[variable] ...const result =  -> await db.query(sql, params)
</accepted_examples>
This goes alongside the project conventions and file-level context in the prompt.

Growth curve

UsageWhat the model sees
Day 1System prompt + file prefix/suffix only
~10 completionsSystem prompt + 3 relevant accepted examples
~30 completionsExamples + first learned rules
~100 completionsStrong rules, high confidence, category-specific examples

Inspecting and managing memory

# View stats for a project
curl "http://localhost:4096/completion/memory/stats?project_root=/path/to/project"

# Clear a project's memory
curl -X DELETE "http://localhost:4096/completion/memory?project_root=/path/to/project"

# Clear all memory
curl -X DELETE http://localhost:4096/completion/memory

Storage limits

  • Max 500 accepted entries per project (oldest trimmed)
  • Max 200 rejected entries per project
  • Max 30 learned rules per project
  • Memory files are JSON, human-readable at ~/.local/share/zeroxzero/projects/

See also