Followup Suggestions

Qwen Code can predict what you want to type next and show it as placeholder text in the input area. This feature uses an LLM call to analyze the conversation context and generate a natural next step suggestion.

This feature works end-to-end in both the CLI and Web Shell. Generation is automatic and server-side: after each cleanly completed turn (the daemon’s end_turn stop reason — a cancelled, refusal, max_tokens, or max_turn_requests turn gets none) the daemon emits the suggestion on the session stream (on by default; set ui.enableFollowupSuggestions to false to opt out), and Web Shell’s composer already wires the useDaemonFollowupSuggestion hook, so suggestions render and accept with no additional host wiring.

How It Works

After Qwen Code finishes responding, a suggestion appears as dimmed placeholder text in the input area after a short delay (~300ms). For example, after fixing a bug, you might see:

> run the tests

The suggestion is generated by sending the conversation history to the model, which predicts what you would naturally type next. If the response contains an explicit tip (e.g., Tip: type post comments to publish findings), the suggested action is extracted automatically.

Accepting Suggestions

Enter fills the input rather than submitting, so accepting a suggested slash command (e.g. /clear) never auto-executes — you submit it yourself with a second Enter.

When Suggestions Appear

The interactive CLI and the daemon decide this separately, and they do not apply the same conditions: the CLI gates generation itself, while the daemon gates it server-side for every client attached to the session.

Both sides require all of the following:

• At least 2 model turns have occurred in the conversation
• The approval mode is not set to plan
• The feature is enabled (on by default — set ui.enableFollowupSuggestions to false to turn it off)

The interactive CLI additionally requires:

• The session is interactive — the CLI never generates suggestions in its own non-interactive or SDK mode
• The model has completed its response (not during streaming)
• There are no errors in the most recent response
• No confirmation dialogs are pending (e.g., shell confirmation, permissions). One renderer reads that state directly; the other gates on its own pending tool calls and cannot see a shell dialog opened mid-turn, so a suggestion can still be generated behind one. Nothing is displayed in that case — the composer is unmounted while the dialog is up — so what it costs is that turn’s generation call, not a suggestion you can act on by mistake.

The daemon additionally requires:

• The turn ended cleanly, meaning its stop reason is end_turn — a cancelled, refused, or truncated turn gets no suggestion
• Automatic turns are not being held by the todo stop guard, and no queued prompt is waiting to run
• The most recent entry in the conversation history is a model response

Because daemon-side generation happens for every client attached to the session, it also happens for clients that cannot render the result. Such a client — a headless or SDK consumer of a daemon session, which is not the CLI’s own non-interactive mode above — should set ui.enableFollowupSuggestions to false to avoid paying the per-turn LLM cost for output it discards.

Suggestions are automatically dismissed when:

• You start typing
• A new model turn begins
• The suggestion is accepted

Fast Model

By default, suggestions use the same model as your main conversation. For lower-latency suggestions, configure a dedicated fast model:

Via command

/model --fast qwen3-coder-flash

Or use /model --fast (without a model name) to open a selection dialog.

Via settings.json

{
  "fastModel": "qwen3-coder-flash"
}

The fast model is used for prompt suggestions and speculative execution. When not configured, the main conversation model is used as fallback.

Cost note: A fast model lowers latency, but it does not always lower cost. Suggestion generation reuses your conversation’s prefix cache (via ui.enableCacheSharing, on by default) — but a prefix cache is per-model. Pointing fastModel at a different model forks to a separate cache, so the whole conversation history is re-billed as uncached input on the fast model. On long conversations, the default (main model + shared cache) can be cheaper than a fast model, since most of the history is billed at the discounted cached rate. Set fastModel when latency matters more than per-turn cost.

Thinking/reasoning mode is automatically disabled for all background tasks (suggestion generation and speculation), regardless of your main model’s thinking configuration. This avoids wasting tokens on internal reasoning that isn’t needed for these tasks.

Configuration

These settings can be configured in settings.json:

Example

{
  "fastModel": "qwen3-coder-flash",
  "ui": {
    "enableFollowupSuggestions": true,
    "enableCacheSharing": true
  }
}

Monitoring

Suggestion model usage appears in /stats output, showing tokens consumed by the fast model for suggestion generation.

The fast model is also shown in /about output under “Fast Model”.

Suggestion Quality

Suggestions go through quality filters to ensure they are useful:

• Must be 2-12 words (CJK: 2-30 characters), under 100 characters total
• Cannot be evaluative (“looks good”, “thanks”)
• Cannot use AI voice (“Let me…”, “I’ll…”)
• Cannot be multiple sentences or contain formatting (markdown, newlines)
• Cannot be meta-commentary (“nothing to suggest”, “silence”)
• Cannot be error messages or prefixed labels (“Suggestion: …”)
• Single-word suggestions are only allowed for common commands (yes, commit, push, etc.)
• Slash commands (e.g., /commit) are always allowed as single-word suggestions