Docs · Memory
  1. Getting started
  2. Building
  3. Iterating
  4. Memory
  5. Models and keys
  6. Gateway
  7. Self-hosted runtime
  8. Usage and billing
  9. Deploy a token
  10. FAQ
Memory

Memory

Horai remembers three different things, in three different places, for three different reasons. You can see all of it and delete any of it.

Layer 1 — the thread

Each thread keeps its own history, and a chat turn reads the thread it belongs to. That is what makes "make it darker" mean anything.

History is carried under an explicit token budget rather than growing forever. While a thread fits the budget it is passed through untouched. When it outgrows it, the most recent turns stay verbatim and everything older is folded into a single summary that preserves the concrete things you said — names, numbers, colours, decisions — instead of being dropped.

So a café name you gave in the second message still reaches the model twenty messages later. The summary is treated as the durable part: if space runs short, older verbatim turns go first and the summary is kept.

Deleting a thread deletes its history.

Layer 2 — what an app was built from

A deployed app remembers its own project. That is what iterating stands on: when you ask for a change, the agent loads the source of the app you are talking about and edits it, rather than rebuilding from your original sentence.

This memory is attached to the app, and it works across threads — you can come back days later, in a new thread, refer to "the bill splitter I built", and it finds the right project.

Layer 3 — facts about you

A small set of durable facts is kept per wallet, so preferences you have already stated do not have to be restated in every new thread. Five kinds of fact are recorded:

Fact Example
language which language you write in
ui_theme_pref prefers dark interfaces
style_pref no serif fonts
brand_name the name of the thing you are building for
business_type a weekend market stall

Each fact is stored with the job it was learned from, so any row can be traced back to what you actually said, and with a confidence score — an extraction the model is unsure about is never written at all.

Only the facts relevant to what you are currently asking are included in a turn, under a small budget of a few hundred tokens. It is a short block of background, not your whole history.

Facts never cross wallets. Every read, every write and every delete is scoped to your wallet in the query itself, and that invariant is covered by tests that block a release if they fail.

Seeing and deleting it

Settings → Memory lists every fact held for your wallet, with a delete link on each row:

settings · memory · this wallet
• prefers dark UI, no serif fonts        delete
• planning a weekend market stall        delete
• last app: splitbill · iterated ×2      delete
memory                                        on
  • Delete one removes that row.
  • Delete everything forgets every fact for your wallet at once.
  • The switch turns memory off for your wallet: nothing further is learned and nothing is injected into your chats. Existing facts are not deleted by the switch — they stay listed so you can decide about them yourself. Turning it back on resumes learning.

Deleting is immediate and it is a delete, not a flag.

Next

Models and keys covers which model runs your request, and how to make it run on your own key.