sendmessage SENDMESS-1

EPIC: is native SendMessage faster and cheaper (tokens/turns) than the hub?

Backlog high plpm-llmmsgsrv-cc

Elazar 2026-08-22: run more tests, main question is whether native cross-session messaging is faster and cheaper in tokens and turns than llmmsg-srv. Prior measurement (memory native-cross-session-messaging-verdict): works same-host over UDS, buffer-and-drain not interrupt, no tag/kind/re/id, no messages row, cannot reach aro:/scrp-*/Elazar/off-host, ~1.5s idle-wake edge that LLMMSG_POLL_MS=1000 mostly closes. That measured LATENCY and REACH only - it did NOT measure token cost or turn count, which is the open question. Children cover the measurements.

Sub-tickets — 4/5 done

Decision: adopt / shim-side dual-delivery / reject - written with the numbers

SENDMESS-6 Backlog high

plpm-llmmsgsrv-cc

Measure: tokens per delivery, native vs hub (same message, same pair, N=10 each way)

SENDMESS-2 Done high

plpm-llmmsgsrv-cc

Measure: turns per exchange, native vs hub (send -> receive -> reply -> receive)

SENDMESS-3 Done high

plpm-llmmsgsrv-cc

Measure: end-to-end latency idle vs busy receiver, native vs hub, with LLMMSG_POLL_MS=1000 as a third arm

SENDMESS-4 Done

plpm-llmmsgsrv-cc

Measure: context-window cost of having native messaging enabled at all (schema/idle overhead)

SENDMESS-5 Done

plpm-llmmsgsrv-cc

+ Add sub-ticket

Activity

wi-cli-venus created · 7w ago
wi-cli-venus commented · 7w ago

External research 2026-08-22 (docs, HN 72 comments, GitHub issues 84945/86014/86069/86088/78706/29086, 5 blogs). NO published token/turn benchmarks anywhere - every source quotes the docs line 'counts toward usage like a prompt you typed'. Reliability: 4 open bugs all silent-failure class (socket fails to bind -> one-way channel; send reports success, 0/4 delivered; Windows messages land in composer never submitted; idle-turn regression 980s). HN thread is ~90% about compaction/handoff, not the feature. No field data on cost. Our SENDMESS-2/3 would be first measurement.
wi-cli-venus commented · 7w ago

SENDMESS-2/3 MEASURED 2026-08-22 02:28-02:35, pm-llmmsgsrv-cc -> coder-llmmsgsrv-cc, same host (venus), receiver idle, N=10 per arm, 20/20 delivered, 1 receiver turn per probe both arms (receiver made exactly 10 hub sends + 10 SendMessage, 1 stray ToolSearch to load the SendMessage schema). LATENCY send->inbound-visible-at-receiver: hub med 1.71s (0.09-2.96, = shim 3s poll), native med 0.09s. RECEIVER per probe: context growth hub 559 tok / native 521; uncached input hub 204 / native 288; output hub 142 / native 88. SENDER per probe: context growth hub 871 / native 696; uncached input hub 480 / native 494; output hub 120 / native 88. TURNS: identical - 1 inbound-triggered turn + 1 reply tool call each side, no drain call needed on either (hub inbound arrives as <channel> notification, not via read_unread). Net: native saves ~1.6s latency and ~100-175 tokens/message (~15-20%), the saving is the shorter tool-result + wrapper, not fewer turns. Hub cost is dominated by the same thing native cost is: the model turn itself.