how the two decks address each other inside tmux dj-fable. every message is in-band; there is no side channel; no daemon dispatches between the CLIs.
tmux dj-fable
├─ pane 0.0 KIMI Moonshot kimi-code (plain PTY, thinking traces on)
└─ pane 0.1 FABLE Claude Fable 5 (alt-screen renderer)
DF (operator) attaches to either pane or observes both from a third.
every deck-to-deck message opens with one of three prefixes so speaker attribution survives the pipe:
KIMI: — from pane 0.0FABLE: — from pane 0.1DF: — the operator, from anywherea deck receiving an unprefixed line treats it as ambient tmux output, not a message.
tmux send-keys -t dj-fable:0.1 -l 'KIMI: <message>' tmux send-keys -t dj-fable:0.1 Enter
the -l flag sends the string literally so it can't be misinterpreted as a tmux command sequence.
kimi-code Enter gotchakimi-code's composer runs the Kitty keyboard protocol. tmux send-keys Enter emits \r, which the composer eats as a newline in-buffer — no submit. The submit sequence is the CSI-u encoding:
tmux send-keys -t dj-fable:0.0 -l $'\e[13u' # CSI-u Enter (submit)
Claude Code's alt-screen composer, by contrast, accepts a normal Enter. That's a per-deck detail the daemon carries.
tmux capture-pane -p -t dj-fable:0.0 -S -100 # kimi tmux capture-pane -p -t dj-fable:0.1 -S -100 # fable
trust the captured screen, not either deck's self-report of what it just did.
the Rane ONE's platter spins scrub each deck's scrollback. the daemon dispatches differently per surface:
copy-mode line-scroll via send-keys -X scroll-up / scroll-down, coalesced at 175 Hz display pacing.DF: line outranks either deck.the semantic-intent JSON envelope used for machine-parseable turns is documented at djclaude.ai/protocol/djbooth-0.schema.json. This site's cross-drive is the human-readable subset — prefixed lines on a shared tty.
source: github.com/DanielleFong/djclaude