Skip to content

2.2 chat

Jump to bottom
wiki[bot] edited this page Aug 2, 2026 · 3 revisions

2.2. The Chat Experience

The Chat area is the reason 3F exists: a complete, streaming, multi-modal conversation UI that shows its work. Component root: src/components/chat/.

Layout

┌─ conversation-header ─ model, session, conversation controls ─┐
│                                                               │
│  exchange-list                    ┌─ right-panel ────────────┐│
│   ├ chat-exchange (user)          │  session metadata,       ││
│   ├ chat-exchange (assistant)     │  attachments, tools      ││
│   │   └ exchange-content          │                          ││
│   │       ├ reasoning-area        └──────────────────────────┘│
│   │       └ assistant-response (structured)                   │
│   └ pending-indicator (streaming state)                       │
├─ prompt-action-bar ─ input, images, submit, cancel, think ────┤
└─ toolbar · floating-player (media) ────────────────────────────┘

Exchanges

An exchange is one user request + the assistant's full response cycle, keyed by requestId and persisted per session/conversation (HarnessConversation.content). The exchange-list renders the history; each chat-exchange shows:

  • the user prompt with its attached images;
  • the assistant-response, rendered from the harness's structured schemas — comparisons, describe/OCR blocks, summaries, articles, product/news cards, image/video galleries render as UI elements, not raw prose; foreign-language articles/videos appear in an international coverage aside so they augment rather than displace primary-language content;
  • the original behind a toggle for exchanges whose visible text came from compaction.

Reasoning areas

Models with thinking support stream their chain-of-thought as a distinct phase. The reasoning-area renders it collapsed-but-inspectable inside the exchange — you can watch the model think without letting it dominate the answer. use-chat-think wires the think parameter so thinking is a per-conversation choice.

Streaming UX

  • Tokens land on the Socket.IO room as text/stream payloads (see 1.4) and append live; pending-indicator reflects the harness phase rather than a spinner-of-doom.
  • use-frozen-read-snapshot + use-read-tracker freeze the reading viewport while content grows, and release it precisely — no scroll fights mid-stream.
  • Cancel posts /api/v1/harness/cancel and waits for cancel_result — in-flight generation actually stops (see 1.2).

Context management — compaction

When history grows past the model's context budget, the dashboard offers Compact: it sends the accumulated exchanges to POST /api/v1/harness/compact; the server summarises them (emitted as compacting payloads) and the UI folds the thread into the compressed continuation with the original retained. Long research sessions stay in one conversation instead of being restarted.

Input

The prompt action bar handles multimodal input: text plus one or more images (validated before upload), numCtx awareness (use-chat-context-size shows how much of the window the current thread consumes — the feature many proprietary chats hide), model picker fed by the live catalogue, and submit/cancel that maps 1:1 to the harness lifecycle.

SysCtl, DLQ, PProc interplay

Chat is not isolated: model + preprocessing + provider overrides configured in SysCtl apply to the next request; failed jobs surface in DLQ where they can be repaired and re-instated; PProc previews exactly which image variants the server will compute from your uploads.

Debuggability

components/debug and the debug store mirror the raw socket/API traffic. Every exchange can be traced client-side from submission through room events to the persisted record — the dashboard treats observability as a user feature.

Clone this wiki locally