Repository navigation
Integration with Ollama Local #19948
Description
Description
Bug Report: Ollama local model not working in OpenCode Desktop
Description
When using OpenCode Desktop application (Windows), after configuring a local Ollama model, the model appears in the list but returns invalid JSON responses ({ "name": "skill", "arguments": { "name": "build" } }) instead of actual text responses.
Environment
- OpenCode version: 1.2.27
- Operating System: Windows
- Ollama version: Running locally on port 11434
- Model: DanyaVoredom/DanyAI-qwen2.5-coder-3b-instruct:latest
Steps to Reproduce
- Install OpenCode Desktop for Windows
- Download a model in Ollama (e.g.,
ollama run DanyaVoredom/DanyAI-qwen2.5-coder-3b-instruct) - Configure opencode.json with Ollama provider:
{ "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "name": "Ollama (local)", "options": { "baseURL": "http://localhost:11434/v1" }, "models": { "DanyaVoredom/DanyAI-qwen2.5-coder-3b-instruct:latest": { "name": "DanyAI Coder 3B", "_launch": true } } } } } - Open OpenCode Desktop
- Select the Ollama model from the model list
- Send a prompt
Expected Behavior
The model should return a normal text response.
Actual Behavior
The model returns invalid JSON: { "name": "skill", "arguments": { "name": "build" } }
Verification
- Ollama API works correctly (tested via curl)
- The same configuration works with OpenCode CLI (terminal version)
- This appears to be a bug specific to the OpenCode Desktop application
Additional Information
- Similar issue reported in GitHub: Ollama local provider is not appearing #19326 (Ollama local provider is not appearing)
- Issue Unable to connect local Ollama #10961 (Unable to connect local Ollama)
- The CLI version works correctly, only Desktop app has this issue
Screenshots
N/A
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Reacted by marekmalczewski, Maifee Ul Asad, nextgenthemes, bgoewert-seiler and Mehul H
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Mar 29, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct from the above, please clarify how it differs. Otherwise, consider adding your details there instead.
cdvankammen commentedon Apr 29, 2026
Again I am confused.....why is there not a "Ollama local" and or an "Custom OpenAI" option in opencode? during the provider setup there are no local options that allow for confignureing a local ip addresss form what i have been able to find
Hello-World-Traveler commentedon May 3, 2026
I have had same issue
{ "name": "skill", "arguments": { "name": "build" } }it's something to do with the model however I haven't got this working with Ollama, only using the free models, Opencode started to work.Integration with Ollama Locally would be nice.
kunningKing11 commentedon May 4, 2026
@Brendonovich will Ollama Local be added as a model provider option? LM Studio already is.
marekmalczewski commentedon May 19, 2026
I confirm. For Ollama na LM Studio provider result is simillar. Models are not able to run tools:
jclsn commentedon May 20, 2026
I don't see the issue here. My local ollama connection works just fine. Problem is that the local models cannot run tools, but the ollama cloud models can for some reason.
My local gemma4 model is not able to use tools and repeatedly asks me what to do. The cloud models works. I also have to add that the cloud model is served via an ollama instance on the same host (my server) and the local gemma runs on my desktop's larger GPU.
Both are configured the same way
{ "$schema": "https://opencode.ai/config.json", "permission": { "edit": "allow", "bash": "allow", "webfetch": "allow", "question": "allow", "read": "allow", "glob": "allow", "write": "allow", "task": "allow", "todowrite": "allow", }, "provider": { "ollama-nas": { "npm": "@ai-sdk/openai-compatible", "name": "NAS", "options": { "baseURL": "http://127.0.0.1:11434/v1" }, "models": { "gemma4:31b-cloud": { "name": "gemma4:31b-cloud", "tools": true }, } }, "ollama-desktop": { "npm": "@ai-sdk/openai-compatible", "name": "Desktop", "options": { "baseURL": "http://192.168.184.117:11434/v1" }, "models": { "gemma4:latest": { "name": "gemma4:latest", "tools": true }, } } } }kunningKing11 commentedon May 20, 2026
The problem is that it is less user-friendly to have to edit the
jsonconfig file and also the secondary issue is the tool calls.jclsn commentedon May 20, 2026
@kunningKing11 Yeah, it's really weird with the tools calls. I mean why would the cloud models run and not the local ones. They are served by the same API.
I tried verifying if the problem lies in the ollama instance on another machine by adding a cloud model. Again, the cloud model on my desktop works, the local one doesn't
2 remaining items
jaredmontoya commentedon Jun 20, 2026
It seems to me that because of the official opencode docs everyone is trying to use the OpenAI compatible API with ollama.
Unfortunately the Ollama OpenAI compatible api does not support setting context via a parameter like
num_ctxthat is available on the official Ollama API.So if you use opencode with the openai compatible api and don't want to set a global context size value that is not model specific or don't want to wrap every model with a modelfile to set proper context size for each model, you will get the default ollama value that for most people will be 4096 tokens.
I personally use ollama-ai-provider-v2 currently:
{ "$schema": "https://opencode.ai/config.json", "provider": { "ollama": { "models": { "gemma4:12b-it-qat": { "id": "gemma4:12b-it-qat", "limit": { "context": 194560, "output": 32768 }, "name": "gemma4:12b-it-qat", "options": { "options": { "keep_alive": "10m", "num_ctx": 194560 }, "think": true }, "tool_call": true } }, "name": "Ollama", "npm": "ollama-ai-provider-v2", "options": { "baseURL": "http://localhost:11434/api" } } } }because it lets me set the model context size, without this feature local models are useless in opencode.
I did not test this idea but I assume the default value for cloud ollama models is full context and not just measly 4096 so that's probably why @jclsn experienced the difference between them.
While ollama-ai-provider-v2 is kind of working, I noticed some quirks so it might not be the best solution and I assume that https://github.com/jagreehal/ai-sdk-ollama would probably be better, but I can't use it because I was not able to figure out how to make it send
num_ctxby configuring it through opencode. If anyone figures out how to, please post the config here too.jclsn commentedon Jun 21, 2026
@jaredmontoya Tried that, but with local models I am only getting one token as response, whereas remote models work well. Tried your settings on and no context settings. Always the same thing.
zejjnt commentedon Jul 6, 2026
It's unfathomable to me that this issue has been brought up multiple times over more than a year, issues are closed because of duplicate other issues that have not been addressed. Do the devs not care at all about their repo or what is even going on here?
Every other thing, no matter what it is, works flawlessly with http://localhost:11434 but not opencode - which is the most commonly recommended IDE for vibe coding. What.
nextgenthemes commentedon Jul 6, 2026
Apparently not, it's a shame that this thing calls it "opencode" is extremely popular but only cares to send all your shit to the big datacenters and does not let you do it the most open source and private way of running open source models locally.
However, opencode is not an IDE.
jaredmontoya commentedon Jul 6, 2026
To be fair, Ollama also isn't perfect, they don't seem to want to add support for Ollama specific options in their OpenAI compatible API. It would be way easier for everyone if the OpenAI API was the default for inference and the Ollama model management API was either a separate thing or an extension to the OpenAI API. Anytime something that is good for most people isn't merged into a project without a sane justification I assume that it's either incompetence/ignorance or malice and both are bad. This is why I am currently evaluating whether it is worth it for me to move from Ollama to llama.cpp + llama-swap which unlike Ollama are both excellent open source citizens.
nextgenthemes commentedon Jul 6, 2026
Why cares if Ollama is perfect? How is this an excuse? Opencode supports Ollama cloud but not local? It can be THAT complicated to get some basics going it does not have to be the most perfect integration possible. It just needs to work, and then it can go from there.
And yes its always easy to complain, we should get on it to fix it, but would a PR even get pulled. The people who make this finance it by getting paid by companies who want specific things. CLEARLY this is not on the list.
jaredmontoya commentedon Jul 6, 2026
Didn't know they supported Ollama Cloud 😂. This does make it worse indeed.
jaredmontoya commentedon Jul 6, 2026
But I still think Ollama is just bad actually, this post finally made me realize that the issues I have with Ollama are already solved by llama.cpp + llama-swap, especially this section and this one
zejjnt commentedon Jul 6, 2026
I mean... Every single model is bad if you want to get really anal about it because it is simply immoral to train off of other people's work. IMO, of course.
Heh, you're absolutely correct, I wasn't even remotely using that term properly. Thanks for making me laugh for some reason.
jaredmontoya commentedon Jul 6, 2026
I think you are misunderstanding something, I dgaf if the model was trained on baby cries. Also we are talking about Ollama vs Llama.cpp which are inference engines and not models so what you said is completely irrelevant. Go and actually read the
The Modelfile: Reinventing a Solved ProblemandThe Registry Bottlenecksections and if you like them then might as well readThe Fork That Made Things Worse,Misleading Model NamingandThe Cloud Pivot. The rest of the arguments in the post also hold some weight but these are about "design decisions" and manifestations of conflicts of interest that directly and tangibly affect users of Ollama.zejjnt commentedon Jul 6, 2026
I read it, I was just pointing out a similar issue from the broader perspective. If you want to have an internet slapfight you can find someone else to partner with.
jaredmontoya commentedon Jul 6, 2026
I don't know where you see a slapfight, I just couldn't understand why your response seems to not be about what I said at all. Your first message was about model training ethical issues which were not mentioned at all in the post that I linked, so I said that it was irrelevant to what I linked and told you to read it again because I assumed that you didn't read the exact sections I mentioned because how could you not see that it is not about ethical issues of model training.
If you just wanted to comment on how people are mad about AI then you shouldn't have quoted my comment as if you are replying to it because your message seems like a response to me saying: "I think X model is bad because it was trained on other peoples's work" which is obviously far from what I said.
github-actions commentedon Sep 5, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
nextgenthemes commentedon Sep 5, 2026
OK I not remember what was the exact issue but I think it may be just down the model you use. I think this may come down to just using a model that support tool calls correctly. Qwen3.6 does.
I use ramalama now instead of ollama and it works fine with opencode
however, even though on paper this model I can run on my 9070 XT seems pretty great, I have not tried but using the actual full context would slow it down too much. Free models like Big Pickle are already better than the best coding model I can run. Spend (wasted) a lot of time optimizing all kinds of parameters before I realized how good free models are in comparison.
If course you always pay with your data if you use a remote model. Its kind of sad that we are at a point that free models get you better results then what you can run locally on a pretty expensive consumer GPU but I guess that is where we are.