In this article
Cherry Studio’s Local Models panel manages auxiliary models; a conversational local generator is selected through Model Provider.
In Cherry Studio, a local conversation model is configured through Model Provider settings. Settings → Local Models refers to built-in auxiliary models, so downloading an entry there does not by itself configure the model that answers your chat.
The concrete application boundary
The current documentation separates provider configuration from the Local Models panel. Provider types include local inference frameworks such as Ollama and LM Studio. The auxiliary panel instead manages small embedding and OCR models that run locally after download. Those capabilities serve other application functions, not a general conversational model selection. This distinction explains a common onboarding error: the user sees Ready in Local Models and expects chat generation to work. Readiness applies to that auxiliary component. Do not delete or reinstall it to repair a missing conversation provider. Configure the generator through the actual provider entry and select its chat model independently (Cherry Studio Local Models).
A practical route
Open Settings → Model Provider and select the local inference provider matching the existing runtime. Enter its connection details using the dedicated provider guidance. Sync models, add the intended chat entry, and optionally use Model Check to test a conversation model. Then select that model for a plain chat. Leave knowledge-base and OCR features out of the first task so that their settings do not obscure whether generation itself is working (Cherry Studio Model Service Configuration).
A worked example
A user downloads an auxiliary model, sees Ready, but receives no answer in a new conversation. The corrective path is to inspect Model Provider, connect the already running Ollama or LM Studio service, and choose its chat model. Ask it to rewrite a fictional paragraph without adding facts. Check that the response comes from the selected conversational provider rather than treating the auxiliary download as the generator.
| Check | Record |
|---|---|
| Conversation | The provider and chat model selected for the actual answer. |
| Auxiliary state | Any Ready status in Local Models, recorded only for its own component. |
| Test input | A fictional paragraph requiring no document indexing or image recognition. |
Reading the failure correctly
A provider template is not proof that its external runtime is running. Conversely, an unavailable auxiliary model on an unsupported platform does not prove that every external conversation connection is unavailable. Diagnose the component used by the failing operation. Also distinguish ordinary chat from Cherry Agent, whose documented provider requirements are not identical (Cherry Studio documentation).
What completes the check
The setup is complete when the chosen conversation model answers the text task and its provider is identifiable. Keep auxiliary model readiness as a separate record instead of using one local-model label for unrelated application functions. Do not change an unrelated auxiliary download while testing the selected conversation provider.
Related background: llama.cpp server: a local API from a GGUF model, VRAM for LLMs: why model size is only part of the calculation.