Cursor Tab is the autocomplete inside the Cursor code editor: it predicts your next edit and applies it when you press Tab, powered by Cursor's own models. OpenCues works a different surface (any text input, not a code buffer) and inverts the interaction: nothing appears until you place a _ where you want the response.
The key differences
| Cursor Tab | OpenCues | |
|---|---|---|
| Surface | Code buffers in the Cursor editor | Any supported text input: Chrome fields, Claude Code, OpenCode, Gemini CLI, the terminal |
| Who initiates | The model; suggestions appear as you type | You; a _ summons a fill at the position you chose |
| Content | Code edits and completions | Prose, prompts, lookups, rewrites, live system values |
| Model | Cursor's bundled proprietary models | Bring your own: Cerebras, Groq, OpenAI, Anthropic, Gemini, OpenRouter, or local Ollama |
| Source | Proprietary product | Free, open source, open standard |
Prediction vs summoning
Cursor Tab's bet is that in code, the next edit is often predictable enough to guess, and when the guess is right, accepting it with one key is a genuine speedup. That bet works much less well in prose and prompts, where there is rarely one right continuation. OpenCues doesn't guess. Its passive layer (cues) only dims words that have alternatives, which you can ignore at zero cost, and everything generative waits for an explicit _. A wrong autocomplete costs you attention every time it fires; an unresolved blank just stays as a visible _.
Different jobs, honestly
If you write code in Cursor, Cursor Tab is built for exactly that and OpenCues does not compete with it: OpenCues has no code-editor integration and does not do next-edit prediction. The overlap is the text around your code work: commit messages, PR descriptions, prompts to coding agents, and everything you type outside the editor. There, OpenCues gives you lookups (capital of france _), rewrites (make this more formal _), live values (volume _), and word alternatives, on a model you choose.
The attention economics differ too
An always-on predictor charges you a small reading tax on every suggestion, right or wrong, and in a code editor that tax is usually worth paying because acceptance rates are high. In prose the same design reads as noise. OpenCues' division keeps the passive layer non-charging (a dim you can ignore never costs a decision) and moves all generation behind an explicit keystroke, so the only suggestions you evaluate are ones you asked for. Neither design is universally right; they're fitted to how predictable their respective content is.
They compose
A realistic setup is both: Cursor for code, OpenCues in your browser and terminal, and in the prompt box of whichever AI CLI you drive. Since OpenCues runs on your own key (Cerebras' free tier by default), adding it alongside a Cursor subscription costs nothing extra. The Copilot comparison covers the same boundary from the Copilot side.
Related: OpenCues vs autocomplete · What is a blank? · OpenCues in Claude Code · GitHub repo