In this article
Goose’s local provider supplies generation, while extensions expose tools; a model without tool calling is limited to chat.
Goose can use a local model through documented Ollama or LM Studio providers. For a first task, configure that provider explicitly and treat extensions as a separate capability layer rather than assuming that a successful chat enables every tool.
The concrete application boundary
The current documentation is hosted at goose-docs.ai, and the official repository is under aaif-goose. The provider guide lists local paths and notes that Goose relies heavily on tool calling. A model without tool calling is limited to chat completion and requires extensions to be disabled. Therefore begin with a model whose supported behavior matches the task, not merely a file that loads. An extension may expose file or command actions, while the provider supplies generation. Keeping those responsibilities separate is essential when an answer works but an action fails. A local provider also does not make a separately connected external tool offline (Goose extension guide).
A practical route
In Goose Desktop open the sidebar, Settings, Models, and Configure providers. For an existing LM Studio runtime choose LM Studio, configure it, submit, and select the model loaded in that server. The entered name must match the server panel identifier. For Ollama, use its documented provider and the host of the running local runtime. The CLI alternative is goose configure followed by Configure Providers. Begin a fresh session with only the extension required for the trial (Goose provider configuration).
A worked example
Prepare a disposable directory with a fictional project note. Ask Goose to summarize the note through an explicitly permitted file-reading extension, without changing files. Compare the answer with the source and inspect which tool was invoked. Then ask a clarification using the returned text. This distinguishes actual reading from a plausible response generated without accessing the file.
| Check | Record |
|---|---|
| Provider | The selected local runtime and exact model identity. |
| Extension | The enabled file-reading capability used for the disposable note. |
| Evidence | The tool result and an answer grounded in the note’s actual contents. |
Reading the failure correctly
If Goose answers but cannot read the file, inspect extension availability, process environment, and file scope. If the model returns prose instead of a tool action, check whether that model/runtime combination supports the required behavior. Replacing the prompt repeatedly is not a substitute for identifying a missing capability.
What completes the check
Retain the provider configuration and one observed tool result for the first task. Add other extensions incrementally, so their independent credentials and execution effects do not obscure the verified local model path. Use the exact loaded model identifier rather than copying the illustrative model name from the provider guide (Goose official repository).
Related background: Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.