The OpenClaw user model
Why stable preferences live in their own file, the directive format with observed dates and status, superseding in place instead of appending, the fixed four thousand character cap, and the separate gateway profile identity
Preferences and facts fail differently. A fact that is merely present in context can still be recalled; a preference that is merely present stops being applied after a handful of turns. That asymmetry is why OpenClaw keeps the user model in its own small file with its own format rules, rather than mixing it into long-term memory.
The format contract
- Each entry is a metadata comment followed by one imperative directive: begin with an imperative such as always, never or prefer, record the date the preference was observed, use only active or superseded for status, keep one behavioural instruction per directive, and store only details that improve assistance rather than building a dossier.
- When a preference changes, update its existing section and keep the superseded entry next to its replacement so the current directive is unambiguous; do not append a second active directive elsewhere, because append-only contradictory history reliably causes models to answer from the stale value.
- The file loads beside long-term memory at session start with a separate small bootstrap budget, edits are picked up on later turns in a long-lived session, and if the file is absent startup simply continues without it.
- Choosing the right file is a table in the docs: stable preferences and relationship or project facts that change how you should be assisted go here, durable non-profile facts and decisions go to long-term memory, detailed observations go to dated daily notes, event-conditioned future actions become standing intents, and exact-time or recurring actions become scheduled tasks.
When a preference changes, update its existing section. Do not append a second active directive elsewhere in the file.
Keeping it compact
The user file has a fixed four thousand character bootstrap cap, smaller than the general per-file budget, and the configuration keys that size other bootstrap files can only lower this cap, never raise it. That is deliberate: profile guidance is meant to stay directive-sized so it cannot crowd project rules and durable facts out of the shared prompt budget. When the file approaches the cap, the documented order is to remove stale superseded entries while keeping each replacement next to its predecessor, move durable facts and lessons that do not change how you should be assisted into long-term memory, move detailed observations and running project context into dated daily files, and convert event-conditioned actions into standing intents so the trigger stays available without the full detail. The doctor command names the cap and recommends compaction when the fixed limit is what is biting, and gives different advice when the shared total budget is the constraint instead.
The profile beside the file
- The authenticated gateway profile is separate from the user file: it carries the display name and avatar other people see, a single-user gateway gives unidentified operator connections one durable local owner profile shared across devices, and that owner profile has no email, changes no permissions and cannot be merged with a personal profile.
- Verified identity can come through an identity-aware proxy or a tailnet login backed by the same account provider, recording the immutable numeric account id alongside the current login name so later renames stay attached to one person, and the account row itself stays read-only because token, password and unauthenticated connections cannot claim it.
- Public commit credit is a separate choice that defaults on for verified accounts: it adds the verified account's public no-reply address as a co-author trailer to commits created from shared sessions, the system prompt lists the exact trailers once for the agent to apply, and turning it off stops future attribution without rewriting commits that already carry it.
OpenClaw memory overview covers the file family this one belongs to and OpenClaw memory architecture why preferences are kept apart from facts.
What not to put here
The temptation with a user file is to write observations: notes about what someone said, when they said it, and what they seemed to want. The format resists that on purpose. An observation has to be interpreted before it can change behaviour, and interpretation is exactly what degrades over a long conversation. A directive does not need interpreting. The same logic explains the status metadata: a superseded entry sitting next to its replacement tells both the model and the next human reader which one is current, while a file of undated statements tells nobody. OpenClaw standing intents is where conditional future actions belong instead and The OpenClaw agent workspace the wider set of files an agent reads at start.
On Diali
On Diali the persona captured during onboarding enters these workspace files, and the workspace lives on a persistent volume, with daily snapshots and one-click restore available through the Backups add-on (included on Max). Hosted OpenClaw on Diali describes the hosted assistant and Diali pricing the plans it ships in.
- Directives, not observations; one instruction per entry.
- Supersede in place, keeping the old entry beside the new one.
- Four thousand characters, a cap configuration can only lower.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
