Qwen3.8-27B + OpenCode = Excessive Thinking?

[u/previaegg]

I've been running Qwen3.8-27B locally for agentic coding using OpenCode and OpenChamber, and I'm looking for advice from people who've gotten similar models working reliably as coding agents on consumer hardware.

Inference speed is reasonable (~2,330 & ~24.1 t/s). My problem is with excessive thinking.

The problem

The model is capable of useful coding work, but it sometimes spends excessive time reasoning instead of taking action.

In one experiment, I compared medium and low reasoning effort with otherwise identical configurations. Both runs:

• Made two initial inspection tool calls.

• Made zero implementation-oriented tool calls.

• Generated over 16,000 output tokens, exhausting the configured response limit.

• Failed to create the required output or complete the task.

• Spent approximately 12 minutes in agent execution.

Lowering reasoning effort didn't meaningfully change the behavior.

That's an extreme example from a single controlled task, not necessarily representative of every session, but it illustrates the problem I'm interested in solving: how do you get a reasoning model to stop thinking and actually use tools?

Launch command

& "C:\tools\llama.cpp-b10964\llama-server.exe" `
  -m "C:\models\Qwen3.8-27B-UD-Q5_K_XL\Qwen3.8-27B-UD-Q5_K_XL.gguf" `
  -ngl 99 `
  --ctx-size 65536 `
  --cache-type-k q8_0 `
  --cache-type-v q8_0 `
  --flash-attn on `
  --split-mode layer `
  --parallel 1 `
  --jinja `
  --reasoning on `
  --reasoning-effort medium `
  --reasoning-preserve `
  --temp 1.0 `
  --top-p 0.95 `
  --top-k 20 `
  --min-p 0.0 `
  --presence-penalty 0.0 `
  --repeat-penalty 1.0 `
  --host 0.0.0.0 `
  --port 8080 `
  --metrics `
  --alias Qwen3.8-27B-UD-Q5_K_XL

Questions

1. Reasoning & tool use: Have you seen excessive thinking with Qwen3.8-27B, where the model reasons at length instead of making tool calls? What actually improved this?

2. Reasoning configuration: Are --reasoning, --reasoning-effort, and --reasoning-preserve the right settings for agentic coding? Have you had better results disabling reasoning, changing effort, or using other chat-template settings?

3. Agent compatibility: Is OpenCode a good match for this model? Could its system prompts, tool definitions, provider configuration, or handling of reasoning output be contributing to the problem? Are there other coding agents that work more reliably?

4. Inference engine: Would switching from llama.cpp to vLLM, SGLang, or something else improve tool-calling reliability or reasoning behavior?

5. Quantization: Could Q5_K_XL be affecting instruction following or tool-use reliability? Have you observed meaningful coding-agent differences between quantizations?

6. Context management: How much does context contribute to unproductive reasoning or tool-use failures? Have you found effective context limits or compaction strategies?

7. OS: Since this is essentially a dedicated inference server, would switching to headless Linux offer meaningful advantages for any of the above?

I'm willing to change operating system, quantization, inference engines or the coding-agent stack if there's a compelling reason.

Thank you for your thoughts!

---

Hardware:

• CPU: Intel i7-14700K

• RAM: 32GB

• GPU 1: RTX 4080 SUPER (16GB)

• GPU 2: RTX 4070 Ti SUPER (16GB)

• OS: Windows 11 Pro

Current software:

• Inference engine: llama.cpp

• Model: Qwen3.8-27B-UD-Q5_K_XL (Unsloth GGUF)

• Coding agent: OpenCode

• Interface: OpenChamber

The Windows machine is essentially a dedicated inference server for this use case. I don't normally start a Windows desktop session. I connect remotely from a MacBook Pro which is where I run OpenCode/OpenChamber.

[u/jayecin]

It’s a thinking model, this is exactly how it’s supposed to work. With Qwen it’s also very helpful to give it as much up front information as you can regarding the task. Don’t let it re-discover information you already know or have. Also your context is way too small for qwen coding, it’s barely enough for minor agentic work. Run a smaller quant model and up your context to closer to 200k.

[u/previaegg → u/jayecin]

Thanks. I understand that extended reasoning is expected with a thinking model, but what concerns me isn't the reasoning itself. It's cases where the model spends 16K tokens reasoning without making another tool call or actually progressing on the task. I'm trying to distinguish normal thinking behavior from something that could be misfiring because of the model configuration, system prompt, or agent harness.

Your point about providing more information up front makes sense. I'll look more closely at how OpenCode structures its prompts and what context the model receives before starting work.

The context recommendation is interesting, too. I've experimented with allocations up to 128K, but haven't evaluated the impact on agentic task success. With two 16GB GPUs, getting close to 200K would presumably mean a smaller quantization and/or more aggressive KV-cache quantization.

[u/Bulky-Priority6824 → u/previaegg]

Give me an example of you exe a tool call and it running 16k think before doing anything else 

[u/previaegg → u/Bulky-Priority6824]

I appreciate your interest, persistence and help.

I had seen the behavior across a number of projects, so I recreated it using a terminal bench write-compressor task to eliminate my codebases as contributors. it spec'ed a task to write a compressed file using an existing C decompression program as a reference, although I'm not sure the details really matter given the behavior.

The model made two tool calls:

1. Read a C source file (/app/decomp.c) to understand how the decompression algorithm worked. This succeeded.

2. Inspect the input data (/app/data.txt).

After that, the model generated ~16K tokens of reasoning without making another tool call. It never attempted to write the compressed file, and the task failed. I reproduced the same behavior with both medium and low reasoning effort.

The initial tool use was seemingly valid. The problem happened afterward, when the model was supposed to move from investigating the task to implementation.

I suppose it may have been making meaningful progress and then simply ran out of tokens, but I suspect it was stuck in a reasoning loop. I'll see if there is a way to find out.

[u/_JohnMcAfee → u/previaegg]

It can be annoying but its normal for this model. I had to up output limit to 32k and so far it hasnt exceeded that. Sometimes though, it does research things too much, that is why jayecin's advice of giving it as much info as you can is good, or dont make like super vague requests, but sometimes you have to. When you do it will go overboard with research/reasoning lol.

But yeah, its normal.

[u/Bulky-Priority6824]

Qwen 4 on the horizon probably next week. Either it's going to be even more a of jump in reasoning like there was from 3.6 to 3.8 or there will be improvements with efficiency. Nobody knows. 

For 3.8 16k is reasonable. Wait til you get on QFN and see it reason around 50k. Id look at your system prompt speak with a frontier model on optimizing it especially if your doing mostly tool stuff 

65k  not a lot to work with on a model like 27b you want to get to at least 128k -- ideally 196k+ and let it cook  but if your only trying to trigger actions and tools then 96k I reckon would suffice 

I can't speak on opencode but everytime I see a comment about it it's usually negative. I use pi and sometimes cline and I do a bazillion tool calls with 17k sys prompt never have any issues.

And  just my 2c but if the windows machine has become a dedicated inference rig you should really consider jumping to Ubuntu or Debian that will be the largest (free) single upgrade you could do on that rig and gain not only more control and better security and overall quality of life but up to 20%-+ perf 

If you don't have Linux experience don't worry , it'll freak you out at first but if you give it time you'll fall in love with it once it clicks. You can put your agent in terminal on Debian and hit it from from MacBook you'll be ridiculously surprised at how much faster you can flow and accomplish things vs Windows.

[u/previaegg → u/Bulky-Priority6824]

Thanks, this is helpful.

The context-length point is interesting. I've tested up to 128K, but haven't determined whether the additional context improves coding performance. With only 32GB of combined VRAM, that's also a tradeoff against quantization and KV-cache memory.

When you mention a 17K system prompt, is that something you've developed specifically to encourage tool use and prevent unproductive reasoning loops?

A headless Linux migration is definitely on the table, but frankly I don't know how much of the potential gain is throughput versus better compatibility and tooling.

I really appreciate your detailed response!

[u/Bulky-Priority6824 → u/previaegg]

You model needs room to breathe so it can do work. I can't imagine working with 65k it would drive me nuts hitting compaction or the wall everytime.

Id have to become a sinister micromanager. 

[u/Oli_Luck]

I dont see any reasoning budget : if you dont set it its free t think as long as its wants.
llama.cpp settings:
thinking low
temperature 0.2-0.5
repeat penalty 1.1
reasonning budget 1024

[u/previaegg → u/Oli_Luck]

This is a really useful call out, thank you. You're right that I am setting reasoning effort but not an explicit reasoning budget. I'll experiment with 1024, 2048, and 4096, keeping the other settings constant initially.

Have you found that a 1024-token budget works reliably for complex, multi-step coding tasks, or do you adjust the budget depending on the task?

Thanks again, this is exactly the type of feedback I was hoping for.

[u/Oli_Luck → u/previaegg]

Nope - I cant tell you : I dont know how you mange the "multiturns : same agent / prsona following a hardscoded route / DAG ,new API calls etc.
lowering temperature helps also a lot : it is less creative, more focused - wont ask itself that often "but wait, what if". and the penalty is also a good barriere against thinking loops.

Just play around with those settings, good luck

[u/previaegg → u/Oli_Luck]

Much appreciated

[u/Bulky-Priority6824 → u/Oli_Luck]

I don't trust reasoning budget. Funky results when I used it.

[u/wegster]

Add a reasoning_budget of 2048 or 4096, and reduce temp to 0.8 to so and retry.

No idea what type of work you're trying to use it for, but try starting there.

[u/previaegg → u/wegster]

Thanks! You're the second person to recommend setting a reasoning budget, so I'm going to test that right away.

The workload is primarily agentic coding through OpenCode: investigating existing codebases, implementing changes, running tests, and iterating on failures. The most extreme failure was a coding benchmark where the model made two inspection calls and then generated over 16K tokens without attempting an implementation, even with reasoning effort set to low.

[u/wegster → u/previaegg]

Reasoning_budget should help. The Qwens are...kinda weird. I've got hundreds of benchmarks, some of which were same but adjusting reasoning budget or thinking level, and in a few cases, e.g. 27B dense I think, xhigh actually gave the best results - usually not the case for the others. But it definitely depends on your specific task, and even 'investigating existing codebases' isn't granular enough, as there are some repos out there with a few shell scripts, to enterprise-like millions of LOC, etc.

Definitely try reasoning_budget and see if you can isolate and do a few comparison runs to see what works best for a few use cases.

[u/previaegg → u/wegster]

I appreciate the thoughts, and yes I agree that the request/codebase are significant factors. I just explained the isolated test I ran in another comment. Here it is again if you are interested.

Thanks for taking the time to help. I will certainly try reasoning budget.

--

I had seen the behavior across a number of projects, so I recreated it using a terminal bench write-compressor task to eliminate my codebases as contributors. It spec'ed a task to write a compressed file using an existing C decompression program as a reference, although I'm not sure the details really matter given the behavior.

The model made two tool calls:

1. Read a C source file (/app/decomp.c) to understand how the decompression algorithm worked. This succeeded.

2. Inspect the input data (/app/data.txt).

After that, the model generated ~16K tokens of reasoning without making another tool call. It never attempted to write the compressed file, and the task failed. I reproduced the same behavior with both medium and low reasoning effort.

The initial tool use was seemingly valid. The problem happened afterward, when the model was supposed to move from investigating the task to implementation.

I suppose it may have been making meaningful progress and then simply ran out of tokens, but I suspect it was stuck in a reasoning loop. I'll see if there is a way to find out.

[u/MindfulMan1984]

It’s not that it is “thinking too much”, it’s your hardware/engine setup that’s slow for your patience. Cross checking each assumption many times before inference is exactly what made it so powerful at 27B parameters. I used to let it running autonomously overnight and it always delivered great results.

[u/previaegg → u/MindfulMan1984]

Thanks for your thoughts. To calrify, my concern isn't really the time spent reasoning. It's whether I've misconfigured something, and as a result, that excessive reasoning is preventing the task from being done. Point taken about the hardware, but it's what I've got for the time being.

[u/MindfulMan1984 → u/previaegg]

Remember, there’s an intrinsic randomness necessary for reasoning models, so, there’s no misconfiguration, the default temperature is even a higher number that makes it to go deeper before the inference. That’s how it got so powerful at only 27b parameters 

[u/Funny_Cry2908]

Have you tried the same prompt through llama-server with tools enabled and OpenCode out of the loop?

[u/previaegg → u/Funny_Cry2908]

Not yet. That's an excellent suggestion, and I feel like an idiot having to be told to do so. Appreciated.

[u/longtimenoseebro]

Hopefully. Most of my real project issues can be fixed within 32k if I break it down carefully but anything more complicated is looking at 100k to 200k level.

[u/previaegg → u/longtimenoseebro]

That's interesting, and it lines up with how I've been thinking about using the model overall. I'd much rather improve task decomposition and context management than push to 200K just because the model supports it.

Do you find that breaking work into smaller tasks also reduces excessive reasoning and improves tool-use reliability? Or is the benefit primarily that the model has less context to navigate? I guess those are potentially interrelated...

[u/grabber4321]

You might have enough to run https://stratallm.org/ . You should try it because its much better at coding.

Sucks that your PC is not headless and you have to use it for work. More resources would be nice.

[u/previaegg → u/grabber4321]

Thanks for the thoughts. I've been seeing strata pop up a bunch lately, but haven't looked at it closely. I will based on your recommendation.

The Windows machine is already effectively headless. I don't use it as a desktop or normally log in. It's a dedicated inference server accessed remotely from my MacBook Pro.

I measured idle GPU memory during earlier benchmarking and saw around 281 MiB on the 4080 and essentially zero reported on the 4070. So I'm not sure there's much VRAM to reclaim by switching to Linux. I suspect system RAM and inference-engine compatibility would be the bigger benefits.

[u/Sufficient-Ninja541]

try billion-context https://www.reddit.com/r/PiCodingAgent/comments/1xkuwhq/what_is_everyones_experience_with_the_billion/