Session Intelligence

Unified telemetry combining per-session stats, context-aware suggestions, and cross-session memory recall for AI-assisted development.

What Session Intelligence Is

Session intelligence ties together three capabilities into a single coherent system:

  • Stats -- Per-session metrics (tokens, costs, tool calls, timing)
  • Suggest -- Context-aware suggestions based on session patterns
  • Recall -- Cross-session memory search using keyword and bigram matching

It replaces what were previously separate observer, autopilot, and memory subsystems. Everything is local and file-based -- no external services, no cloud sync, no accounts required.

Stats

Stats tracks quantitative metrics for each AI assistant session:

  • Token usage -- Input tokens, output tokens, and total tokens consumed
  • Costs -- Estimated spend based on the model in use (Opus, Sonnet, Haiku)
  • Tool calls -- Count, types, success/failure ratio
  • Timing -- Session duration, time per tool call, idle gaps

Stats data is collected automatically via the PostToolUse hook and persisted on the Stop event. No manual tracking required.

Loading code block...

Suggest

Suggest generates context-aware recommendations based on patterns observed during the session. Suggestions trigger when thresholds are crossed -- context window past 70%, anti-pattern detected, cost exceeding projected budget.

Examples:

  • "Context pressure is high. Consider compacting or starting a new session."
  • "The same file has been edited 6 times without converging. Review the approach."
  • "Token burn rate suggests the session will exceed $2.00. Switching to Sonnet could reduce cost by 60%."

Suggestions surface in the CLI and, when hooks are active, can be injected into the assistant context.

Recall

Recall enables cross-session memory search. On each UserPromptSubmit, the recall handler searches previous session snapshots for context relevant to your current work using keyword matching and bigram scoring.

Recall answers questions like:

  • What approach did I use last time I worked on authentication?
  • What were the blockers at the end of yesterday's session?
  • Which files were modified during the pipeline refactor?

Search manually:

Loading code block...

Storage

All session intelligence data lives in .bootspring/memory/:

.bootspring/memory/ conversations/ # Raw conversation logs per session sessions/ # Session snapshots (metrics, summaries, timestamps) blocks.json # Structured memory blocks config.json # Memory configuration

Memory Blocks

Memory blocks are the structured context units that hooks inject into every prompt:

BlockDescription
personaYour name, role, communication style, working preferences
project_contextRepo name, tech stack, structure, conventions (auto-populated)
user_preferencesCommit conventions, preferred tools, project-specific rules
session_notesCarry-over notes from previous sessions

Auto-Populated Project Context

On first run (via bootspring init or bootspring hook install), session intelligence scans your project and builds the project_context block automatically from:

  • package.json / Cargo.toml / pyproject.toml for project metadata
  • .git/ for branch, remote, and recent commit history
  • Framework-specific files (next.config.*, tsconfig.json, etc.) for stack detection

The result is a concise context block (typically under 200 characters) that gives the assistant immediate orientation. Regeneration takes less than 100ms.

Session Lifecycle

  1. Start -- UserPromptSubmit fires. Recall loads memory blocks and injects them into the prompt.
  2. Work -- PostToolUse fires after each tool call. Stats collects metrics. Suggest evaluates patterns.
  3. End -- Stop fires. Stats persists metrics. Session notes are updated. A snapshot is written to .bootspring/memory/sessions/.
  4. Next session -- Recall searches the archive and injects relevant context. Each session builds on the last.

CLI Commands

Loading code block...

All commands support --json for structured output.

Design Principles

Local-first. All data stays on your filesystem. No cloud component, no sync service.

File-based. Plain JSON and text files. Easy to version-control, back up, and debug.

Automatic. Runs via hooks without manual intervention. Install once with bootspring hook install.

Graceful degradation. If any component fails, the others continue. A failure in stats never blocks recall.

Further Reading