Qwen3.6 27B eats your context before the session warms up
Running Qwen3.6 27B with Opencode? The model's appetite for context tokens can gut your usable window fast. Here's what's happening and how to push back.
A Reddit thread on r/LocalLLaMA surfaced a problem that will be familiar to anyone running Qwen3.6 27B through Opencode: the model reportedly burns through 45–55k tokens just on initial context load, according to the post. If you’ve capped your session at 105k tokens (as the poster apparently had), that leaves you maybe 50–60k tokens of actual working room before the model starts forgetting what it was doing. Take those token figures as one user’s observation, not a controlled measurement, since the source article couldn’t be fetched for verification.
The underlying physics here are real though. Qwen3.6-27B natively supports a 262K context window, but the Qwen team itself warns that you need at least 128K to preserve the model’s thinking capabilities, and to reduce context if you hit OOM. Running Q8_K_XL at 105k is, by the model maker’s own guidance, already operating below the floor for reliable reasoning. The quant choice is part of the trap: Q8 is the highest fidelity GGUF you can run, which means the KV cache is expensive and your available context shrinks accordingly. Drop to Q4_K_XL and you get more headroom; lose a little quality. That’s the tradeoff, and there’s no free lunch on mid-range hardware.
If this setup is in your rotation, a few things worth trying: lower the quant to reclaim context budget, set a hard --ctx-size that leaves real room for multi-turn work (not just the initial load), and consider whether Opencode’s default context handling is what’s eating tokens before you’ve written a line. The fix is usually one config line. The frustrating part is finding which one.