github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 08:30:05 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #15831] API: Add max as valid value for top-level think parameter #56603

New Issue
Open
opened 2026-04-29 11:05:10 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-29 11:05:10 -05:00
Owner
Copy Link

Originally created by @g0st1n on GitHub (Apr 27, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/15831

Summary

Currently, the top-level think parameter in API requests accepts true, false, low, medium, and high (per docs). However, there is no max level, which limits the ability to request the maximum reasoning effort from thinking-capable models.

This is particularly problematic for downstream clients that need to pass reasoning levels through a standardized API field.

Evidence

Test 1 — top-level think: "max" with Ollama Cloud (deepseek-v4-flash:cloud):

curl -X POST "http://localhost:11434/api/chat" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash:cloud",
    "messages": [{"role": "user", "content": "hi"}],
    "stream": false,
    "think": "max"
  }'

Result: ❌ {"error":"invalid think value: \"max\" (must be \"high\", \"medium\", \"low\", true, or false)"}

Test 2 — options.think: "max" with Ollama Cloud (deepseek-v4-flash:cloud):

curl -X POST "http://localhost:11434/api/chat" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash:cloud",
    "messages": [{"role": "user", "content": "hi"}],
    "stream": false,
    "options": {"think": "max"}
  }'

Result: ✅ Returns thinking content successfully. The response includes a full thinking trace and final content.

Key finding

The max value is only accepted inside options.think, not at the top level. This creates an API inconsistency:

  • The top-level think field is the documented and standardized way to control reasoning
  • Downstream tools rely on think: false at the top level to disable thinking reliably
  • Moving the parameter into options.think breaks the semantic contract for clients that need to toggle thinking on/off via a single field
  • Some models (like GPT-OSS) already use low/medium/high levels at the top level — adding max completes the spectrum and unifies the API

Proposed behavior

Extend the valid values for the top-level think parameter:

"think": true | false | "low" | "medium" | "high" | "max"

Where max requests the highest available reasoning effort from the model, beyond high.

Impact

  • Ollama Cloud already accepts options: {"think": "max"} — formalizing max at the top level would unify the API between local and cloud
  • Downstream clients could expose max reasoning without workarounds or unsafe mappings (max → high)
  • Users get access to the full reasoning capability of models like DeepSeek-v4-flash through the standardized top-level field

Related

Originally created by @g0st1n on GitHub (Apr 27, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/15831 ## Summary Currently, the top-level `think` parameter in API requests accepts `true`, `false`, `low`, `medium`, and `high` (per [docs](https://docs.ollama.com/capabilities/thinking)). However, **there is no `max` level**, which limits the ability to request the maximum reasoning effort from thinking-capable models. This is particularly problematic for downstream clients that need to pass reasoning levels through a standardized API field. ## Evidence **Test 1 — top-level `think: "max"` with Ollama Cloud (`deepseek-v4-flash:cloud`):** ```bash curl -X POST "http://localhost:11434/api/chat" \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-v4-flash:cloud", "messages": [{"role": "user", "content": "hi"}], "stream": false, "think": "max" }' ``` **Result:** ❌ `{"error":"invalid think value: \"max\" (must be \"high\", \"medium\", \"low\", true, or false)"}` **Test 2 — `options.think: "max"` with Ollama Cloud (`deepseek-v4-flash:cloud`):** ```bash curl -X POST "http://localhost:11434/api/chat" \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-v4-flash:cloud", "messages": [{"role": "user", "content": "hi"}], "stream": false, "options": {"think": "max"} }' ``` **Result:** ✅ Returns thinking content successfully. The response includes a full `thinking` trace and final `content`. ## Key finding The `max` value is **only accepted inside `options.think`**, not at the top level. This creates an API inconsistency: - The top-level `think` field is the **documented and standardized** way to control reasoning - Downstream tools rely on `think: false` at the top level to **disable** thinking reliably - Moving the parameter into `options.think` breaks the semantic contract for clients that need to toggle thinking on/off via a single field - Some models (like GPT-OSS) already use `low`/`medium`/`high` levels at the top level — adding `max` completes the spectrum and unifies the API ## Proposed behavior Extend the valid values for the top-level `think` parameter: ```jsonc "think": true | false | "low" | "medium" | "high" | "max" ``` Where `max` requests the highest available reasoning effort from the model, beyond `high`. ## Impact - **Ollama Cloud** already accepts `options: {"think": "max"}` — formalizing `max` at the top level would unify the API between local and cloud - **Downstream clients** could expose `max` reasoning without workarounds or unsafe mappings (`max` → `high`) - **Users** get access to the full reasoning capability of models like DeepSeek-v4-flash through the standardized top-level field ## Related - OpenClaw issue [openclaw/openclaw#72402](https://github.com/openclaw/openclaw/issues/72402) — downstream impact discussion - [Ollama Thinking docs](https://docs.ollama.com/capabilities/thinking)
GiteaMirror commented 2026-04-29 11:05:11 -05:00
Author
Owner
Copy Link

@solicomo commented on GitHub (Apr 27, 2026):

true looks redundant to me, and it cannot tell which level is expected.

We can go with

"think": false | "low" | "medium" | "high" | "max"
<!-- gh-comment-id:4330201085 --> @solicomo commented on GitHub (Apr 27, 2026): `true` looks redundant to me, and it cannot tell which level is expected. We can go with ``` "think": false | "low" | "medium" | "high" | "max" ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#56603
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?