OpenCode connector

OpenCode connector

Supported schema

The connector targets current OpenCode SQLite storage:

session(id, title, directory, time_created, ...)
message(id, session_id, time_created, data JSON, ...)
part(id, message_id, session_id, time_created, data JSON, ...)

Message role is stored inside message.data. Content is stored in part.data; current databases do not embed parts inside message.data.

The source is opened as:

sqlite3.connect(f"file:{path}?mode=ro", uri=True)

No source table is created, altered, vacuumed, or indexed.

Session discovery

Sessions are grouped by session.id, ordered oldest-first by (time_created, id), and annotated with message counts. --limit and --offset apply after ordering. Oldest-first is an operational policy, not a Cognee requirement: a partial run remains a coherent historical prefix while timestamps in the notes carry the actual event time.

Because discovery occurs at process launch, sessions created later are not part of that run. Run the connector again or use Cognee's live OpenCode plugin for ongoing capture.

Transcript reconstruction

Parts are joined to their parent message, labeled with the role from message.data, and ordered by message creation time and part creation time. Supported part types:

Type	Treatment
text	retained, bounded per part
reasoning	retained only as a short hint; final output must not expose chain-of-thought
tool	tool name + bounded input/output
step-start, step-finish	discarded

The connector currently labels text parts conservatively because source variants differ. Future connector revisions should explicitly join message role into each part to improve speaker attribution.

Compaction

Default transcript budget is 18,000 characters:

• first 6,000 characters: problem statement and context;
• remaining 12,000 characters from the end: decisions and outcome;
• middle replaced by a truncation marker.

Tool outputs are capped independently so command logs cannot consume the entire budget.

Distillation contract

The LLM retains evidence of work, including:

• tasks attempted and projects/systems touched;
• investigations, research, findings, and artifacts;
• implementation details and current state;
• decisions and rationale;
• reusable patterns and workflows;
• gotchas and successful fixes;
• error causes and solutions;
• failed approaches and follow-ups;
• project facts, exact paths, symbols, commands, and errors.

Expected Markdown sections are What Was Worked On, Outcome / Current State, Decisions & Rationale, Findings & Learnings, Problems & Fixes, Files, Systems & Commands, and Follow-ups; empty sections may be omitted. Exact JUNK is reserved for empty handshakes, availability checks, or sessions with no meaningful subject, activity, finding, artifact, or outcome.

The model input is persisted before inference. The resulting note receives a deterministic provenance header containing source, session ID, start time, and project directory. This keeps the generated note auditable without indexing the much larger transcript directly.

Why not index transcripts directly?

The direct path was tested end to end. Conversation-only transcripts were 4.2x larger, took 3.2x longer to Cognify, and answered only 3 of 8 factual checks fully correctly versus 8 of 8 for distilled notes. Including tool activity made Cognify roughly 38x slower. Distillation is therefore session-level aggregation across prompts, tool evidence, failures, and outcomes rather than cosmetic rewriting. The source database and var/transcripts/ remain available for verification.

Known limits

• No incremental timestamp watermark yet; distillation resume keys by immutable session ID.
• Session edits after a note is distilled are not detected automatically.
• Regex scrubbing is defense-in-depth, not a complete DLP system.
• Attachments and image content are not reconstructed.