GeezerVison

The release connects Telegram to the session open in the terminal rather than always creating a separate session, with history recaps, session selection, mirrored activity and editable progress messages. It also attaches read images to native and Claude tool cards, adjusts idle compaction for newer OpenAI models and intermittent cache misses, and prevents bare native agents from inheriting nearby instructions or prompt/context hook rewrites. Pairing gains an optional sessionId, preserving directory-only requests and existing stored chat records.

Changes

Sequence diagram

sequenceDiagram
    participant T as Terminal
    participant D as Daemon
    participant B as Telegram bridge
    participant G as Telegram chat
    T->>D: Pair with directory and sessionId
    D-->>T: Expiring pairing code
    G->>B: /pair CODE
    B->>D: Read session history
    B-->>G: Recent turns
    B->>D: Subscribe and replay running turn
    T->>D: Submit prompt
    D-->>B: Session events
    B-->>G: Prompt, progress and answer
    G->>B: Prompt or approval response
    B->>D: Submit or resolve in shared session

• Files reviewed: 25 · 877 changed lines · estimated review effort 4/5, about 60 minutes
• Profile: normal · at most 8 inline comments
• Verification: every finding was checked again by a separate pass (2 candidates judged)
• Cost: 1,699,162 tokens in (1,529,728 from the provider's cache) · 7,314 out
• Readers: 10 files went to readers instead of the review pass whole: 10 code files by gpt-6-luna (the review pass gets their summaries and the hunks of their risk spots; 1 call, up to 3 at once, 34,761 tokens counted). Their summaries are hints, not findings. 15 code files no reader could read went to the review pass whole (the readers' share of the review's token cap is spent; the reader gave no usable answer for this file).

Performance (perf-attrib, base 92ec527 against head b3a2066)

perf-attrib: nota: no total rose; inside, binary.bytes +16416B

base 92ec5274126f61eb29017e2d56129b22bb021a52 (92ec5274) vs cand b3a2066572f04a98d843dee929dc1cfd48cd37a9 (b3a20665), median of 2 faux-engine session(s) per side; flagged = beyond the noise measured on 18 base-vs-base runs (x1.5).

JS object types that rose (count):

• tui.after.heap.type.Function: 44525 -> 44527 (+2)
• tui.rest.heap.type.Function: 44521 -> 44523 (+2)

JS heap bytes by constructor that rose:

• tui.rest.ctor.object:ModuleRecord.bytes: 5503002 -> 5504809 (+1807)
• tui.rest.ctor.native:Blob.bytes: 1741846 -> 1743266 (+1420)
• tui.rest.ctor.code:JSLexicalEnvironment.bytes: 1280016 -> 1280032 (+16)

Modules loaded at start: 230 -> 230, 4631481 -> 4633288 bytes of chunks; chunk sizes only in cand: [1009142, 715667, 275976, 251528, 110586, 20161, 2295], only in base: [1008597, 715646, 275922, 251346, 110300, 19508, 2229] (chunk names are hashes: the list says which changed in size, not by what name)

Reference (skill, 2026-11-03, real model): footprint 64 ready / 66 after / peak 80 MB, 2.6 KB per session. This run (faux engine, whole process tree): 54.8 / 57 / peak 73.5 MB, 2034 B per session.

Telegram pairing can now attach a chat to the terminal's current session rather than always creating a separate one. The bridge adds history, session selection, mirrored turns, approval handling and an editable progress message. Separately, native and Claude tool results expose image attachments, idle-compaction defaults account for newer GPT models, and bare native agents avoid instruction-file and prompt/context-hook injection.

Changes

Sequence diagram

sequenceDiagram
    participant T as Terminal
    participant D as Daemon
    participant B as Telegram bridge
    participant G as Telegram chat
    T->>D: Pair(directory, optional sessionId)
    D-->>T: Code and expiry
    G->>B: /pair CODE
    B->>D: Read session history
    B-->>G: Recent turns
    B->>D: Subscribe from running-turn start or log end
    D-->>B: Replay and live session events
    B-->>G: Prompt, progress, approvals and answer
    G->>B: Message or session selection
    B->>D: Submit message or change subscription

• Files reviewed: 25 · 921 changed lines · estimated review effort 4/5, about 60 minutes
• Profile: normal · at most 8 inline comments
• Verification: every finding was checked again by a separate pass (2 candidates judged)
• Cost: 1,690,945 tokens in (1,531,264 from the provider's cache) · 6,871 out
• Readers: 9 files went to readers instead of the review pass whole: 9 code files by gpt-6-luna (the review pass gets their summaries and the hunks of their risk spots; 1 call, up to 3 at once, 34,979 tokens counted). Their summaries are hints, not findings. 16 code files no reader could read went to the review pass whole (the readers' share of the review's token cap is spent; the reader gave no usable answer for this file).

Performance (perf-attrib, base 92ec527 against head a71641f)

perf-attrib: nota: no total rose; inside, binary.bytes +16416B

base 92ec5274126f61eb29017e2d56129b22bb021a52 (92ec5274) vs cand a71641f791f4bf2223b31ae73d0e99c16ca76fcf (a71641f7), median of 2 faux-engine session(s) per side; flagged = beyond the noise measured on 18 base-vs-base runs (x1.5).

JS object types that rose (count):

• tui.after.heap.type.Function: 44526 -> 44529 (+3)
• tui.rest.heap.type.Function: 44522 -> 44525 (+3)

JS heap bytes by constructor that rose:

• tui.rest.ctor.native:Blob.bytes: 1741846 -> 1743695 (+1849)
• tui.rest.ctor.object:ModuleRecord.bytes: 5503002 -> 5504845 (+1843)
• tui.rest.ctor.code:JSLexicalEnvironment.bytes: 1280016 -> 1280032 (+16)

Modules loaded at start: 230 -> 230, 4631481 -> 4633324 bytes of chunks; chunk sizes only in cand: [1009178, 715667, 275976, 251528, 110586, 20161, 2295], only in base: [1008597, 715646, 275922, 251346, 110300, 19508, 2229] (chunk names are hashes: the list says which changed in size, not by what name)

Reference (skill, 2026-11-03, real model): footprint 64 ready / 66 after / peak 80 MB, 2.6 KB per session. This run (faux engine, whole process tree): 54.7 / 57.3 / peak 73.4 MB, 2039 B per session.

Telegram submissions now request queued delivery so a concurrently starting terminal turn cannot consume them through steering. When a second chat joins an already-followed session, the bridge reads historical events in pages instead of rewinding the shared subscription cursor. Existing per-chat buffering and sequence checks order and deduplicate replayed and live events. The changelog identifies these fixes as beta.3 and updates the stable release's stated baseline.

Changes

Sequence diagram

sequenceDiagram
    participant Chat as Joining Telegram chat
    participant Bridge as Channel bridge
    participant Host as Channel host
    participant Client as Shared daemon client
    participant Daemon as Daemon
    Chat->>Bridge: Pair or switch session
    Bridge->>Host: watch(sessionId)
    Host->>Client: loadWindow and session.history
    Client->>Daemon: Read log end and running turn
    alt Session not yet followed
        Host->>Client: subscribe(sessionId, from)
        Client->>Daemon: Subscribe with replay
        Daemon-->>Bridge: Replayed and live events via client
    else Session already followed
        loop Until no more pages
            Host->>Client: loadAfter(sessionId, cursor, 200)
            Client->>Daemon: session.events
            Daemon-->>Host: Event page
            Host-->>Bridge: Replay through onEvent
        end
    end
    Bridge->>Bridge: Sort buffered events and deduplicate by sequence
    Bridge-->>Chat: Prompt, progress and approvals

• Files reviewed: 5 · 78 changed lines · estimated review effort 2/5, about 15 minutes
• Profile: normal · at most 8 inline comments
• Verification: the review pass raised no candidate findings, so no separate pass was needed
• Cost: 330,232 tokens in (280,064 from the provider's cache) · 2,113 out
• Readers: 5 code files no reader could read went to the review pass whole (the diff is small: one reader call costs more than the readers' share of this review's cap, so the review pass reads it).

Performance (perf-attrib, base 92ec527 against head c300179)

perf-attrib: nota: no total rose; inside, binary.bytes +16416B

base 92ec5274126f61eb29017e2d56129b22bb021a52 (92ec5274) vs cand c300179ff348858454908528dfad5b733a27a8d7 (c300179f), median of 2 faux-engine session(s) per side; flagged = beyond the noise measured on 18 base-vs-base runs (x1.5).

JS object types that rose (count):

• tui.ready.heap.type.FunctionExecutable: 14166 -> 14170 (+4)
• tui.ready.heap.type.UnlinkedFunctionExecutable: 14153 -> 14157 (+4)
• tui.after.heap.type.Function: 44526 -> 44529 (+3)
• tui.rest.heap.type.Function: 44522 -> 44525 (+3)

JS heap bytes by constructor that rose:

• tui.rest.ctor.object:ModuleRecord.bytes: 5503002 -> 5505259 (+2257)
• tui.rest.ctor.native:Blob.bytes: 1741846 -> 1744090 (+2244)
• tui.rest.ctor.code:JSLexicalEnvironment.bytes: 1280016 -> 1280032 (+16)
• tui.rest.ctor.code:JSModuleEnvironment.bytes: 104208 -> 104224 (+16)

Modules loaded at start: 230 -> 230, 4631481 -> 4633738 bytes of chunks; chunk sizes only in cand: [1009592, 715667, 275976, 251528, 110586, 20161, 2295], only in base: [1008597, 715646, 275922, 251346, 110300, 19508, 2229] (chunk names are hashes: the list says which changed in size, not by what name)

Reference (skill, 2026-11-03, real model): footprint 64 ready / 66 after / peak 80 MB, 2.6 KB per session. This run (faux engine, whole process tree): 55 / 57.6 / peak 73.5 MB, 2031 B per session.