Short-Term Memory
Short-term memory is managed through conversation continuity. On Gemini, the bot uses the Interactions API and tracks aprevious_interaction_id for each user, scoped to the exact (guild_id, channel_id, user_id) combination. This means each user’s conversation thread is isolated — two users talking in the same channel maintain separate, independent threads that don’t bleed into each other.
On all other providers, short-term continuity is stateless. The bot relies on the persona and the long-term memory injection to provide context rather than a running conversation chain.
To wipe the server-side conversation history for a channel, run /clearmemory. This clears the stored interaction IDs for that channel and starts a fresh thread on the next message.
/clearmemory requires Administrator permissions and affects the entire channel, not a single user.Long-Term Memory
After every user message, the bot runs a background fact extraction pass. It asks the active model whether the message reveals anything worth remembering — a name, job, location, interest, ongoing project, or relationship. This happens silently in the background with no visible confirmation to the user. Facts that come back from the extraction pass are scored by importance on a scale of 0.0 to 1.0. Only facts with an importance score of 0.3 or higher are kept. The top 20 facts per user (ranked by importance) are retained in the database — older, lower-importance facts are pruned automatically as new ones come in. All facts are stored in a local database keyed byguild_id + user_id. The database survives restarts and is provider-neutral — your users’ facts persist even if you switch from Gemini to Groq or back.
When a user sends a message, the bot injects their stored facts into the system prompt as a [Known facts about {display_name}] block before generating a response.
Fact Isolation
Memory is scoped per guild. Facts collected from a user in one server are never visible to the bot in a different server, even if it’s the same user. The identity key is alwaysguild_id + user_id.
Managing Memory
Viewing Stored Facts
Run/memorylist to see the facts the bot has stored about you. Each fact is displayed with its importance score and list number. Admins can view any user’s facts by passing an optional [user] argument.
Clearing All Facts for a User
Run/memoryclear to wipe all stored facts for yourself. Admins can clear another user’s facts by passing their name or mention as the [user] argument. The bot will confirm how many facts were deleted.
Deleting a Specific Fact
Run/memorydelete <index> to remove a single fact by its list number from /memorylist. Use this to surgically remove something the bot remembered incorrectly or that you’d prefer it forget. Admins can delete facts for other users by including the [user] argument.
Permissions
| Command | Regular users | Admins |
|---|---|---|
/memorylist [user] | Own facts only | Any user |
/memoryclear [user] | Own facts only | Any user |
/memorydelete <index> [user] | Own facts only | Any user |
~memorylist (~meml), ~memoryclear (~memcl), and ~memorydelete (~memdel).
Privacy Notes
- All memory is stored locally on your host machine. Nothing is sent to an external service.
- The identity key is
guild_id + user_id— each user’s data is fully isolated from every other user and every other server. - Fact extraction runs silently in the background. Users receive no notification when a fact is stored.
- There is no minimum message length or opt-in required — extraction runs on every user message to the bot.