In this article
Continue autocomplete needs its own role and invocation path; debouncing and output filtering can also explain absent visible suggestions.
Continue chat can work while autocomplete remains unconfigured or produces no visible suggestion. Check the active autocomplete role and invocation path before reconnecting a chat model that already answers correctly.
The concrete application boundary
The current YAML model reference defines roles separately. The default set includes chat, edit, apply, and summarize, while autocomplete must be assigned for that job. A model’s display name, provider, and actual runtime identifier also have separate purposes. After configuration, the completion pipeline still differs from chat: it waits during rapid typing, can reuse cached completions, gathers context, and post-processes responses. The documentation describes discarding some poor suggestions, so the absence of visible text does not always prove no model request happened. Conversely, a working chat panel cannot establish that completion used the intended model. Diagnose configuration and presentation as separate stages (Continue autocomplete pipeline).
A practical route
Open the active config.yaml, locate the intended local model definition, and inspect roles for autocomplete. Confirm the runtime model value against the actual installed model. Reload config in Continue’s configuration selector and inspect the autocomplete selection and enabled state. Open a simple source file, place the cursor where a short continuation is appropriate, type a partial statement, then pause. Compare this controlled attempt with the working chat rather than repeatedly sending chat prompts and expecting them to enable inline behavior (Continue config.yaml reference).
A worked example
A developer configured a local chat model but left its roles at the defaults. The chat explains a function successfully; typing a new helper produces no completion. Add an appropriate autocomplete role or a separate completion model definition, reload the selected configuration, and retry the small source example. Keep the original chat selection unchanged so the repair has a clear application-level cause.
| Check | Record |
|---|---|
| Configuration | The active YAML and explicit autocomplete assignment. |
| Invocation | The cursor location and paused partial statement used for the trial. |
| Observation | Visible suggestion, relevant request evidence, or a distinguishable configuration error. |
Reading the failure correctly
A chat-oriented local model is not automatically a suitable completion model. Special tokens, repeated output, or poor formatting may be filtered instead of displayed. A different selected configuration can also make an edit appear ineffective. Inspect these conditions before changing global runtime settings or assuming every missing suggestion is a network problem (Continue model roles).
What completes the check
The useful repair separates an assigned completion role from actual inline behavior. Keep a minimal source example that can be retried after extension updates; do not describe one successful chat response as complete autocomplete integration. Keep the cursor location unchanged between the compared attempts.
Related background: Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.