Session Storage
الجلسات Storage
Start with meaning, then move to detail.
This lesson explains Session Storage as part of Hermes internals and extension points. You will learn what it does, when it matters, and the smallest safe test that proves it works.
If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?
For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.
For advanced readers, inspect Architecture Overview, SQLite Schema, Sessions Table, then verify failure modes and version compatibility.
Know Python, Git, and basic project structure before changing code.
A clear outcome before you read.
- Understand Session Storage without assumed prior knowledge.
- Separate the source description from what still needs testing in your environment.
- Read the first command and identify its inputs and outputs before copying it.
Short definitions before the details.
- Session & memory
- A session holds conversation context, while memory keeps selected facts that should persist.
What does the source say, and in what order?
- 01Architecture Overview
Start here to understand the core idea or structure.
- 02SQLite Schema
Read this after the foundation, then connect it to the previous step.
- 03Sessions Table
Read this after the foundation, then connect it to the previous step.
- 04Messages Table
Read this after the foundation, then connect it to the previous step.
- 05FTS5 Full-Text Search
Read this after the foundation, then connect it to the previous step.
- 06Schema Version and Migrations
Read this after the foundation, then connect it to the previous step.
- 07Write Contention Handling
Read this after the foundation, then connect it to the previous step.
- 08Common Operations
Read this after the foundation, then connect it to the previous step.
- 09Initialize
Read this after the foundation, then connect it to the previous step.
- 10Create and Manage Sessions
Finish here to verify the result and special cases.
Copy only after you understand the effect.
~/.hermes/state.db (SQLite, WAL mode)
├── sessions — Session metadata, token counts, billing
├── messages — Full message history per session
├── session_model_usage — Per-model/per-task usage attribution rows
├── messages_fts — FTS5 virtual table (content + tool_name + tool_calls)
├── messages_fts_trigram — FTS5 virtual table with trigram tokenizer (CJK / substring search)
├── messages_fts_cjk — FTS5 virtual table with cjk_unicode61 tokenizer
├── state_meta — Key/value metadata table
├── gateway_routing — Gateway routing metadata
├── ### Messages Table
Abridged — the full schema also includes `effect_disposition`,
`platform_message_id`, `observed`, `active`, `compacted`, `api_content`,
`display_kind`, and `display_metadata`:Notes:
- `tool_calls` is stored as a JSON string (serialized list of tool call objects)
- `reasoning_details`, `codex_reasoning_items`, and `codex_message_items` are stored as JSON strings
- `reasoning` stores the raw reasoning text for providers that expose it
- `api_content` is a byte-fidelity sidecar: the exact content string sent to the API for this message when it differs from `content` (ephemeral memory/plugin injections, persist overrides). It preserves the wire bytes for prompt-cache-stable replay — stored as sent, except lone surrogates, which sqlite3 cannot bind and which the conversRead the first command and identify its inputs and outputs before copying it.
Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.