For me this model is being extremely bad, what am I doing wrong?

#61
by Xhatz - opened

Hello! I have been trying this model on LM Studio with all the recommended settings (temp 1, top k 64, rep pen 1.1, top p 0.95), and giving it a playground using nanobot, but for some reason it has been running very bad for me. Simple agentic tasks end up getting stuck in weird loops where the agent tries to mess with skills or multiple versions of files that has nothing to do with the task, it's really nonsense lol. I have no clue what I did wrong, people seem to not have such issues? (I am using Q6K without MTP)

Hey @Xhatz β€” thanks for the detailed writeup, and no, you're almost certainly not doing anything "wrong." A few things to check, roughly in order of likelihood:

  1. The chat template in LM Studio (most likely culprit). Gemma 4 ships a custom chat template, and LM Studio's template engine (minja) doesn't handle all of it. When the tool-call tokens don't render correctly, the agent can't cleanly read tool results back and starts flailing β€” touching unrelated files, poking at "skills," looping. That matches your symptom almost exactly. The most reliable setup for agentic/tool use is to serve the model through llama.cpp llama-server --jinja (build b9553 or newer) as an OpenAI-compatible endpoint, and point nanobot at that instead of LM Studio. That applies the real template and emits proper tool calls. (Ollama with --jinja-equivalent handling also works.) If you'd rather stay in LM Studio, check whether it throws an UndefinedValue template warning when loading β€” that's the tell.

  2. Sampler, tuned for agentic. temp 1 / rep-pen 1.1 is fine for one-shot chat/coding, but for multi-step agentic runs I'd drop temperature to ~0.7 and repeat penalty to ~1.05 (and no DRY stacked on top). Lower temp makes tool-argument choices more deterministic and cuts the "nonsense branch" loops. The temp-1 recommendation was tuned for chat, not long autonomous chains.

  3. An honest limitation. v2 (12B) was trained largely on single-turn data, so long fully-autonomous multi-step chains are genuinely its weakest area β€” this exact "gets stuck in loops / wanders off-task" pattern is the #1 thing I'm targeting in v3. v3 (still 12B) is landing in the next day or two, so if the config fixes above don't fully solve it, that update should help a lot.

Two quick questions to pin it down: does nanobot use native OpenAI function-calling, or a text/ReAct-style agent? And do you see any template warning in LM Studio when the model loads? That'll tell us whether it's the template.

Sorry for the late reply! Thank you for your message. I think LM Studio is setting the jinja template by default for these models and nanobot is calling it's OpenAI style endpoint by default. Here are some logs sent as the model is loaded if it can help with anything...

LlamaV4::load config: n_parallel=4 n_ctx=65536 kv_unified=true
[2026-07-09 05:17:09][DEBUG] gemma4 architecture detected, using AUTO flash attention mode
0.00.069.740 I srv    load_model: loading model 'C:\Users\Xhatz\.lmstudio\models\yuxinlu1\gemma-4-12B-agentic-fable5-composer2.5-v2-3.5x-tau2-GGUF\gemma4-v2-Q8_0.gguf'
[2026-07-09 05:17:09][DEBUG] 0.00.529.024 W load: control-looking token:     50 '<|tool_response>' was not control-type; this is probably a bug in the model. its type will be overridden
[2026-07-09 05:17:09][DEBUG] 0.00.529.382 W load: control-looking token:    212 '</s>' was not control-type; this is probably a bug in the model. its type will be overridden
[2026-07-09 05:17:09][DEBUG] 0.00.575.970 W load: special_eog_ids contains '<|tool_response>', removing '</s>' token from EOG list
[2026-07-09 05:17:14][DEBUG] 0.05.606.839 W cmn  common_init_: KV cache shifting is not supported for this context, disabling KV cache shifting
[2026-07-09 05:17:14][DEBUG] 0.05.786.550 I srv    load_model: initializing, n_slots = 4, n_ctx_slot = 65536, kv_unified = 'true'```
Xhatz changed discussion status to closed
Xhatz changed discussion status to open

Sign up or log in to comment