Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
Right now, using local Ollama models with OpenCode is either undocumented, partially broken, or confusing compared to cloud-based providers (e.g. Ollama Cloud or OpenAI-compatible endpoints).
Even though Ollama exposes an OpenAI-compatible API (/v1/chat/completions), OpenCode does not clearly or reliably support:
- local model discovery
- correct tool-calling behavior with local models
- full configuration parity with cloud providers
- context length configuration (
num_ctx)
- proper separation of model types (chat / vision / embedding)
As a result, local-first setups are hard to use or require fragile manual configuration.
Use case
Many users want to run OpenCode fully locally using:
- Ollama on
http://localhost:11434
- coder models (e.g. Qwen, Llama, DeepSeek)
- optional vision models
- embedding models for indexing
This is important for:
- privacy-focused workflows
- offline development environments
- GPU-limited local setups
- avoiding cloud provider costs
Proposed feature
Add first-class support for local Ollama provider mode, similar to OpenAI-compatible providers.
1. Native local provider support
Allow a clean config like:
{
"provider": {
"ollama": {
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
}
}
}
}
2. Model auto-discovery
Support fetching models from:
/api/tags (Ollama native)- or
/v1/models (OpenAI-compatible layer)
Then automatically classify:
- chat models
- vision models
- embedding models
3. Explicit model type support
Allow marking models explicitly:
"models": {
"qwen2.5-coder": {
"name": "Qwen Coder",
"type": "chat"
},
"nomic-embed": {
"name": "Embeddings",
"type": "embedding"
},
"llava": {
"name": "Vision Model",
"type": "vision"
}
}
4. Tool calling reliability improvements
Ensure local Ollama models:
- properly trigger tool calls (not just print JSON)
- follow OpenAI tool schema consistently
- are not blocked by provider abstraction differences
Expected outcome
With proper local Ollama support:
- OpenCode becomes fully usable offline
- tool calling works reliably with local coder models
- embeddings + vision pipelines become possible locally
- configuration complexity is significantly reduced
Why this matters
Right now local Ollama support feels like a “best effort integration”, while cloud providers are first-class. Making Ollama a first-class provider would significantly improve adoption for local-first users.
Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
Right now, using local Ollama models with OpenCode is either undocumented, partially broken, or confusing compared to cloud-based providers (e.g. Ollama Cloud or OpenAI-compatible endpoints).
Even though Ollama exposes an OpenAI-compatible API (
/v1/chat/completions), OpenCode does not clearly or reliably support:num_ctx)As a result, local-first setups are hard to use or require fragile manual configuration.
Use case
Many users want to run OpenCode fully locally using:
http://localhost:11434This is important for:
Proposed feature
Add first-class support for local Ollama provider mode, similar to OpenAI-compatible providers.
1. Native local provider support
Allow a clean config like:
{ "provider": { "ollama": { "name": "Ollama (local)", "options": { "baseURL": "http://localhost:11434/v1" } } } }2. Model auto-discovery
Support fetching models from:
/api/tags(Ollama native)/v1/models(OpenAI-compatible layer)Then automatically classify:
3. Explicit model type support
Allow marking models explicitly:
4. Tool calling reliability improvements
Ensure local Ollama models:
Expected outcome
With proper local Ollama support:
Why this matters
Right now local Ollama support feels like a “best effort integration”, while cloud providers are first-class. Making Ollama a first-class provider would significantly improve adoption for local-first users.