anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[Bug] Timeout not working for Local LLM with MLX Models #1959

New Issue
Closed
opened 2026-02-16 17:33:25 -05:00 by yindo · 19 comments
yindo commented 2026-02-16 17:33:25 -05:00
Owner
Copy Link
Copy Source

Originally created by @webboty on GitHub (Oct 4, 2025).

Originally assigned to: @thdxr on GitHub.

There is still an issue that with a local provider like "lm studio" serving MLX models, timeout settings in the opencode.json config are totally ignored.

This break a lot of workflows especially with subagents.
While the main chat window might be continued via "continue", subagents once timeout can not be continued.

Running bigger local models especially with bigger CTX may sometimes require more than the default timeout setting.

Here is a fraction of a config that shows how the timeout is set and yet ognored.

[...]
 "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://192.168.1.107:11435/api/v0",
        "timeout": 900000,
        "includeUsage": true
      },
      "models": {
[...]
Originally created by @webboty on GitHub (Oct 4, 2025). Originally assigned to: @thdxr on GitHub. There is still an issue that with a local provider like "lm studio" serving MLX models, timeout settings in the opencode.json config are totally ignored. This break a lot of workflows especially with subagents. While the main chat window might be continued via "continue", subagents once timeout can not be continued. Running bigger local models especially with bigger CTX may sometimes require more than the default timeout setting. Here is a fraction of a config that shows how the timeout is set and yet ognored. ``` [...] "provider": { "lmstudio": { "npm": "@ai-sdk/openai-compatible", "name": "LM Studio (local)", "options": { "baseURL": "http://192.168.1.107:11435/api/v0", "timeout": 900000, "includeUsage": true }, "models": { [...] ```
yindo closed this issue 2026-02-16 17:33:25 -05:00
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 4, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #1065: How to control Timeouts - discusses timeout configuration issues
  • #2865: Timeout then tool errors with Devstral-Medium - similar timeout issues with local models
  • #763: getting often TimeoutError - general timeout problems
  • #508: Better support for LM Studio local provider/models - broader LM Studio integration issues including timeout handling
  • #2463: Lmstudio and local models need system prompt - general LM Studio configuration issues

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Oct 4, 2025): This issue might be a duplicate of existing issues. Please check: - #1065: How to control Timeouts - discusses timeout configuration issues - #2865: Timeout then tool errors with Devstral-Medium - similar timeout issues with local models - #763: getting often TimeoutError - general timeout problems - #508: Better support for LM Studio local provider/models - broader LM Studio integration issues including timeout handling - #2463: Lmstudio and local models need system prompt - general LM Studio configuration issues Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 5, 2025):

just wanted to comment that I see this and I will give you a work around or fix when I get a chance

@rekram1-node commented on GitHub (Oct 5, 2025): just wanted to comment that I see this and I will give you a work around or fix when I get a chance
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@kaantekiner commented on GitHub (Oct 12, 2025):

hi, didnt https://github.com/sst/opencode/pull/1982 solved this, thanks.

@kaantekiner commented on GitHub (Oct 12, 2025): hi, didnt https://github.com/sst/opencode/pull/1982 solved this, thanks.
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 12, 2025):

no doesnt solve this one

@rekram1-node commented on GitHub (Oct 12, 2025): no doesnt solve this one
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@kaantekiner commented on GitHub (Oct 13, 2025):

@rekram1-node , thanks for very quick response. I tried with local ollama, like the https://github.com/sst/opencode/issues/1065 but it also failed to progress the 200 ms timeout threshod. So it is not working for all local providers, not just for lmstudio, can you please confirm?

{ "$schema": "https://opencode.ai/config.json", "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "name": "local ollama server", "options": { "baseURL": "http://xxxx:11434/v1", "timeout": 200 },

Thanks in advance.

@kaantekiner commented on GitHub (Oct 13, 2025): @rekram1-node , thanks for very quick response. I tried with local ollama, like the https://github.com/sst/opencode/issues/1065 but it also failed to progress the 200 ms timeout threshod. So it is not working for all local providers, not just for lmstudio, can you please confirm? `{ "$schema": "https://opencode.ai/config.json", "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "name": "local ollama server", "options": { "baseURL": "http://xxxx:11434/v1", "timeout": 200 }, ` Thanks in advance.
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 13, 2025):

@kaantekiner not sure i entirely follow, if you are setting the timeout to a smaller value it will work but if it is larger than 5 minutes in some cases it won't work because bun has underlying timeout of 5 minutes if no data is being sent from the server

@rekram1-node commented on GitHub (Oct 13, 2025): @kaantekiner not sure i entirely follow, if you are setting the timeout to a smaller value it will work but if it is larger than 5 minutes in some cases it won't work because bun has underlying timeout of 5 minutes if no data is being sent from the server
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@kaantekiner commented on GitHub (Oct 13, 2025):

@rekram1-node I tried the timeout with 200 MS (like the above snippet) and few seconds, but no luck, it did not respect at all, no timeout on cli.

Also passed 'option' parameters like 'num_ctx' to ollama not worked as well. I didn't set a reverse proxy for api observation (opencode --> ollama api), but 'ollama serve' logs did not aligned with num_ctx while booting the model. But somehow when options have 'reasoning': true, and if model does not have that feature, it tirggers the error at cli, which is correct.

Need some deeper investigation I believe.

@kaantekiner commented on GitHub (Oct 13, 2025): @rekram1-node I tried the timeout with `200 MS` (like the above snippet) and few seconds, but no luck, it did not respect at all, no timeout on cli. Also passed 'option' parameters like `'num_ctx'` to ollama not worked as well. I didn't set a reverse proxy for api observation `(opencode --> ollama api)`, but `'ollama serve'` logs did not aligned with `num_ctx` while booting the model. But somehow when options have `'reasoning': true`, and if model does not have that feature, it tirggers the error at cli, which is correct. Need some deeper investigation I believe.
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 13, 2025):

ahh i see, wait for num_ctx you need to set that in ollama that's not an option to pass

@rekram1-node commented on GitHub (Oct 13, 2025): ahh i see, wait for num_ctx you need to set that in ollama that's not an option to pass
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@kaantekiner commented on GitHub (Oct 13, 2025):

ahh i see, wait for num_ctx you need to set that in ollama that's not an option to pass

exactly, this approach below remediates. I have seen it from some other dev, it is working.

for the timeout thing, I can wait.

@kaantekiner commented on GitHub (Oct 13, 2025): > ahh i see, wait for num_ctx you need to set that in ollama that's not an option to pass exactly, this approach below remediates. I have seen it from some other dev, it is working. - https://github.com/p-lemonish/ollama-x-opencode?tab=readme-ov-file for the timeout thing, I can wait.
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 13, 2025):

Sounds good, hm weird that timeout isn't working at all I thought for short ones it'd be enforced lol well thanks for finding this!

@rekram1-node commented on GitHub (Oct 13, 2025): Sounds good, hm weird that timeout isn't working at all I thought for short ones it'd be enforced lol well thanks for finding this!
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@webboty commented on GitHub (Oct 13, 2025):

@kaantekiner not sure i entirely follow, if you are setting the timeout to a smaller value it will work but if it is larger than 5 minutes in some cases it won't work because bun has underlying timeout of 5 minutes if no data is being sent from the server

Do you have any idea how we could get around that?

Like an intermediate service (like a bridge listener) the request are funneled through and responds with something before the 5 minutes are over? Or a custom version of bun where this stupid hard coded 5 minute threshold is eliminated? 5 minutes in LLM world is not a lot. :-(

@webboty commented on GitHub (Oct 13, 2025): > [@kaantekiner](https://github.com/kaantekiner) not sure i entirely follow, if you are setting the timeout to a smaller value it will work but if it is larger than 5 minutes in some cases it won't work because bun has underlying timeout of 5 minutes if no data is being sent from the server Do you have any idea how we could get around that? Like an intermediate service (like a bridge listener) the request are funneled through and responds with something before the 5 minutes are over? Or a custom version of bun where this stupid hard coded 5 minute threshold is eliminated? 5 minutes in LLM world is not a lot. :-(
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 14, 2025):

yeah ill take a look at that tmr, but just so we are clear the timeout should only be occurring if nothing is being sent from server, if the llm is actively doign things the request could last long long periods of time

But totally yeah we should be able to work around that default

@rekram1-node commented on GitHub (Oct 14, 2025): yeah ill take a look at that tmr, but just so we are clear the timeout should only be occurring if nothing is being sent from server, if the llm is actively doign things the request could last long long periods of time But totally yeah we should be able to work around that default
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@webboty commented on GitHub (Oct 14, 2025):

yeah ill take a look at that tmr, but just so we are clear the timeout should only be occurring if nothing is being sent from server, if the llm is actively doign things the request could last long long periods of time

But totally yeah we should be able to work around that default

You are right, once the llm starts streaming results it is, all working. With bigger context and bigger model (despite great hardware) it can take more than 5 minutes until the llm starts streaming.

so the time to first token is the big issue.

@webboty commented on GitHub (Oct 14, 2025): > yeah ill take a look at that tmr, but just so we are clear the timeout should only be occurring if nothing is being sent from server, if the llm is actively doign things the request could last long long periods of time > > But totally yeah we should be able to work around that default You are right, once the llm starts streaming results it is, all working. With bigger context and bigger model (despite great hardware) it can take more than 5 minutes until the llm starts streaming. so the **time to first token** is the big issue.
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 16, 2025):

found the issue, fixing now

@rekram1-node commented on GitHub (Oct 16, 2025): found the issue, fixing now
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 16, 2025):

will be fixed in next release

@rekram1-node commented on GitHub (Oct 16, 2025): will be fixed in next release
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rawzone commented on GitHub (Oct 24, 2025):

will be fixed in next release

Sadly didn't make it in the last release?

Any timeline for the to merge in release? As of now it stops at least me from using opencode as every prompt fails with a timeout. (Yes I run the LLM om a bit of older hardware. But Im sure many of us are).

@rawzone commented on GitHub (Oct 24, 2025): > will be fixed in next release Sadly didn't make it in the last release? Any timeline for the to merge in release? As of now it stops at least me from using opencode as every prompt fails with a timeout. (Yes I run the LLM om a bit of older hardware. But Im sure many of us are).
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 24, 2025):

@rawzone it was released, are you sure the setting doesn't work for you I tested it with proxy servers and it was working for me. What version of opencode are you using?

This is what setting looks like:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "my-provider": {
      "options": {
        "timeout": 100000000000
      }
    }
  }
}

Timeout is in milliseconds

@rekram1-node commented on GitHub (Oct 24, 2025): @rawzone it was released, are you sure the setting doesn't work for you I tested it with proxy servers and it was working for me. What version of opencode are you using? This is what setting looks like: ``` { "$schema": "https://opencode.ai/config.json", "provider": { "my-provider": { "options": { "timeout": 100000000000 } } } } ``` Timeout is in milliseconds
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rawzone commented on GitHub (Oct 24, 2025):

Thanks @rekram1-node !

It does in fact seem to work as intended now.
Was just going by the text on the "releases" and didn't say anything about the timeout issue.

Now I can run opencode to help me out with projects (slowly, but without timeouts on this old dual Xeon CPU server), yay!

Have a great weekend. 🫡

@rawzone commented on GitHub (Oct 24, 2025): Thanks @rekram1-node ! It does in fact seem to work as intended now. Was just going by the text on the "releases" and didn't say anything about the timeout issue. Now I can run opencode to help me out with projects (_slowly_, but without timeouts on this old dual Xeon CPU server), yay! Have a great weekend. 🫡
yindo commented 2026-02-16 17:33:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 24, 2025):

Sweet, you too

@rekram1-node commented on GitHub (Oct 24, 2025): Sweet, you too
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1959
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?