Understand conversation memory
Conversation memory combines SQLite messages with a separate ChromaDB conversation collection. Set ENABLE_CONVERSATION_MEMORY=false when you do not need persistence, and restart the backend.
Continue a thread
Section titled “Continue a thread”With memory enabled, /api/v1/query returns a conversation_id. Send it on the next request along with a non-secret user_id. A new ID creates a new logical thread; it does not establish an access-control boundary.
Current limitations
Section titled “Current limitations”| Behavior | What it means for you |
|---|---|
Missing user_id defaults to the API token | The credential can be stored and logged as a user identifier |
| Semantic history search is unfiltered | Other threads can influence an answer |
| Conversation endpoints check only the shared API key | Caller ownership is not enforced |
| Message retrieval sorts oldest first before limiting | Longer threads may omit recent context |
| Expiration cleanup deletes SQLite records only | Semantic history can survive the retention deadline |
Do not use this implementation for mutually untrusted users or sensitive conversations. A supplied user_id avoids the default identifier but does not fix authorization or retrieval isolation.
Delete a conversation
Section titled “Delete a conversation”The authenticated DELETE /api/v1/conversations/{conversation_id} endpoint attempts to remove SQLite messages and corresponding vector entries. A vector deletion failure is logged but can still produce a successful API response. Verify both stores before asserting complete deletion.
Retention and backups
Section titled “Retention and backups”Retention defaults to seven days for newly created query conversations. Cleanup must actually run; there is no automatic expiry filtering on reads. Backups can retain earlier copies. See backup and restore for storage coverage.
Next: API reference or security boundaries.