version v0.17.0 Using Qwen Code + Ollama and Qwen 3.6 model LLM- Qwen simply can not complete tasks

[QuantumAIStudio]

What happened?

I have noticed the previous Timeout bug report and fix, im using the Open AI - local LLM call on Local host and noticed recently, the function of Create a task - which previously worked for example create an Ebook in HTML for my store, regarding topic, place the files on my desktop once completed. qwen code then thinks says what it will do, then stops. without any further action. I tried to add the timeout to 60m for both qwen model and ollama .json files had AI re assist with this. yet still getting API Error: terminated (cause: Body Timeout Error)] this update is very broken.

What did you expect to happen?

i expected the AI agent to be less like a chat bot more like an automated agent, asking constant questions, forgetting the original context and prompt after about 2 minutes. This last update has completely broken my qwen code agent. which was working fine previously.

Client information

Client Information

Run qwen to enter the interactive CLI, then run the /about command.

$ qwen /about
# paste output here

Login information

API config is using the open AI API and then points to my local LLM

Anything else we need to know?

No response

[qwen-code-ci-bot]

This appears related to known issues with local model providers and timeout errors:

• API Error: terminated (cause: Body Timeout Error) #4604 - Same "API Error: terminated (cause: Body Timeout Error)" with local model servers. User debug logs showed BrokenPipeError from the model server during tool call generation.
• Tool calling does not work with local model qwen3-30b-a3b #176 - Tool calling issues with local models (Ollama, LM Studio). One user resolved this by increasing the context size in Ollama beyond the default 4096.

To help diagnose this, could you share:

1. Debug logs: Run qwen with the --debug flag and share the logs from a failing session.
2. Configuration: What timeout values did you set, and in which files? (Qwen Code settings.json and Ollama configuration)
3. Ollama context window: What context size is your Qwen 3.6 model running with? Users have reported tool calling failures when context is too small.
4. Server logs: Any errors in the Ollama server logs when the timeout occurs?
5. Version comparison: You mentioned this worked previously - which version last worked, and what changed?

The timeout during task execution often indicates the model server isn't responding within the expected window, or tool call parsing is failing.

[QuantumAIStudio]

config.json

0a4f6e1d-0a79-4383-aa09-3eb54cc50c51.txt

settings.json

tried to troubleshoot for 2-4 hrs + with Visual studio , all settings should be correct VS telling me the model is not responding correctly, and time out occurs in qwen code only. No history, API needs a proxy or something to fix. im unsure.
when i tried to adjust the settings.json file it reverted to an older file. not sure if that caused it possibly also.

can no longer call write to desktop for simple html files. processes dies after 6+ minutes or randomly with the
#4604

tried set QWEN_CODE_HTTP_TIMEOUT=600
set OLLAMA_HTTP_TIMEOUT=600
set OLLAMA_CONTEXT_LENGTH=16384 was previously 32k

system 32gb ram rtx3090 6 core i7 processor.

[zzhenyao]

Hey, I've also tried running a local LLM.

i expected the AI agent to be less like a chat bot more like an automated agent, asking constant questions, forgetting the original context and prompt after about 2 minutes.

your context window is probably just too small.

With an RTX 3090, have you tried llama.cpp? Depending on quantization you can get 128k–256k context, which should fix the context loss issue. The model I'm using is this quantized GGUF from unsloth/Qwen3.6-27B-MTP-GGUF.

As for the timeout / terminated error, you'd probably need Ollama server logs to figure out what's going on there.

Attaching my llama.cpp config for reference.

llama.cpp config

llama.cpp/build/bin/llama-server \
    --model llama.cpp/models/unsloth-Qwen3.6-27B-MTP-GGUF/Qwen3.6-27B-Q4_K_M.gguf \
    --alias "Qwen3.6-27B" \
    --temp 0.6 \
    --top-p 0.95 \
    --top-k 20 \
    --min-p 0.00 \
    --presence_penalty 0.0 \
    --repeat-penalty 1.0 \
    --port 8001 \
    --swa-full \
    --kv-unified \
    --jinja \
    --cache-type-k q8_0 \
    --cache-type-v q8_0 \
    --flash-attn on \
    --fit off \
    --ctx-size 128000 \
    --n-gpu-layers 99 \
    --reasoning on \
    --chat-template-kwargs '{"preserve_thinking": true}' \
    --no-context-shift \
    -np 1 \
    --threads 16 \
    --checkpoint-every-n-tokens 4096 \
    --ctx-checkpoints 46 \
    --spec-type draft-mtp \
    --spec-draft-n-max 2 \
    --spec-draft-p-min 0.75 \
    --slot-prompt-similarity 0.85 \
    -b 8192

[LaZzyMan]

Thanks for the report — this is actually two separate bugs mixed together. Triaging them one at a time:

1. "Says what it will do, then stops" + "forgets context after ~2 minutes"

@zzhenyao has the right diagnosis: your context window is too small for what qwen-code sends. The system prompt + tool descriptors alone are roughly 15–20k tokens before your first user message. Ollama's default num_ctx is 2048, and even at OLLAMA_CONTEXT_LENGTH=16384 you're right at the edge — when the prompt overflows, Ollama silently rolls the KV cache from the front, dropping the system prompt and tool definitions first. That's why the agent "forgets the original context" and then produces narrative text without ever emitting a tool call.

Workaround: bake a larger num_ctx into a derived model so it sticks across restarts:

cat > Modelfile <<'INNER'
FROM <your-qwen3-model>
PARAMETER num_ctx 32768
INNER
ollama create qwen3-32k -f Modelfile

Then point qwen-code at qwen3-32k. On a 3090 (24 GB) you should comfortably go 32k–64k depending on the model size and quant. zzhenyao's llama.cpp config above is also a solid alternative — llama.cpp's tool-call handling tends to be more robust than Ollama's for OpenAI-compat clients.

2. "API Error: terminated (cause: Body Timeout Error)"

This one is a client-side bug, not a model/server problem. Two things to know:

• QWEN_CODE_HTTP_TIMEOUT and OLLAMA_HTTP_TIMEOUT do not exist in qwen-code. Neither env var is read anywhere in the codebase — setting them has no effect. Sorry that wasn't documented.
• The timeout you're hitting is undici's built-in 5-minute bodyTimeout in Node's fetch (idle time between SSE chunks). Long reasoning silences from qwen3 — especially with a cold KV cache on a large prompt — trip it. Configuring the Ollama side does nothing because the abort comes from the client.

There's already an in-flight fix for this in #4667 (and an earlier alternative in #4605) — once one of those lands you'll be able to set generationConfig.bodyTimeout in settings.json to disable it.

Until then, the only client-side knob that does anything is the OpenAI SDK timeout (2 min default), which is separate from the undici bodyTimeout but still worth raising:

{
  "model": {
    "generationConfig": {
      "timeout": 600000
    }
  }
}

Triage info that would help

If the num_ctx fix above doesn't resolve the "says it then stops" symptom, please re-run with --debug after the stall and share:

1. The final finish_reason in the stream (length, stop, tool_calls, error_finish)
2. Ollama server output during the stall — is the model still generating tokens, or did it stop?
3. Output of ollama show <model> --modelfile | grep num_ctx

That'll tell us whether you're hitting the context-overflow path, a <think>-tag parsing edge case, or something else.

[QuantumAIStudio]

I will keep it short and sweet. Thanks so much to both of you. ive updated the context window back to 32k in a new variant model tied into qwen code and updated the settings accordingly. increased the ctx num issue updated the timeout windows to 600000 or so using VS extensions. I ran a test file and the reasoning, write calling and agent performed well again. there was no timeout issue with the smaller task completed ok yet the larger task unfortunately still getting API timeout issues after about 7 mins

[doudouOUC]

Root Cause Identified

This is the same underlying issue as #4604.

What's happening

The Body Timeout Error is caused by undici's default 300-second idle timeout between SSE streaming chunks. This is an idle timer — if no data arrives for 300 consecutive seconds during streaming, the connection is killed.

Why your timeout settings don't help

The httpTimeout and requestTimeout fields in your settings are not recognized by Qwen Code. The valid field is generationConfig.timeout inside the model provider config:

{
  "modelProviders": {
    "openai": [{
      "id": "qwen3.6",
      "generationConfig": {
        "timeout": 600000
      }
    }]
  }
}

However, even with the correct field, this setting only controls how long the client waits for the initial HTTP 200 response from Ollama. Once Ollama responds and streaming begins, that timer is cleared. The streaming body idle timeout (300s) is hardcoded in Node.js's undici HTTP client and is not configurable today.

Why it may have worked before

You mentioned reducing context from 32k to 16k. With a smaller context window, the model is more likely to hit the output limit mid-generation. When the tool call JSON is truncated (confirmed by server logs in the related #4604: "tool text was likely truncated mid-generation"), the server stops sending data while the client is still waiting — triggering the 300s idle timeout. At 32k context, the model had enough room to complete tool calls before hitting the limit, so the issue was less likely to occur.

The code gap

Runtime path	Body idle timeout	Result
Bun	disabled	✓
Node.js + proxy	disabled	✓
Node.js, no proxy	300s (default)	✗ triggers with slow local models

Since you're connecting directly to localhost:11434 without a proxy, you're on the third path.

Fix

We've submitted a fix in #4667 that adds a configurable generationConfig.bodyTimeout field (default 0 = disabled). This disables the 300s body timeout for all Node.js users, matching the proxy and Bun paths.

Related: #4604