Composer predictions — ghost-text next-message suggestions for the DSH composer

[Amir-Bazylkhanov]

Composer predictions for DeepSeek Harness — ghost-text suggestions for your next message.

When an assistant turn ends, the plugin asks your configured model what you would most plausibly send next and paints it dimly in the empty composer. Tab inserts the whole suggestion into the draft (nothing is sent); Esc dismisses it. Suggestions never enter the draft, transcript, or history until you accept one.

Install

dsh plugin --profile <your-profile> add dsh-composer-prediction

Restart DSH afterwards (the host half composes at boot).

What it does

• One prediction per turn — deduped per session + turn, so it never re-asks for a turn it has already answered.
• Survives session switching — the offer is cached per session and restored instantly when you come back, with no new request.
• Never fights you — typing hides the offer; a stale response is dropped by a sequence guard, so it cannot replace or resurrect a newer one.
• No separate API key — predictions ride ctx.llm, i.e. your deployment's own provider route and credentials (deepseek-account, Kimi, …). Reasoning is pinned to the model's cheapest advertised effort.
• Settings → Predictions — enable/disable, provider/model overrides, delay, max length, context size. The stock Plugins page is read-only inventory in this build, so the plugin contributes its own settings.section page.
• Session-safe — on a session switch it waits for the chat store to swap (node-list change, 400 ms cap) before asking, so a request can never carry the previous session's transcript.

How it is built

• A bundle plugin: cordis.patch.yml inserts the host half; the browser half registers into conversation.input.overlay and settings.section.
• Host owns the transport (POST /api/composer-predict/rpc: config.get, config.set, predict, cancel) and persists config to its own JSON document in $DSH_HOME.
• The client bundle is generated by a small script (no bundler); tests drive the bundle in a VM plus the host RPC surface with stubbed providers.

Notes

• Tested against DSH 0.2.1-rc.2.
• The Settings nav glyph is drawn by masking the shell's own icon, because navIcon is hardcoded per section id — third-party sections otherwise get the gear. If the shell markup changes, the plugin silently falls back to the gear.
• MIT licensed; the nav glyph is CC0.

Links: GitHub · npm

Feedback very welcome — especially bad predictions, IME handling, and composer edge cases (attachments, very long drafts).

[xiaoshenming]

独立做了个几乎同款的（dsh-next-hint，今天发布），所以这篇对我很有参考价值 —— 两边结论惊人的一致：回合结束触发、复用 ctx.llm、推理档压到模型最低档、绝不上屏草稿。

有件事值得替用户说出来：两个别同时装。 都会往同一个输入框里画灰字，结果是两条重叠的建议 + 每轮两笔辅助调用。你的版本里有没有检测「已经有别的 ghost 在场」？我这边只判了 /、@ 菜单是否占用 Tab，没做跨插件检测。

接缝上也留个对照：我这边是浏览器侧判定（session.running 真→假）+ 宿主无状态的一次 POST，灰字是画在 [data-input-scroll] 里的绝对定位节点；你走 overlay 槽位 + 配置 RPC，对宿主改版大概比我这个 CSS 选择器更稳。

顺带问一句：输入法组字结束那一下，你是怎么避免灰字闪一下又消失的？这是我这版目前最不稳的地方。

[Amir-Bazylkhanov]

Hi, congrats on shipping dsh-next-hint — the convergence is almost eerie (turn-edge
trigger, ctx.llm, first advertised reasoning effort, 64-token cap, nothing in the
draft until Tab). On your question: no, mine has no cross-plugin detection either
— it only gates on its own offer and an empty draft, so with both installed we'd
get two ghosts and two calls, and since mine captures keydown at the document
level, one Tab could accept both if yours does the same. I'll add a "don't
install both" note to the README and market entry. One correction on the seam: I also decide in the browser from
useSession(running), and my host route is stateless — only the mount differs,
and it's only half safer, since I still measure [data-composer-input] and hide
its placeholder sibling. On IME: there is no compositionend code at all, and I
think that's why it doesn't flash — visibility is just draft === '' from the
composer's own store, which already reflects composition text, so by the time
compositionend fires the ghost is already gone. If yours still shows for a frame,
try suppressing while data-composer-composing is set on the editor root.

[xiaoshenming]

Thanks — this corrects two things on my side.

Seam. I had recorded "browser decides + stateless host route" as our difference. Fixed in our docs: you also decide in the browser (useSession(running)) and the predict route is stateless; the real differences are the mount point (overlay vs dock), the settings page/config RPC, the per-session cache and Esc.

IME. Adopted your suggestion. Our composer store can lag the composition by a tick, which is what produced the flash. 0.1.2 treats data-composer-composing on the editor root as "not requestable" and never paints while it is set, so the 350 ms settle window cannot paint into an active composition. The check lives in the same pure requestable() used by the request gate and the painted-hint validity check; composition end is re-evaluated by the next state publication.

Coexistence. Both READMEs warn already. Agreed on the double-Tab risk — a shared "ghost is present" attribute on the composer is probably the smallest cross-plugin signal; our node carries data-next-hint="ghost" if that helps.

0.1.2 is out (866ac58); release note on our thread. Thanks for the detailed answer.

[xiaoshenming]

Saw 0.7.7 — thanks for taking the coexistence contract seriously. Three notes from our side:

1. Shared marker. 0.1.3 now sets data-composer-ghost on the painted node only (it disappears when the ghost is hidden). [data-next-hint-anchor] is mounted for the whole session, so gating on it means "the plugin is present", not "a ghost is visible". If you ever want dynamic deference instead of permanent deference, [data-composer-ghost] (or [data-next-hint="ghost"]) is the per-offer signal.
2. One-way deference is intentional. We deliberately do not stand down when we see your ghost; if both sides deferred, a machine with both installed would show nothing. Your side pausing when this plugin is present gives a deterministic winner (ours). We documented that rule in both READMEs and RESEARCH.
3. IME. 0.1.2 adopted the data-composer-composing gate you suggested; it converged with your 0.7.7 change. Real-IME frame checks are still on our list.

0.1.3 is out (236a6dc); release note on our thread.