# Run OpenCode with a local Ollama model in Canopy

> Set up a local model route, account for OpenCode V1 and V2 differences, verify context and tool use, then test an offline coding task in Canopy.

Canonical HTML: https://canopyide.dev/guides/opencode-ollama-local-model-in-canopy
Article date: 2026-09-28

Canopy launches installed coding CLIs; it does not ship an Ollama model or reroute a CLI's provider account. To run a local coding agent, install Ollama and OpenCode, make OpenCode select a model served on localhost, then launch that OpenCode session from the right Canopy project. Verify the selected route and one real edit before calling the workflow offline. The commands below follow current Ollama and OpenCode documentation; the exact installed versions and hardware still need a local trial.

## Prepare all three layers while connected

Install Canopy, OpenCode, and Ollama through their official installation paths while online. Choose an Ollama model that fits your machine and supports the tool use your coding task needs; download its weights before disconnecting. Ollama's CLI reference documents `ollama pull`, `ollama ls`, `ollama serve`, and `ollama ps`. Its OpenCode integration says coding-agent sessions need a large context window and recommends 64k or more. Larger context consumes more memory, and a model that answers chat questions may still fail at edits or tool calls. Check the model's actual context and processor placement with `ollama ps` during a trial. Do not assume that a model name ending in `:cloud` is local just because you selected it in Ollama.

*Each layer has a separate job; inspect the exact installed versions.*

| Layer | Owns | First evidence |
| --- | --- | --- |
| Canopy | Project, terminal, local services, preview, Git review | Correct project and checkout are open |
| OpenCode | Agent session, model selection, tools, file edits | Selected provider/model and visible tool action |
| Ollama | Model weights and inference endpoint | Local model listed and responding on localhost |
| Your project | Runtime, dependencies, data, tests, deployment | A run command and accepted behavior |

## Connect OpenCode according to its version

OpenCode's V2 provider docs say it probes Ollama at `http://127.0.0.1:11434`, discovers completion models, and lists them under `/models` without an account connection. Start Ollama, pull a model, open OpenCode, and explicitly select an `ollama/...` entry. The V1 provider docs instead show an `opencode.json` entry with the `@ai-sdk/openai-compatible` package and `http://localhost:11434/v1`; Ollama's integration guide offers `ollama launch opencode --config` to configure OpenCode without starting it. Check which docs match your installed major version. A V1 `provider` object and V2 `providers` object are different schemas; copying the wrong one can leave the model absent even when Ollama is healthy. If Canopy launches OpenCode after a config-only step, verify that the model appears in that new session rather than assuming the settings followed it.

## Prove the endpoint and the chosen model

Run `ollama ls` to confirm weights are present, and use Ollama's documented `GET /api/tags` on localhost to check that its server responds. In OpenCode, inspect `/models` and choose the Ollama provider entry by its full ID. Then ask a read-only question about a file in a disposable repository and watch for the actual model response. If the response comes from another configured provider, the local trial has not begun. Ollama's context guide shows `ollama ps` with CONTEXT and PROCESSOR columns after the model loads; a too-small context or heavy CPU offload may explain slow or broken agent work. Record the model identifier, installed OpenCode major version, context, and selected endpoint before granting edit authority.

## Launch inside the intended Canopy checkout

Open a disposable local repository in Canopy, check its branch and working directory, and launch the installed OpenCode CLI from that project. Ask for one bounded change, such as a failing form validation test, with a success check and a failure check. Inspect the live terminal for tool activity, run the relevant test, and read the Git diff in Canopy before accepting the result. Canopy does not choose OpenCode's provider or make the local model good at tool use. If OpenCode is missing from the Canopy launcher, verify its installed path and the Canopy release; starting a shell in the same project is a practical diagnostic, but a shell tab alone does not prove agent integration parity.

## Repeat with Internet disconnected

After dependencies, the model, and the sample project are present, disconnect Internet access while leaving localhost available. Start the same Canopy project, confirm the Ollama endpoint, select the local OpenCode model, and run a fresh small task. Check the resulting edit, test, and diff. Note any package install, MCP server, remote database, GitHub operation, plugin, or project API that still requires the network. A failure in one of those services is not necessarily a local-inference failure; a silent switch to a cloud model is. Ollama itself can offer cloud models, so use the chosen model ID and endpoint as evidence. The separate offline-workflow guide gives the fuller workspace and integration checklist.

## Copyable resources

### Example local-route checks

Use a model your hardware can run. Start `ollama serve` only when the Ollama app or service is not already serving the endpoint; it holds that terminal open. OpenCode V1 may need the separate config-only step.

````text
opencode --version
ollama pull qwen3:8b
ollama ls
# In a separate terminal, if Ollama is not already running:
ollama serve
# Then check the local endpoint:
curl http://127.0.0.1:11434/api/tags
# In OpenCode, inspect /models and select the ollama/... model.
# If using the V1 config path, follow the Ollama integration guide:
ollama launch opencode --config
# During a model response, check allocated context and CPU/GPU placement:
ollama ps
````

### Local OpenCode trial card

This is a reproducible check, not a benchmark of model quality. Commands and version rules come from the linked official docs.

````text
Canopy release/platform and project/branch: [ ]
OpenCode version and docs branch (V1/V2): [ ]
Ollama version, local model ID, weights present: [ ]
Server started: [ ]; `ollama ls` result: [ ]
Local `/api/tags` response: [ ]
OpenCode `/models` selected provider/model: [ ]
V1 config-only step or V2 automatic discovery: [ ]
`ollama ps` CONTEXT and PROCESSOR during request: [ ]
Read-only question and visible response/tool activity: [ ]
Small edit, test command/result, final Canopy diff: [ ]
Internet-disconnected repeat: local inference [ ]; accepted task [ ]; network dependencies [ ].
````

## Frequently asked questions

### Does Canopy include Ollama or a free local model?

No. Install Ollama, a suitable model, and an OpenCode version that can select its local provider. Canopy supplies the project and CLI workspace.

### Why does Ollama work in a terminal but not appear in OpenCode?

Check the OpenCode major version and its matching provider rules. V2 documents localhost discovery; V1 documents an explicit provider configuration. Then verify the model is a completion model and the endpoint is reachable.

### Does using Ollama guarantee my whole coding task is offline?

No. Select a local model rather than an Ollama cloud model, then test the project runtime, dependencies, tools, MCP servers, and other integrations with Internet access disconnected.

### Will a small local model work as well as a hosted coding model?

Model quality, context capacity, tool reliability, and hardware vary. Use a bounded task with a real test and final diff before trusting it on larger changes.

## Sources and further reading

- [OpenCode V2 provider discovery for Ollama](https://opencode.ai/v2/docs/providers)
- [OpenCode V2 model selection and local discovery](https://opencode.ai/v2/docs/models)
- [OpenCode V1 Ollama provider configuration](https://opencode.ai/docs/providers)
- [Ollama OpenCode integration and config-only command](https://docs.ollama.com/integrations/opencode)
- [Ollama CLI commands](https://docs.ollama.com/cli)
- [Ollama context length and memory guidance](https://docs.ollama.com/context-length)
- [Ollama local model-list API](https://docs.ollama.com/api/tags)
- [Canopy current-main README and CLI release caveat](https://github.com/FluidWorksApp/canopy-ide/blob/main/README.md)
- [Public OpenCode and Ollama setup question](https://www.reddit.com/r/opencodeCLI/comments/1rhafzr/how_to_use_opencode_with_ai_assistant_local_llm/)

## Related Canopy pages

- [Can Canopy work offline with a local coding agent?](https://canopyide.dev/use-cases/canopy-offline-local-coding-agent-workflow.md)
- [Canopy vs OpenCode: agent or project workspace?](https://canopyide.dev/use-cases/canopy-vs-opencode-for-coding-agents.md)
- [Which coding-agent CLIs work in Canopy, and what differs?](https://canopyide.dev/guides/coding-agent-cli-support-in-canopy.md)
- [How to reduce coding-agent token usage without losing the result](https://canopyide.dev/guides/reduce-coding-agent-token-usage.md)
- [What leaves your machine when you use Canopy?](https://canopyide.dev/use-cases/what-leaves-your-machine-when-using-canopy.md)

Canopy runs installed coding CLIs; CLI accounts, model selection, and provider billing remain separate. Check the installed release before relying on version-specific behavior.