Subagents often want to do more than they are told to

[danielfdickinson]

I'm not sure if this is something I can do anything about, but I have noticed that often the architect/orchestrator will give a sub-agent a specific edit task, but the agent wants to 'analyze more fully to understand context' and sometimes does things wildly different from what the architect requested.

For example: I have been updating a README.md to match the current repo state, and when experimenting with a fast but not very smart subagent, it decided it wasn't going to the edit, but instead rewrite the README.md with it's own version of an update (which being a not terribly good model was much worse than what the orchestrator/architect has come up with).

In that instance I was using ministral-3:14b as the architect and lfm2.5-thinking as the subagent model, with ollama as the server.

However, I have observed this even when using qwen3.6 for both architect and subagent.

[mlhher]

This is expected for smaller models there is not much that the harness can do if the model wants to do it.
In my tests (seemingly contrary to yours) at least Qwen3.6-35B-A3B was saying for example "... my code does not compile but the import errors were there before so I will just return a summary ...".

If it degrades your workflow I suggest using a smarter model as the subagent. This is explicitly an instruction following issue outside of our control.

[danielfdickinson]

Thanks. I was wondering if it was/is just a property of the smaller models. To clarify on the Qwen - it's much better at following the prompts from the architect, but still does a lot of re-doing the analyzing that the architect did. I guess that is not really avoidable.

I'm also learning that I need to spend some time with the 'worktree' options so that I can have late work on tasks in the background, rather than trying to use it as an interactive tool, at least when using local LLM servers (haven't tried the online services directly yet, to see if they respond more quickly; from what I've seen with GitLab's code reviews though, the 'thinking' still takes a while).

[giveen]

My recommendations for models:
Qwen3.6-35B-A3B - Primary
Qwen3.6-27B - Subagent

I use llama-swap to handle the switching

[kn0xx01]

I'm testing this... using config.json to configure models, and in-app options to switch... and a "caveman" mode.
probably feature worth...

[aa956]

Interesting, I'm also using llama-swap but the switching slow so I'm using Qwen3.6 27B in thinking mode as primary model and instruct mode as subagent model.

As configuration is done by llama-swap proxy (rewriting request headers) there's no need to reload the llama-server between thinking/instruct switches.

Example for 24Gb VRAM:

late config (direnv's .envrc):

export OPENAI_BASE_URL="http://localhost:8080"
export OPENAI_MODEL="qwen3.6-27b-q4:reasoning-coding"
export LATE_SUBAGENT_MODEL="qwen3.6-27b-q4:instruct-general"

llama-swap config:

models:
  "qwen3.6-27b-q4":
    name: ${MODEL_ID}
    filters:
      stripParams: "temperature, top_k, top_p, min_p, repeat_penalty, presence_penalty"
      setParams:
        # Default: reasoning-coding (precise coding with thinking enabled)
        presence_penalty: 0.0
      setParamsByID:
        "${MODEL_ID}:reasoning-coding":
          temperature: 0.6
        "${MODEL_ID}:reasoning-general":
          temperature: 1.0
          presence_penalty: 1.5
        "${MODEL_ID}:instruct-general":
          chat_template_kwargs:
            enable_thinking: false
          temperature: 0.7
          top_p: 0.8
          presence_penalty: 1.5
        "${MODEL_ID}:instruct-reasoning":
          chat_template_kwargs:
            enable_thinking: false
          temperature: 1.0
          top_p: 1.0
          presence_penalty: 1.5
    cmd: |
      ./bin/llama-server
      --port ${PORT}
      --jinja
      --flash-attn on
      --n-gpu-layers 999
      --cache-type-k q8_0
      --cache-type-v q8_0
      --spec-type ngram-mod
      --spec-ngram-mod-n-match 24
      --spec-draft-n-min 48
      --spec-draft-n-max 64
      --temp 0.6
      --top-p 0.95
      --top-k 20
      --min-p 0.0
      --repeat-penalty 1.0
      --presence-penalty 0.0
      --reasoning on
      --image-min-tokens 768
      --image-max-tokens 1024
      --fit on
      --fit-ctx 114688
      --fit-target 2048
      --no-mmproj-offload
      --chat-template-kwargs '{"preserve_thinking": true}'
      --model ./models/Qwen_Qwen3.6-27B-Q4_K_M.gguf
      --mmproj ./models/mmproj-Qwen_Qwen3.6-27B-bf16.gguf

[danielfdickinson]

I discovered that using late with OVHcloud's AI Endpoints works really well. Blazing fast when using Qwen3.6:35b (for both architect and subagent) compared to the local option which was painfully slow even with a very simple query (each word was taking seconds to appear; much slower than I can read. The endpoints option was zipping by).

I've tried using llama-server and ollama and discovered I just don't have the GPU needed to get reasonable speeds doing the local option (lots of CPU and base RAM but not the greatest GPU and not much VRAM on the Nvidia (8GB), and the Intel Arc (much more VRAM) I never got working with ollama or llama-server on my Linux laptop, with the proprietary drivers (the Intel stuff apparently does not provide Debian support, and the self-building was getting me deep into yak shaving territory)) regardless of what I use as agents.

A minimalist agent like lfm has okay speeds locally, but is only suitable for very basic tasks and is not useful for coding.

[aa956]

For Intel ARC try prebuilt llama-server (just in case, all 3 options: Vulkan, SYCL fp32 and fp16).

Later you can set up local build for the variant you like, for Vulkan it's simple, SYCL build requirements was PITA to set up on debian if I recall correctly last time I tried (but it was a long time ago, using CUDA mainly for now).

You'll need to use proprietary drivers for CUDA.

8GB Nvidia is good to run smaller MoE models - e.g. Qwen3.6 35B A3B - as long as you have normal system RAM to keep the offloaded MOE layers.
Try to start with just llama-server --jinja --cpu-moe --model Qwen_Qwen3.6-35B-A3B-IQ4_XS.gguf and optimize parameters later.

Larger dense models (like Qwen3.6 27B) - these will be painfully slow on 8GB GPU.

Edit: thanks for the OVHcloud tip, I'll check them.

Just this weekend registered on openrouter and tried Deepseek V4 flash with late - this one was fun to watch working.

[danielfdickinson]

Thanks for this. I had tried the prebuilt and thought it was incompatible with my hardware due to it erroring out. This got me to take a closer look, and I realized the real issue is that when using Vulkan it was preferring the Nvidia and running out of memory and dumping stack (I take it it is supposed to fail more gracefully). When I forced the Arc graphics, it behaved well, and the speeds were not too bad.
On second look, I noticed the OvHcloud models don't include Qwen3.7 27B, so it looks like it's a good way to get my feet wet, but may not do everything I end up wanting.