An inline cue is a system-to-user signal layered directly onto the text you are typing. The system surfaces information about a word (a tip, alternatives, a correction) in context, while you work, without asking you to leave the prompt. In OpenCues the signal is a dim: a word (or a whole sentence) with something to offer renders slightly dimmed, and everything else follows from three keyboard primitives.
Dim, navigate, cycle
The dim is the entry point, and it charges you nothing: a signal you can completely ignore. If you engage, Ctrl+Alt+←/→ moves a selection indicator between dimmed words (your cursor stays where it was, so you can browse without losing your typing position), the secondary display shows the selected cue's tip, and Ctrl+Alt+↑/↓ cycles the word's alternatives into place. No popup, no menu; the substitution happens in the text itself, and editing a word clears its cue.
The design constraints that produced it
The Inline Cues essay lists the constraints the mechanism had to satisfy, and they explain why it looks the way it does: no text reflow (moving words breaks flow and procedural memory), no interrupting typing (no popups, no focus theft), no overloading bold or italic (those already carry meaning), universality (any text input on any platform), ignorable by construction, cross-domain isolation (a legal cue source must not contaminate a medical one), and a selection indicator decoupled from the cursor. Those constraints rule out autocomplete dropdowns, hover tooltips, and command palettes; what survives is a colour-channel signal layered on existing text. That different-modality property is the modality rule at work.
Two kinds of cue source
| Kind | How it resolves | Latency |
|---|---|---|
| Local (static tips) | Dictionary of word → tip + alternatives, loaded at boot | Roughly zero |
| Remote (LLM) | Domain prompt fired for words matching a regex or keyword list | Typically sub-second on fast providers |
Both are defined the same way: a CUE.md file dropped into ~/.cues/cues/<name>/, discovered by folder, hot-reloaded on the next keystroke.
Why the term matters beyond OpenCues
Inline cues are one half of a two-direction model. The cue direction is system to user; inline prompting (the _) is user to system. And because a cue ships as a config file rather than documentation, the same mechanism delivers continuous onboarding: when a tool's feature changes, the cue updates with it, and every user picks it up on their next keystroke.
Related: What is a cue? · Continuous onboarding · The modality rule · GitHub repo