Skip to main content

Thread System

Loom’s thread system provides persistent conversation history with bidirectional synchronization between local storage and the server. Every coding session is a thread that captures:
  • Complete message history (user, assistant, tool calls)
  • Agent state (waiting, executing tools, error)
  • Git context (branch, commits, remote URL)
  • Workspace metadata

Architecture

Components:
  • Thread: Core data model (defined in loom-common-thread/src/model.rs)
  • LocalThreadStore: XDG-compliant local storage
  • SyncingThreadStore: Hybrid store with background sync
  • ThreadSyncClient: HTTP client for server communication
  • PendingSyncQueue: Offline-first sync queue

Thread Data Model

Thread Structure

Thread ID Format

Thread IDs use UUIDv7 (time-ordered) with a T- prefix:
Benefits:
  • Sortable by creation time
  • No collision risk (globally unique)
  • Human-readable prefix
  • Compatible with databases (indexed strings)

Message Types

Agent States

Each state includes:
  • Retry count (for error recovery)
  • Last error message (if applicable)
  • Pending tool calls (for ExecutingTools)

Thread Visibility

Sharing workflow:

Local Storage

XDG Directory

Threads are stored in:
File format: Pretty-printed JSON (human-readable)

LocalThreadStore API

save_and_sync() blocks until server sync completes. Use for commands that exit immediately (e.g., loom share).
Fallback when server is unavailable:
Searches:
  • Thread title
  • Git branch name
  • Git remote URL
  • Commit SHAs (prefix match)
  • Tags
  • Message content (full text)

Server Synchronization

Sync Strategy

Loom uses offline-first synchronization:
1

Save locally first

2

Queue for sync

3

Background sync

Spawned task processes queue:
4

Handle conflicts

Server returns latest version on conflict. Client merges or retries.
Benefits:
  • Works offline (local-first)
  • No blocking on network
  • Automatic retry on failure
  • Conflict detection via versioning

SyncingThreadStore

Usage:

Sync API Endpoints

Creates or updates a thread. Server validates:
  • Thread ownership (via auth token)
  • Version number (optimistic locking)
  • Visibility rules

Git Integration

Loom automatically captures git state:

Snapshot Workflow

Called:
  • On thread creation
  • After every tool execution
  • On graceful shutdown (Ctrl+C, EOF)

Search by Git Metadata

Private Sessions

Create local-only sessions that never sync:
Sets:
  • is_private = true
  • visibility = Private
The SyncingThreadStore skips sync for private threads:
Use cases:
  • Sensitive codebases
  • Offline development
  • Personal experiments

Thread Lifecycle

1

Creation

2

User Input

3

LLM Response

4

Tool Execution

5

State Update

Resume Behavior

Restores:
  • Full conversation history
  • Agent state (resumes from last checkpoint)
  • Workspace context (warns if workspace changed)
  • Git state (shows branch/commit changes)
Example output:

Search Implementation

PostgreSQL full-text search:
Query:

Local Search Fallback

Substring matching across all fields:

Performance Optimizations

Lazy Loading

Thread summaries load minimal data. Full threads fetched on demand.

Background Sync

Non-blocking sync prevents UI lag. Errors retried automatically.

Local Caching

Recently accessed threads cached in memory (future enhancement).

Indexed Search

PostgreSQL GIN indexes for fast full-text queries.

Troubleshooting

Check network connectivity:
Verify authentication:
The thread is still saved locally. Sync retries automatically.
List all threads:
Search by content:
Check local storage:
Happens when thread modified on multiple devices simultaneously.The server returns HTTP 409. Client should:
  1. Fetch latest version from server
  2. Merge changes (manual or automatic)
  3. Retry with updated version
Try:
  • Broader query terms
  • Different keywords (branch name, repo URL)
  • Local search if server is down
Verify thread exists: