Out of memory when working with Qwen Code in a session with a local Qwen 3.6 model running with llama.cpp under Linux

[sergehuber]

What happened?

Working with Qwen code with a local qwen3.6 model using llama.cpp when I got outofmemory. I resumed my session and tried to continue working and this happened a second time hence my report.

What did you expect to happen?

To not do an OOM and continue working normally :)

Client information

Qwen Code: 0.15.11 (782403d)
Runtime: Node.js v24.14.0 / npm 11.9.0
OS: linux x64 (6.17.0-23-generic)
Auth: API Key - openai
Base URL: http://localhost:8080/v1
Model: qwen-3.5-64k
Fast Model: qwen-3.5-64k
Session ID: d67c09cf-263f-4995-9873-ab5cabc22b2a
Sandbox: no sandbox
Proxy: no proxy
Memory Usage: 315.0 MB

Login information

No response

Anything else we need to know?

I didn't have this issue with the exact same configuration on 0.15.10

[qwen-code-ci-bot]

This appears related to existing performance discussions:

• qwen vs. llama.cpp/web performance #4028 - Performance comparison between qwen and llama.cpp/webui with local models

Your report includes helpful details (version regression from 0.15.10 to 0.15.11, full environment info). The maintainers may want to know:

• Does this occur on every session resume, or only after specific operations?
• What is the approximate memory usage before the OOM occurs?
• Are you able to reproduce this consistently with a specific prompt pattern or task type?

This information would help isolate whether this is a memory leak, context accumulation issue, or model loading regression.

[sergehuber]

I tried increasing the memory to 8GB and still got an error :
<--- Last few GCs --->

[1296864:0x169c2000] 3653082 ms: Scavenge (interleaved) 8138.0 (8162.8) -> 8127.5 (8199.3) MB, pooled: 0 MB, 11.94 / 0.04 ms (average mu = 0.339, current mu = 0.319) allocation failure;
[1296864:0x169c2000] 3654089 ms: Mark-Compact (reduce) 8137.7 (8199.8) -> 8109.1 (8135.8) MB, pooled: 0 MB, 33.62 / 5.17 ms (+ 817.9 ms in 165 steps since start of marking, biggest step 6.6 ms, walltime since start of marking 869 ms) (average mu = 0.326
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

1: 0x735eec node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
2: 0xbafc40 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
3: 0xbafd2f [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
4: 0xe48825 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
5: 0xe48852 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
6: 0xe48b4a [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
7: 0xe5906a [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
8: 0xe5d410 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
9: 0x18efec1 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
l

This is reproduceable by resume a long session and letting it work for a while in YOLO mode. No special prompt pattern but I do have a file with a list of tasks to implement and I simply tell it to work through it.

[danielgue2]

I am using qwen code as well since weeks, and very recently, after an update, I suddenly regularly get out of memory fatal errors which I never got before. I hope this helps.

[yiliang114]

Thanks for the detailed reproduction steps and environment info — very helpful.

We have an open fix in #4286 that addresses this class of OOM. The root cause we identified: the main send loop calls structuredClone(this.history) up to 4 times per iteration. In long sessions (especially in YOLO/auto-accept mode with many rapid consecutive iterations), the transient memory peaks from these deep clones exceed V8's heap headroom — even at 8 GB.

A few questions to help confirm this is the same root cause:

1. Timing: Does the OOM tend to happen shortly after resuming (within the first few interactions), or only after extended work?
2. Auto-compaction: Is your context compression set to auto (the default)? Does the OOM happen around the time you see a "[compacting conversation]" message?
3. Context window usage: You're using qwen-3.5-64k — is the 64k context window close to capacity when the crash occurs?

Temporary workarounds:

• Start fresh sessions instead of resuming (smaller history = less clone pressure)
• NODE_OPTIONS="--max-old-space-size=16384" (buys headroom but doesn't fix the root cause)

Will update this issue once #4286 lands.

[sergehuber]

1. Usually after some extended work
2. I do have context compression to the default. No I don't see necessarily a compating conversation it seems, I'll check on next occurence to be sure, but with 8GB I do get a warning when the memory usage reaches 7GB that says that if it crashes I should report a bug.
3. That's a good question I didn't check, I'll check on next occurence.

[sergehuber]

Just got another one, here are the last logs of what it was doing (nothing about context compression, and as you can see the context was at 63%:

` ⠦ Don't panic... (47s · ↑ 9.3k tokens · esc to cancel)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Type your message or @path/to/file
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
auto-accept edits (shift + tab to cycle) 63.2% context used

<--- Last few GCs --->

[2522053:0x28efb000] 17249901 ms: Scavenge (interleaved) 8122.8 (8154.9) -> 8117.8 (8188.4) MB, pooled: 0 MB, 26.48 / 0.02 ms (average mu = 0.347, current mu = 0.334) allocation failure;
[2522053:0x28efb000] 17250992 ms: Mark-Compact (reduce) 8128.5 (8189.1) -> 8108.9 (8122.4) MB, pooled: 0 MB, 32.70 / 3.09 ms (+ 828.1 ms in 166 steps since start of marking, biggest step 5.3 ms, walltime since start of marking 901 ms) (average mu = 0.337
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

1: 0x735eec node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
2: 0xbafc40 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
3: 0xbafd2f [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
4: 0xe48825 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
5: 0xe48852 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
6: 0xe48b4a [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
7: 0xe5906a [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
8: 0xe5d410 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
9: 0x18efec1 [/home/loom/.nvm/versions/node/v24.14.0/bin/node]
`

[sergehuber]

Here are my llama.cpp settings for running the model on my local RTX 3090 24GB RAM (usually works wonderfully well with qwen code until this bug appeared in 0.15.11) :

llama-server -hf unsloth/Qwen3.6-27B-GGUF --port 8080 --host 0.0.0.0 --verbosity 3 --ctx-size 262144 --batch-size 512 --cache-type-k q4_0 --cache-type-v q4_0 --flash-attn auto --parallel 2 --ubatch-size 512 --jinja --metrics

Note the parallel 2 which is atypical.