anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 02:36:57 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

think: false option not working for Ollama models #2486

New Issue
Closed
opened 2026-02-16 17:35:52 -05:00 by yindo · 10 comments
yindo commented 2026-02-16 17:35:52 -05:00
Owner
Copy Link
Copy Source

Originally created by @SuperSonnix71 on GitHub (Nov 2, 2025).

Originally assigned to: @rekram1-node on GitHub.

think: false option not working for Ollama models

Hey! I'm trying to disable thinking output for an Ollama model (qwen3), but the think: false parameter seems to be ignored. The model still outputs <think> blocks no matter where I configure it.

What I tried

1. Model-level config:

{
  "provider": {
    "ollama": {
      "models": {
        "qwen3-32-opencode": {
          "name": "Qwen3 32B OpenCode",
          "options": {
            "think": false
          }
        }
      }
    }
  }
}

2. Agent-level config:

{
  "agent": {
    "ollama": {
      "model": "ollama/qwen3-32-opencode",
      "options": {
        "think": false
      }
    }
  }
}

3. Both at once (model-level AND agent-level)

Expected behavior

The model should not output <think>...</think> blocks when think: false is set.

Actual behavior

The model still outputs thinking blocks:

<think>
Okay, the user wants me to...
[thinking content]
</think>

Environment

  • OpenCode version: Latest
  • Model: qwen3-32-opencode (custom Ollama variant based on qwen3:32b)
  • Ollama API endpoint: Remote (http://ai:11434/v1)

Notes

  • According to the docs, think is a valid runtime parameter for Ollama API
  • The parameter works when calling Ollama API directly via curl with "think": false
  • It seems OpenCode might not be passing this parameter to Ollama, or it's being passed incorrectly

Is this a known issue? Any workaround to disable thinking for Ollama models?

Thanks!

Originally created by @SuperSonnix71 on GitHub (Nov 2, 2025). Originally assigned to: @rekram1-node on GitHub. # `think: false` option not working for Ollama models Hey! I'm trying to disable thinking output for an Ollama model (qwen3), but the `think: false` parameter seems to be ignored. The model still outputs `<think>` blocks no matter where I configure it. ## What I tried **1. Model-level config:** ```jsonc { "provider": { "ollama": { "models": { "qwen3-32-opencode": { "name": "Qwen3 32B OpenCode", "options": { "think": false } } } } } } ``` **2. Agent-level config:** ```jsonc { "agent": { "ollama": { "model": "ollama/qwen3-32-opencode", "options": { "think": false } } } } ``` **3. Both at once** (model-level AND agent-level) ## Expected behavior The model should not output `<think>...</think>` blocks when `think: false` is set. ## Actual behavior The model still outputs thinking blocks: ``` <think> Okay, the user wants me to... [thinking content] </think> ``` ## Environment - OpenCode version: Latest - Model: qwen3-32-opencode (custom Ollama variant based on qwen3:32b) - Ollama API endpoint: Remote (http://ai:11434/v1) ## Notes - According to the docs, `think` is a valid runtime parameter for Ollama API - The parameter works when calling Ollama API directly via curl with `"think": false` - It seems OpenCode might not be passing this parameter to Ollama, or it's being passed incorrectly Is this a known issue? Any workaround to disable thinking for Ollama models? Thanks!
yindo closed this issue 2026-02-16 17:35:52 -05:00
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 2, 2025):

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

  • #2875: Have an ability to turn on / off thinking mode - Similar request for controlling thinking output, though more general
  • #2531: Removing thinking tokens from nano-gpt provider - Very similar issue about stripping thinking tokens from models, with config options not being respected
  • #1006: Hide Chain-of-Thoughts when use opencode run - Same core problem of thinking blocks appearing despite configuration attempts
  • #1528: [Feature Request] Add support for using thinking tags in local models - Related to thinking output control for local models

The issues #2531 and #1006 are particularly similar as they deal with the same problem of thinking/reasoning output not being properly suppressed despite configuration attempts.

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

@github-actions[bot] commented on GitHub (Nov 2, 2025): This issue might be a duplicate of existing issues. Please check: - #2875: Have an ability to turn on / off thinking mode - Similar request for controlling thinking output, though more general - #2531: Removing thinking tokens from nano-gpt provider - Very similar issue about stripping thinking tokens from models, with config options not being respected - #1006: Hide Chain-of-Thoughts when use opencode run - Same core problem of thinking blocks appearing despite configuration attempts - #1528: [Feature Request] Add support for using thinking tags in local models - Related to thinking output control for local models The issues #2531 and #1006 are particularly similar as they deal with the same problem of thinking/reasoning output not being properly suppressed despite configuration attempts. Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 2, 2025):

@SuperSonnix71 ollama doesn't expose this parameter through their openai api

@rekram1-node commented on GitHub (Nov 2, 2025): @SuperSonnix71 ollama doesn't expose this parameter through their openai api
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@SuperSonnix71 commented on GitHub (Nov 2, 2025):

@rekram1-node Thanks for clarifying! You're right that the OpenAI-compatible API doesn't support the think parameter. I saw it after filing this. However, according to https://ollama.com/blog/thinking, the OpenAI-compatible endpoint (/v1/chat/completions) uses reasoning_effort instead of think.

So OpenCode should be passing reasoning_effort: false (or "low") to the OpenAI-compatible API, not think: false.

The current config accepts think: false, but it seems like OpenCode isn't translating this to the correct reasoning_effort parameter when calling Ollama's v1 endpoint.

@SuperSonnix71 commented on GitHub (Nov 2, 2025): @rekram1-node Thanks for clarifying! You're right that the OpenAI-compatible API doesn't support the think parameter. I saw it after filing this. However, according to https://ollama.com/blog/thinking, the OpenAI-compatible endpoint (/v1/chat/completions) uses reasoning_effort instead of think. So OpenCode should be passing reasoning_effort: false (or "low") to the OpenAI-compatible API, not think: false. The current config accepts think: false, but it seems like OpenCode isn't translating this to the correct reasoning_effort parameter when calling Ollama's v1 endpoint.
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 2, 2025):

@SuperSonnix71 options isn't meant for translating unless it is done by the underlying ai sdk provider. So instead options should be what the ollama server needs. I think in this case you can try reasoningEffort: false or reasoningEffort: "low"

Why am I saying reasoningEffort instead of reasoning_effort well that is because we use the vercel ai sdk and it expects reasoningEffort

@rekram1-node commented on GitHub (Nov 2, 2025): @SuperSonnix71 `options` isn't meant for translating unless it is done by the underlying ai sdk provider. So instead `options` should be what the ollama server needs. I think in this case you can try `reasoningEffort: false` or `reasoningEffort: "low"` Why am I saying reasoningEffort instead of `reasoning_effort` well that is because we use the vercel ai sdk and it expects `reasoningEffort`
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@SuperSonnix71 commented on GitHub (Nov 2, 2025):

@rekram1-node Thanks for the clarification about using reasoningEffort with Vercel AI SDK. I did some testing and found a few interesting things.

About Ollama's Think Parameter

So here's the thing - Ollama actually does have a think parameter in their API. They document it in their blog post:

"There is a new think parameter that can be set to true or false for enabling a model's thinking process."

But this is for their native API (/api/chat and /api/generate), not the /v1 OpenAI-compatible endpoint, which is more of a minimalistic OpenAI SDK implementation.

Testing reasoningEffort

I tried your suggestion and updated my config to test both values you mentioned:

Test 1: reasoningEffort: false

"models": {
  "qwen3-32-opencode": {
    "options": {
      "reasoningEffort": false
    }
  }
}

Result:

AI:InvalidArgumentError: invalid ollama provider options.

Test 2: reasoningEffort: "low"

"models": {
  "qwen3-32-opencode": {
    "options": {
      "reasoningEffort": "low"
    }
  }
}

Result:

"qwen3-32-opencode" does not support thinking.

So neither approach works with Ollama's OpenAI-compatible endpoint.

More Testing with Ollama v0.12.9

I upgraded my Ollama server from v0.11.10 to v0.12.9 and tested the think parameter directly with curl:

DeepSeek-R1 - It works:

curl http://ai:11434/api/chat -d '{
  "model": "deepseek-r1:70b",
  "messages": [{"role": "user", "content": "What is 2+2?"}],
  "think": false,
  "stream": false
}'
# Output: "2 + 2 equals 4."
# No <think> blocks at all

Qwen3 - Doesn't work:

curl http://ai:11434/api/chat -d '{
  "model": "qwen3:32b",
  "messages": [{"role": "user", "content": "What is 2+2?"}],
  "think": false,
  "stream": false
}'
# Still outputs extensive <think> blocks

I tested this across:

  • Native API (/api/chat, /api/generate)
  • OpenAI-compatible API (/v1/chat/completions)
  • CLI with --think=false
  • Interactive mode with /set nothink

None of these work for Qwen3.

My Summary

It looks like DeepSeek-R1 can control thinking with the think: true/false parameter, but Qwen3's thinking is just baked into the model and can't be turned off. The /v1 OpenAI-compatible endpoint doesn't support the think parameter, and reasoningEffort (whether as a boolean or string) gets rejected.

@SuperSonnix71 commented on GitHub (Nov 2, 2025): @rekram1-node Thanks for the clarification about using `reasoningEffort` with Vercel AI SDK. I did some testing and found a few interesting things. ## About Ollama's Think Parameter So here's the thing - Ollama actually does have a `think` parameter in their API. They document it in their [blog post](https://ollama.com/blog/thinking): > "There is a new `think` parameter that can be set to `true` or `false` for enabling a model's thinking process." But this is for their native API (`/api/chat` and `/api/generate`), not the `/v1` OpenAI-compatible endpoint, which is more of a minimalistic OpenAI SDK implementation. ## Testing `reasoningEffort` I tried your suggestion and updated my config to test both values you mentioned: **Test 1: `reasoningEffort: false`** ```jsonc "models": { "qwen3-32-opencode": { "options": { "reasoningEffort": false } } } ``` Result: ``` AI:InvalidArgumentError: invalid ollama provider options. ``` **Test 2: `reasoningEffort: "low"`** ```jsonc "models": { "qwen3-32-opencode": { "options": { "reasoningEffort": "low" } } } ``` Result: ``` "qwen3-32-opencode" does not support thinking. ``` So neither approach works with Ollama's OpenAI-compatible endpoint. ## More Testing with Ollama v0.12.9 I upgraded my Ollama server from v0.11.10 to v0.12.9 and tested the `think` parameter directly with curl: **DeepSeek-R1 - It works:** ```bash curl http://ai:11434/api/chat -d '{ "model": "deepseek-r1:70b", "messages": [{"role": "user", "content": "What is 2+2?"}], "think": false, "stream": false }' # Output: "2 + 2 equals 4." # No <think> blocks at all ``` **Qwen3 - Doesn't work:** ```bash curl http://ai:11434/api/chat -d '{ "model": "qwen3:32b", "messages": [{"role": "user", "content": "What is 2+2?"}], "think": false, "stream": false }' # Still outputs extensive <think> blocks ``` I tested this across: - Native API (`/api/chat`, `/api/generate`) - OpenAI-compatible API (`/v1/chat/completions`) - CLI with `--think=false` - Interactive mode with `/set nothink` None of these work for Qwen3. ## My Summary It looks like DeepSeek-R1 can control thinking with the `think: true/false` parameter, but Qwen3's thinking is just baked into the model and can't be turned off. The `/v1` OpenAI-compatible endpoint doesn't support the `think` parameter, and `reasoningEffort` (whether as a boolean or string) gets rejected.
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 2, 2025):

@SuperSonnix71 we already do that, here is how u can verify:

{
 "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://webhook.site/2638aa86-5a67-4533-90d2-d5fa951c8df5"
      },
      "models": {
        "qwen3-32-opencode": {
          "name": "Qwen3 32B OpenCode",
          "options": {
            "think": false
          }
        }
      }
    }
  },
}

send a request, view the webhook request, You will see in the request body:

{
  "model": "qwen3-32-opencode",
  "max_tokens": 32000,
  "top_p": 1,
  "think": false,
  "messages": [
....],
...
}
@rekram1-node commented on GitHub (Nov 2, 2025): @SuperSonnix71 we already do that, here is how u can verify: ``` { "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "options": { "baseURL": "https://webhook.site/2638aa86-5a67-4533-90d2-d5fa951c8df5" }, "models": { "qwen3-32-opencode": { "name": "Qwen3 32B OpenCode", "options": { "think": false } } } } }, } ``` send a request, view the webhook request, You will see in the request body: ``` { "model": "qwen3-32-opencode", "max_tokens": 32000, "top_p": 1, "think": false, "messages": [ ....], ... } ```
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@SuperSonnix71 commented on GitHub (Nov 2, 2025):

@rekram1-node I ran into an issue with webhook.site but found a workaround.

Webhook.site Issue

When I tried using webhook.site, OpenCode crashed before sending any requests:

ERROR service=acp-command reason=EditBuffer is destroyed Unhandled rejection

I tested with multiple webhook URLs but got the same crash every time.

Local Proxy Workaround

To work around this, I created a simple Python HTTP proxy on localhost:8888 to capture the requests:

#!/usr/bin/env python3
from http.server import HTTPServer, BaseHTTPRequestHandler
import json

class CaptureHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        content_length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(content_length).decode('utf-8')
        print(json.dumps(json.loads(body), indent=2))
        # Return error response
        self.send_response(500)
        self.send_header('Content-Type', 'application/json')
        self.end_headers()
        self.wfile.write(b'{"error": "test proxy"}')

HTTPServer(('0.0.0.0', 8888), CaptureHandler).serve_forever()

I pointed my OpenCode config at this proxy:

"provider": {
  "ollama": {
    "npm": "@ai-sdk/openai-compatible",
    "options": {
      "baseURL": "http://localhost:8888"
    }
  }
}

Captured Request

Here's what OpenCode actually sends:

{
  "model": "qwen3:32b",
  "max_tokens": 32000,
  "top_p": 1,
  "think": false,
  "options": {
    "think": false
  },
  "messages": [...]
}

You were right! OpenCode IS passing "think": false correctly - both at the root level AND inside the options object.

Summary

The webhook test confirms OpenCode is working correctly and passing the think parameter as expected. The issue is that Qwen3's thinking behavior is baked into the model and can't be controlled via the API parameter, unlike DeepSeek-R1 where it works perfectly.

This appears to be a Qwen3 model limitation rather than an OpenCode issue.

@SuperSonnix71 commented on GitHub (Nov 2, 2025): @rekram1-node I ran into an issue with webhook.site but found a workaround. ## Webhook.site Issue When I tried using webhook.site, OpenCode crashed before sending any requests: ``` ERROR service=acp-command reason=EditBuffer is destroyed Unhandled rejection ``` I tested with multiple webhook URLs but got the same crash every time. ## Local Proxy Workaround To work around this, I created a simple Python HTTP proxy on localhost:8888 to capture the requests: ```python #!/usr/bin/env python3 from http.server import HTTPServer, BaseHTTPRequestHandler import json class CaptureHandler(BaseHTTPRequestHandler): def do_POST(self): content_length = int(self.headers.get('Content-Length', 0)) body = self.rfile.read(content_length).decode('utf-8') print(json.dumps(json.loads(body), indent=2)) # Return error response self.send_response(500) self.send_header('Content-Type', 'application/json') self.end_headers() self.wfile.write(b'{"error": "test proxy"}') HTTPServer(('0.0.0.0', 8888), CaptureHandler).serve_forever() ``` I pointed my OpenCode config at this proxy: ```jsonc "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "options": { "baseURL": "http://localhost:8888" } } } ``` ## Captured Request Here's what OpenCode actually sends: ```json { "model": "qwen3:32b", "max_tokens": 32000, "top_p": 1, "think": false, "options": { "think": false }, "messages": [...] } ``` **You were right!** OpenCode IS passing `"think": false` correctly - both at the root level AND inside the options object. ## Summary The webhook test confirms OpenCode is working correctly and passing the `think` parameter as expected. The issue is that Qwen3's thinking behavior is baked into the model and can't be controlled via the API parameter, unlike DeepSeek-R1 where it works perfectly. This appears to be a Qwen3 model limitation rather than an OpenCode issue.
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 2, 2025):

awesome!

@rekram1-node commented on GitHub (Nov 2, 2025): awesome!
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@ParisNeo commented on GitHub (Nov 7, 2025):

Hi. I tried to do the same but with the native ollama library:
response = chat(
model='qwen3',
messages=[{'role': 'user', 'content': 'How many letter r are in strawberry?'}],
think=False,
stream=False,
)

It looks like it thinks even if I say don't!

I need it to be near real time so I need quick answers and this is completely screwing my project.

@ParisNeo commented on GitHub (Nov 7, 2025): Hi. I tried to do the same but with the native ollama library: response = chat( model='qwen3', messages=[{'role': 'user', 'content': 'How many letter r are in strawberry?'}], think=False, stream=False, ) It looks like it thinks even if I say don't! I need it to be near real time so I need quick answers and this is completely screwing my project.
yindo commented 2026-02-16 17:35:53 -05:00
Author
Owner
Copy Link
Copy Source

@Mav3656 commented on GitHub (Dec 31, 2025):

Hello,

I struggled with the same problem (opencode + ollama + qwen3). Thanks to this posts I found the solution: "reasoningEffort": "none"

    "ollama-docker": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },  
      "models": {
        "qwen3:0.6b": {
          "name": "qwen3 without think mode",
          "options": {
            "reasoningEffort": "none"
          }   
        }
      }   
    }

This permits to use opencode with ollama (and any openAI compatible api) with thinking mode disabled!

Enjoy,

@Mav3656 commented on GitHub (Dec 31, 2025): Hello, I struggled with the same problem (opencode + ollama + qwen3). Thanks to this posts I found the solution: **"reasoningEffort": "none"** ``` "ollama-docker": { "npm": "@ai-sdk/openai-compatible", "name": "Ollama", "options": { "baseURL": "http://localhost:11434/v1" }, "models": { "qwen3:0.6b": { "name": "qwen3 without think mode", "options": { "reasoningEffort": "none" } } } } ``` This permits to use opencode with ollama (and any openAI compatible api) with thinking mode disabled! Enjoy,
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#2486
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?