Skip to content

Context library

Every distillation, excerpt, and file manifest is written to a local payload store and listed in the Library view. Payloads are immutable and content-addressed, so re-running the same capture costs nothing and produces the same hash.


~/.config/threadle/payloads/
ab/
ab3f…d21.json ← the payload
ab3f…d21.md ← human-readable sidecar (not written for kind "files")
tags.json ← hash → tags

The hash is sha256(kind ␀ provider ␀ sessionId ␀ content), sharded by its first two hex characters. Writes are atomic (temp file + rename) and skipped entirely when the file already exists.

A stored payload carries:

FieldMeaning
hashContent address
kinddistilled-summary · transcript-excerpt · files
createdAtCapture timestamp
sourceProvider + session id it came from
contentThe markdown itself
metaModel (for distills), message range, token estimate (chars ÷ 4), source title

Listing a payload derives a preview: the first line that carries meaning. Blanks, code fences, role headers, and tool-call lines are skipped.


Jump-list bookmarks (workflows, sessions, payloads, skills, rules, files) live under ★ Favorites. Soft links, not copies. See Favorites.

Library stays for reusable context payloads. Favorites is for “open this place again.”


The Library view listing stored payloads grouped by source session The Library view listing stored payloads grouped by source session

Payload rows under their source session, each with kind, size, and age.

Library rows are grouped by source session, newest group first. The group header links back to that session (❯ session).

ControlValues
Source chipsall plus every provider that actually produced a payload
Kindany kind · distilled · excerpt · files
Sortrecent first · largest first · title A–Z
Filter boxpreview, tags, source title, or hash

Each row shows preview, kind, size, and age. The ⋯ menu holds Source blueprint, Lineage, and Download raw. The inline workflow button seeds a canvas with the payload.

The detail aside shows hash, created, source, the tag editor, and the full content, with actions: → workflow, ❐ copy, ⇓ raw, ⌗ source, ❯ session.


Tags live in a sidecar (tags.json) so stored payloads stay byte-identical to their hash. Type into the tag box and press ⏎. The ✕ on a chip removes one.

Limits: up to 20 tags, each ≤ 40 characters. Duplicates and blanks are dropped. Clearing every tag removes the entry.

The tag reference is applied automatically when you copy a session’s reconstructed context into the library via → workflow · reference or library · reference on a blueprint (or the → control on an open-context window). Filter the library / palette for reference to find those snapshots. See Open files & context.

Terminal window
curl -X POST http://127.0.0.1:4570/api/payloads/<hash>/tags \
-H 'content-type: application/json' \
-d '{"tags":["auth-refactor","handoff"]}'

Or snapshot a session context (stores payload + merges the reference tag):

Terminal window
curl -X POST http://127.0.0.1:4570/api/context/reference \
-H 'content-type: application/json' \
-d '{"source":{"provider":"claude-code","sessionId":"<id>"}}'

Palette → library lists the 15 most recent payloads. Drag one onto the canvas and you get a context node that is already materialized. Its payloadHash is set, so it needs no source session and no Materialize press. Wire-dropping from a handle offers the same payloads under a library heading.

This matters for detached runs: a context node without a payload hash still runs headless when a session or agent is wired (extract / distill mid-run). Library drag is the path when you want a fixed brief with no source session.


EndpointReturns
GET /api/payloadsMetadata for every payload, newest first, tags merged in
GET /api/payloads/:hashThe full payload JSON
POST /api/payloads/:hash/tagsReplace a payload’s tags
POST /api/context/referenceSnapshot session context → store + tag reference

Payload content is also indexed for search. Filter type: context to search only captured context.


The store is listed under Settings → internals as Context payloads, with its size and file count, and can be cleared from there. Clearing removes captures only. Sessions are untouched, since threadle never writes to provider storage.