A user details their experiment to test the Qwen3.8-27B AI model in a coding agent setup using EvoX, comparing reasoning levels and soliciting feedback on test design.
I got Qwen3.8-27B running locally and connected it to EvoX. Basic chat works. That is the easy part. I am trying to find out whether I would trust it once a coding task gets messy and the agent has to read a repository, call tools, recover from a bad first attempt, and stay on track for more than one turn. EvoX is the harness I already have connected to the local model. I am keeping the comparison inside that setup and focusing on how Qwen behaves once a repository and tools enter the loop. This is not meant to rank desktop agent apps. Most of my own experiments are small web tools, so I chose tasks where I can check both the code and the result without pretending to run a production benchmark. A single impressive prompt would not tell me much either. Most of the early Qwen3.8-27B tests I have read mention the same annoyance. Xhigh can disappear into reasoning for a long time, while medium often looks more practical. I want the reasoning level in the main comparison. I will start with a screenshot-to-page build. Low, medium, and xhigh will each get the same reference image and prompt in a clean copy of one frontend repository. The tools, context limit, and timeout stay fixed. EvoX experience reuse will be off so the later runs cannot inherit a useful hint from the first one. I picked this task because it can fail in obvious ways. A page may look close at first glance while the buttons do nothing or the assets are broken. The model may also spend half its time adding features I never asked for. I will compare the first working render with the final screenshot, then check the build output, missing interactions, correction turns, and total time. I also want the reasoning token count and time to the first tool call. A good page is much less appealing if the model spends fifteen minutes planning before it touches a file. If one setting gives a clearly better balance of result and waiting time, I will give it a harder second job and build the USGS earthquake dashboard. I will start with a saved GeoJSON fixture so the data stays fixed, then switch to the live feed. The app has to render the globe, map magnitude and depth correctly, filter the visible events, open the right details, and keep the timeline usable. I will keep the repeated commands, browser checks, unrelated edits, and any failures that appear only after the live feed is enabled. Does that sound like a fair test, or am I missing an important control or failure case? If you have used Qwen3.8-27B in an agent harness, what else would you measure, and what task would you try instead?
A user reports difficulties using the Qwen 3.8 27B model for agentic coding tasks, noting inefficiencies and errors compared to other models, and seeks advice on potential setup issues.
User feedback indicates that Qwen3.8-27B Q6 demonstrates high performance in agentic coding tasks, maintaining 60-63 tokens/s over 20 hours on dual NVIDIA GPUs.
A user's detailed comparison of Qwen3.8 and Qwen3.6 models in coding tasks, highlighting improvements in instruction following and tracing for Qwen3.8, but with inefficiencies in reasoning.
The article reports on a benchmark comparing Qwen 3.8 27B with other models in agentic coding, highlighting that medium reasoning mode offers better efficiency without significant score improvements in xhigh mode.
User reports positive experience with Qwen 35b a3b for agentic coding tasks, noting it outperforms Gemma4 26b in their use case and works well for demo/data analytics, especially in agentic mode versus chat.