Vidbyte

Documentation

Durable designHarnessesRoute-accurate reference

Research threads are meant to persist

A thread holds durable source identity and artifacts across multiple runs. Each new prompt gets its own bounded run envelope while the collection keeps growing in a way that remains recoverable and inspectable.

Manage keys
Stable public contract

Thread

The collection

Owns the durable relationship among questions, sources, and artifacts.

Run

One prompt

Captures one asynchronous execution, its progress, usage, and terminal state.

Context

Bounded

The next run sees an intentional working set, not every old artifact body.

1. A thread contains many independent runs

Starting Research creates a durable thread and its first run. Appending a prompt creates another run in the same owned thread, which lets you investigate a new angle without throwing away the original evidence collection.

The run is the durable execution envelope for progress and usage. The thread is the product-level collection that preserves source identity and completed artifacts across those runs.

Flow

Thread model

Thread
├─ Run 1: map the question
├─ Run 2: investigate a follow-up
└─ Run 3: resume unfinished source work

Sources and ready artifacts remain in the thread.

2. Persistence does not mean an ever-growing prompt

A follow-up run uses a bounded visited-source ledger to avoid selecting URLs the thread already knows. It can also receive up to 15 explicitly selected artifact references when a user deliberately wants old evidence to guide new research.

Prior artifact bodies are deliberately not loaded automatically. This keeps a thread with a large corpus from becoming increasingly slow, expensive, or vulnerable to unreviewed old content controlling the next model call.

Persistent product state and model-visible context are separate on purpose: durable artifacts stay available to the user, while context enters only through a bounded, explicit policy.

3. Partial work remains useful

Completed artifacts are durable and idempotent, so continuation does not regenerate finished source work.

Partial, failed, and credit-exhausted runs can be continued under the same run identity.

A run checkpoints through durable workflow steps, so retries recover product-visible membership rather than relying on process memory.

A credit cap pauses before the next expensive operation; saved work remains available when capacity is approved later.