GeezerVison

A new async-generator wrapper retries a completion up to six times when the provider throws RetryableProviderError before emitting text. It uses the existing backoff schedule, honors longer provider retry-after delays, and stops waiting when cancelled. The daemon applies this wrapper in completeWithUsage, leaving provider routing, model guards, ordinary engine-turn retries, and response parsing unchanged.

Changes

Sequence diagram

sequenceDiagram
    participant Caller as Auxiliary caller
    participant Complete as completeWithUsage
    participant Retry as retryingCompletion
    participant Provider as Routed provider
    Caller->>Complete: Request completion with AbortSignal
    Complete->>Retry: Supply provider.stream attempt
    loop Initial attempt and up to six retries
        Retry->>Provider: stream(request)
        alt Retryable failure before text, retries remain
            Provider-->>Retry: RetryableProviderError
            Retry->>Retry: Abort-aware backoff / retry-after wait
        else Successful stream
            Provider-->>Retry: Model events
            Retry-->>Complete: Forward events
        else Non-retryable failure, text already emitted, or cancelled
            Retry-->>Complete: Propagate error
        end
    end
    Complete-->>Caller: Text and usage, or error

• Files reviewed: 4 · 113 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: 194,266 tokens in (163,712 from the provider's cache) · 2,031 out
• Readers: 4 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).
• Stacked on #131: only this pull request's own commits since #131's head 0201e4d.

Performance (perf-attrib, base 0201e4d against head 43a0917)

perf-attrib: igual: nothing above the measured noise

base 0201e4d5b29977b5ce181530f2cf9c2be5631efd (0201e4d5) vs cand 43a091792e8326c6f060a3272eaf65bad31d5590 (43a09179, cached build), 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.SQLStatement: 79 -> 88 (+9)
• tui.after.heap.type.Object: 38152 -> 38158 (+6)
• tui.ready.heap.type.FunctionExecutable: 14162 -> 14166 (+4)
• tui.ready.heap.type.UnlinkedFunctionExecutable: 14149 -> 14153 (+4)

JS heap bytes by constructor that rose:

• tui.rest.ctor.object:ModuleRecord.bytes: 5502260 -> 5502808 (+548)
• tui.rest.ctor.native:Blob.bytes: 1738955 -> 1739095 (+140)
• tui.rest.ctor.code:JSModuleEnvironment.bytes: 104144 -> 104176 (+32)

Modules loaded at start: 230 -> 230, 4630739 -> 4631287 bytes of chunks; chunk sizes only in cand: [1007138], only in base: [1006590] (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.9 / 56.8 / peak 73.4 MB, 2055 B per session.