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.
What the note tells you
When your caret enters a dimmed span, a small note appears under it with one consistent vocabulary. An emoji leads a notification, something flagged for you to look at: ⚠ a factual or scheduling conflict, ❓ a clarifying question, ✍️ a spelling fix. A cycleable improvement, on the other hand, carries no emoji and just a number, the count of options remaining as you cycle. A (underscore to cycle) hint rides along until your first cycle, then drops away, and spelling and rewrite notes list the options you can cycle to so you can see where a press of _ lands before you commit.
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 (one cue source must not contaminate another), 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