What Is a Session?
A session is Cognee’s short-term memory for a specific user during search operations. It is identified by(user_id, session_id) and stores an ordered list of recent interactions created by calls to cognee.search().
When you omit session_id in a search call, Cognee uses the session ID default_session and still stores the turn when caching is enabled. Sessions are created and used only for these search types: GRAPH_COMPLETION, RAG_COMPLETION, TRIPLET_COMPLETION. Batch queries do not use the session cache, and other search types do not read or write session history.
Cognee reads from this session memory at the start of a search to recover earlier turns. When the search finishes, it writes a new interaction to the session so the history grows over time.
Using the same session_id across searches allows Cognee to include previous interactions as conversational history in the LLM prompt, enabling follow-up questions and contextual awareness.
Sessions require caching to be enabled. See the next sections and Configuration Details below. If caching is disabled or unavailable, searches still work but without access to previous interactions.
How Sessions Work
Sessions are used during search operations. When you callcognee.search() with a session_id:
- Retrieve context – Cognee finds relevant graph elements for your query
- Load conversation history – If caching is enabled, previous interactions for
(user_id, session_id)are loaded - Generate answer – The LLM receives the query, graph context, and retrieved history
- Save interaction – A new Q&A entry is stored in the session cache
Cache Adapters
Cognee supports two cache adapters for storing sessions. Redis is recommended for distributed or multi-process setups, while Filesystem can be used when you need a simple local cache without network dependencies. Both provide the same functionality; only the storage backend differs. Below are the configuration options for each adapter with additional details.- Redis
- Filesystem
Add to your Start Redis:
.env file:- Fast in-memory storage
- Supports shared locks for Kuzu (multi-process coordination)
- Requires a running Redis instance and network connectivity
Session Data Structure
Session Data Structure
Sessions store interactions as JSON entries in a list. Each entry contains:
- time: ISO 8601 timestamp (UTC)
- question: The user’s query text
- context: Context used for the answer; may be empty if summarization is not enabled
- answer: The LLM’s response
- qa_id: Unique identifier for the entry (used for feedback and updates)
- feedback_text: Optional user feedback text
- feedback_score: Optional feedback score, 1–5
agent_sessions:{user_id}:{session_id}Each user can have multiple sessions, each maintaining its own cache of short-term information.Configuration Details
Configuration Details
Environment Variables:
CACHING(bool): Enable/disable caching (default:false)CACHE_BACKEND(str):"redis"or"fs"(default:"fs"whenCACHING=true)CACHE_HOST(str): Redis hostname (default:"localhost")CACHE_PORT(int): Redis port (default:6379)CACHE_USERNAME(str, optional): Redis usernameCACHE_PASSWORD(str, optional): Redis password
- Cognee includes up to the last 10 session entries when building LLM conversation history.
Adapter Comparison
Adapter Comparison
| Feature | Redis | Filesystem |
|---|---|---|
| Storage | In-memory (Redis) | Local disk (diskcache) |
| Performance | Very fast | Fast (local I/O) |
| Multi-process | ✅ Supported | ❌ Not supported |
| Shared locks | ✅ Yes | ❌ No |
| Network required | ✅ Yes | ❌ No |
| Setup complexity | Medium | Low |
| Best for | Production, distributed | Development, local |