Tool Calling is not working in VScode[Cline]
Used LM Studio and VScode.
prompt:
Act as a Senior Game Developer, UI/UX Designer, and Performance Engineer. We are building an elegant Snake game in ONE single-file HTML (HTML5 Canvas + CSS3 + Vanilla JS). The aesthetic is "Modern Minimalist Neon" — dark mode background, glowing snake body with gradient tail, pulse animations on food, high-contrast score overlay, and a retro CRT scanline effect overlay.
Plan the code as if it were a multi-file project so each section stays clean:
- CSS module (layout, canvas styling, glow effects, scoring UI)
- Game Engine module (grid constants, snake state, food gen, direction handling)
- Rendering loop (requestAnimationFrame with consistent 60fps delta time)
- Input layer (keydown queue for non-backtracking turns — no reversing direction midframe)
Do not write any actual component code yet. Output the complete file structure tree of how you would organize this logic if it were split, explain what each section does within the single HTML file, and await my signal for Step 2.
Screenshots
LM Studio Settings
Hey, thanks for the detailed write-up and screenshots — they make this easy to diagnose, and the good news is your
model actually did its job here. The plan it produced is genuinely solid (clean CSS / engine / render / input split,
non-reversing direction handling, rAF loop), and the HTML it started writing was clean too. So this isn't the model
breaking down — it's that the tool calls never got executed.
What's happening: those <|tool_call>call:write_to_file{...} and <|"> bits leaking as raw text are Gemma 4's native
tool-call tokens. The model is emitting proper native tool calls — but in this LM Studio + Cline setup they aren't
being parsed into structured/executable calls, so they leak into the chat as text and Cline never actually writes the
file. I checked this on my end: the exact same model served through llama.cpp returns clean, structured tool calls
with zero leaked tokens — so the model side is fine, it's the serving/harness layer that needs the right tool parsing.
Two things to fix:
- Tool execution. Serve the model with llama.cpp's llama-server --jinja (it has the parser for Gemma 4's native tool
format — I confirmed it returns proper structured tool_calls), and point Cline at it as an OpenAI-compatible provider
with native function-calling enabled, so Cline consumes structured calls instead of trying to match its own text
format. That combo actually runs the tools instead of printing them. - Quality setting (independent, but worth it). In your LM Studio load settings you have both K Cache and V Cache
quantization set to Q4_0 — that measurably hurts precision on coding / structured output, so turn both off (FP16 KV
cache) for code work. Your GPU Offload is also at 40 (partial); if you have the VRAM, push it to full — that's just
speed, not the bug.
Honest heads-up: Cline has its own tool protocol that can clash with Gemma 4's native format, so the --jinja +
function-calling path above is the reliable combo. Once the tools actually execute, that Snake plan should turn into a
real file. Let me know how it goes!
hey thanks for the neat response. I'm a hobbyist Local AI user with limited technical knowledge. I found LM Studio to be a simple setup, and so many models work in Cline without any default configuration changes. I initially thought there was an issue with the model itself. Thanks anyway for the great work, and I look forward to further updates that will allow people like me to enjoy these community models as well.
Unfortunately, even jinja enabling won't solve the issue. I switched to llama.cpp from lm studio but still the agentic coding does not work most of the time. The task has to be absurdly simple and then it works some times, and most of the time it does not, it complain about like:
Model Response Incomplete
The model failed to use any tools in its response. This typically happens when the model provides only text/reasoning without calling the required tools to complete the task.
I'm using Zoo Code which is fork of Roo Code and support agentic coding. It is free.
Unfortunately, even jinja enabling won't solve the issue. I switched to llama.cpp from lm studio but still the agentic coding does not work most of the time. The task has to be absurdly simple and then it works some times, and most of the time it does not, it complain about like:
Model Response Incomplete
The model failed to use any tools in its response. This typically happens when the model provides only text/reasoning without calling the required tools to complete the task.I'm using Zoo Code which is fork of Roo Code and support agentic coding. It is free.
I have same experience with you.
Model just stucks, desperately tries to call non-existing tools (hit or miss) etc. etc.
It's kind of broken, at least for the agentic approach.
And it has weird behaviors like not creating a required file even though i keep insisting it to issue. (instead, it tried to screenshot lol 🥸 )
@kremerneil @gmbiz Thank you both — and you're right to push back. What you're describing is a different, more real problem than the template leak above, so let me be straight about it instead of just repeating "use --jinja."
There are two layers here, and --jinja only fixes the first:
Harness protocol. Roo/Zoo have been migrating from the old XML tool protocol to native function-calling. The XML protocol is rough even for frontier models (~10–15% tool-call failure on things like apply_diff), and asking a 12B to follow that verbose prompt-based format reliably is a lot. Make sure you're on a recent Zoo Code build with native tool calling enabled, add the model as an OpenAI-compatible provider, and confirm tools are actually being passed through (llama-server --jinja does emit structured tool_calls, but the harness has to be in native mode to consume them). That alone moves the needle.
The honest part — the model. Even with all of that correct, v2 was trained largely on single-turn data. Sustained, fully-autonomous agentic coding — where every turn it has to commit to a tool call, never drift into "just reasoning," never invent a tool name — is genuinely this 12B's weakest area right now. The exact symptoms you're hitting (returns reasoning with no tool call, calls a non-existent tool, loops, refuses to write the file) are failure modes I've reproduced myself. That's not you doing anything wrong.
The good news: this is the #1 thing v3 was built to fix. It specifically targets execution robustness — committing to the tool call instead of stalling, not looping, not hallucinating tools. v3 (still 12B) lands in the next day or two, and I'm stress-testing this exact agentic-coding path (Roo/Zoo/Cline) before I ship. I won't oversell it — a 12B on full autonomy won't match a frontier cloud agent, and scoping tasks + native tool calling will always help — but this failure mode is precisely what it's aimed at
If it's useful, I'm happy to post the exact llama-server flags + Zoo Code provider settings I run so we're comparing the same setup. And please retest once v3 isexactly what tell me whether it actuallylanded.