후속 제안
Qwen Code는 다음에 입력할 내용을 예측하고 입력 영역에 플레이스홀더 텍스트로 표시할 수 있습니다. 이 기능은 LLM 호출을 사용하여 대화 컨텍스트를 분석하고 자연스러운 다음 단계 제안을 생성합니다.
이 기능은 CLI와 Web Shell 모두에서 엔드투엔드로 작동합니다. 생성은 자동이며 서버 측에서 처리됩니다. 각 턴이 정상적으로 완료될 때마다(데몬의 end_turn 정지 이유 — cancelled, refusal, max_tokens, max_turn_requests 턴은 제외) 데몬이 세션 스트림에서 제안을 내보냅니다(기본적으로 켜져 있으며, 옵트아웃하려면 ui.enableFollowupSuggestions를 false로 설정). Web Shell의 컴포저는 이미 useDaemonFollowupSuggestion hook이 연결되어 있어, 추가 호스트 연결 없이 제안이 렌더링되고 수락됩니다.
작동 방식
Qwen Code가 응답을 완료한 후, 짧은 지연(~300ms) 후에 제안이 입력 영역에 흐릿한 플레이스홀더 텍스트로 나타납니다. 예를 들어, 버그를 수정한 후 다음과 같이 표시될 수 있습니다:
> run the tests제안은 대화 기록을 모델에 전송하여 생성되며, 모델이 자연스럽게 다음에 입력할 내용을 예측합니다. 응답에 명시적 팁(예: Tip: type post comments to publish findings)이 포함되어 있으면, 제안된 동작이 자동으로 추출됩니다.
제안 수락
| 키 | 동작 |
|---|---|
Tab | 제안을 수락하고 입력에 채움 |
Enter | 제안을 수락하고 입력에 채움 |
Right Arrow | 제안을 수락하고 입력에 채움 |
| 아무 입력 | 제안을 해제하고 정상적으로 입력 |
Enter는 입력을 채우지만 제출하지 않으므로, 제안된 슬래시 명령어(예: /clear)를 수락해도 자동 실행되지 않습니다 — 두 번째 Enter로 직접 제출합니다.
제안이 나타나는 시기
대화형 CLI와 데몬은 이를 별도로 결정하며, 동일한 조건을 적용하지 않습니다. CLI는 각 렌더러에서 생성을 직접 제어하고, 데몬은 세션에 연결된 모든 클라이언트에 대해 서버 측에서 제어합니다.
양쪽 모두 다음 조건이 모두 필요합니다:
- 대화에서 최소 2번의 모델 턴이 발생했을 때
- 승인 모드가
plan으로 설정되지 않았을 때 - 기능이 활성화되어 있을 때 (기본적으로 켜져 있음 —
ui.enableFollowupSuggestions를false로 설정하면 끄기)
대화형 CLI는 추가로 다음을 요구합니다:
- 세션이 대화형이어야 함 — CLI는 자체 비대화형 또는 SDK 모드에서 제안을 생성하지 않음
- 모델이 응답을 완료했을 때 (스트리밍 중이 아님)
- 가장 최근 응답에 오류가 없을 때
- 보류 중인 확인 대화 상자가 없을 때 (예: 셸 확인, 권한). 한 렌더러는 해당 상태를 직접 읽지만, 다른 렌더러는 자체 보류 중인 도구 호출을 기준으로 게이트를 적용하여 턴 중간에 열린 셸 대화 상자를 볼 수 없으므로 그 뒤에서 제안이 생성될 수 있습니다. 이 경우 아무것도 표시되지 않습니다. 대화 상자가 떠 있는 동안 컴포저가 마운트 해제되기 때문입니다. 따라서 비용은 해당 턴의 생성 호출뿐이며, 실수로 실행할 수 있는 제안이 아닙니다.
데몬은 추가로 다음을 요구합니다:
- 턴이 정상적으로 종료되었어야 함. 즉, 정지 이유가
end_turn이어야 함 — 취소, 거부, 잘린 턴은 제안을 받지 못함 - 자동 턴이 todo 정지 가드에 의해 보류 중이지 않으며, 대기 중인 큐에 담긴 프롬프트가 없음
- 대화 기록의 가장 최근 항목이 모델 응답임
데몬 측 생성은 세션에 연결된 모든 클라이언트에 대해 발생하므로, 결과를 렌더링할 수 없는 클라이언트에 대해서도 발생합니다. 이러한 클라이언트(위 CLI의 자체 비대화형 모드와는 다른, 데몬 세션의 헤드리스 또는 SDK 소비자)는 ui.enableFollowupSuggestions를 false로 설정하여 버려지는 출력에 대해 턴당 LLM 비용을 지불하지 않아야 합니다.
제안은 다음 상황에서 자동으로 해제됩니다:
- 입력을 시작할 때
- 새 모델 턴이 시작될 때
- 제안이 수락될 때
Fast 모델
기본적으로 제안은 메인 대화와 같은 모델을 사용합니다. 더 낮은 지연의 제안을 위해 전용 fast 모델을 구성하세요:
명령어를 통해
/model --fast qwen3-coder-flash또는 /model --fast(모델 이름 없이)를 사용하여 선택 대화 상자를 엽니다.
settings.json을 통해
{
"fastModel": "qwen3-coder-flash"
}fast 모델은 프롬프트 제안과 투기적 실행에 사용됩니다. 구성되지 않으면 메인 대화 모델이 폴백으로 사용됩니다.
비용 참고: fast 모델은 지연을 낮추지만 항상 비용을 낮추는 것은 아닙니다. 제안 생성은 대화의 프리픽스 캐시를 재사용합니다(
ui.enableCacheSharing을 통해, 기본적으로 켜져 있음) — 하지만 프리픽스 캐시는 모델별입니다.fastModel을 다른 모델로 지정하면 별도의 캐시로 포크되므로 전체 대화 기록이 fast 모델에서 캐시되지 않은 입력으로 다시 청구됩니다. 긴 대화에서는 기본값(메인 모델 + 공유 캐시)이 fast 모델보다 더 저렴할 수 있습니다. 대부분의 기록이 할인된 캐시 비율로 청구되기 때문입니다. 턴당 비용보다 지연이 더 중요할 때fastModel을 설정하세요.
생각/추론 모드는 모든 백그라운드 작업(제안 생성 및 투기)에 대해 자동으로 비활성화됩니다. 메인 모델의 생각 구성과 무관합니다. 이러한 작업에 필요하지 않은 내부 추론에 토큰을 낭비하지 않기 위함입니다.
구성
이 설정은 settings.json에서 구성할 수 있습니다:
| 설정 | 타입 | 기본값 | 설명 |
|---|---|---|---|
ui.enableFollowupSuggestions | boolean | true | 후속 제안을 활성화 또는 비활성화 |
ui.enableCacheSharing | boolean | true | 비용을 줄이기 위해 캐시 인식 포크 쿼리 사용 (실험적) |
ui.enableSpeculation | boolean | false | 제출 전 제안을 투기적으로 실행 (실험적) |
fastModel | string | "" | 프롬프트 제안 및 투기적 실행에 사용할 모델 |
예시
{
"fastModel": "qwen3-coder-flash",
"ui": {
"enableFollowupSuggestions": true,
"enableCacheSharing": true
}
}모니터링
제안 모델 사용량은 /stats 출력에 나타나며, fast 모델이 제안 생성에 소비한 토큰을 보여줍니다.
fast 모델은 /about 출력의 “Fast Model” 아래에도 표시됩니다.
제안 품질
제안은 유용성을 보장하기 위해 품질 필터를 거칩니다:
- 2-12단어(CJK: 2-30자), 총 100자 이하
- 평가적일 수 없음 (“looks good”, “thanks”)
- AI 목소리를 사용할 수 없음 (“Let me…”, “I’ll…”)
- 여러 문장이거나 포맷(마크다운, 줄바꿈)을 포함할 수 없음
- 메타 코멘트일 수 없음 (“nothing to suggest”, “silence”)
- 오류 메시지나 접두사 레이블일 수 없음 (“Suggestion: …”)
- 한 단어 제안은 일반 명령어만 허용 (yes, commit, push 등)
- 슬래시 명령어(예:
/commit)는 항상 한 단어 제안으로 허용됨