gemma-4-26b and gemma-4-31b opencode interaction issues leading to tool loops/failures

[pchuck]

Description

Gemma-4-26b and Gemma-4-31b, even with the latest tokenizer fixes, running on the latest patched engines, is not usable in OpenCode

Additional environment details

• lmstudio: v0.4.9 - includes: "Improved Gemma 4 tool call reliability"
• engine: metal llama.cpp v2.11.0 - includes "Gemma 4 improvements"
• models: google, and unsloth/bartowski imatrix k-quants (including most recent updates as of 2026.04.04 w/ tokenizer fixes)

Model Settings

• context: 64K
• temperature: 1
• top-k: 64
• repeat penalty: 1.1
• top-p: 0.95
• min-p: 0.0
• flash attention: on
• cache quantization: off

Plugins

none

OpenCode version

v1.3.13

Steps to reproduce

Configure the model in opencode.json...

            "gemma-4-26b-a4b-it": { 
                "name": "gemma-4-26b-a4b-it",
                "limit": {
                    "context": 65536,
                    "output": 65536
                }
            },

Create a simple test file 'test.txt' in the current working directory

Send a simple prompt in OpenCode

read the file test.txt

Observe the failures:

• tool failures
• command repetition on tool success (model not seeing responses?)

(see screenshot)

Screenshot and/or share link

Operating System

MacOS 26.4

Terminal

iTerm2

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Gemma 4 (e4b) tool calling fails via Ollama OpenAI-compatible API — streaming tool_calls not recognized #20995: Gemma 4 tool calling fails via Ollama OpenAI-compatible API — same symptom of tool call failures/loops with Gemma 4 models via local OpenAI-compatible providers
• Default agent is brittle against local OpenAI-compatible tool-call quirks #20669: Default agent is brittle against local OpenAI-compatible tool-call quirks — covers tool loop/hang behavior with local backends like llama.cpp and LM Studio, which matches your environment

[pchuck]

Just following up on the possible duplicates flagged by github-actions.

This issue is not a duplicate of #20995. In that issue, the (smaller) model is unable to make a tool call (model responds with: "I do not have the capability to execute system commands like listing directory contents.") In this issue, the tool calls are attempted.

This issue is not a duplicate of #20669. In that issue, the tools are called with invalid arguments ("The bash tool was called with invalid arguments ... expected string, received undefined"). In this issue, tool calls succeed and are repeated numerous times.

[pchuck]

Updated to metal llama v2.12.0 and tested both unsloth/gemma-4-26b-a4b-it@q4_k_xl and unsloth/gemma-4-31b-it@q4_k_xl.

OpenCode seems to be working now. Model appears to be parsing tool responses properly. Tool use is working without error, and redundant/repeated tool call loops are no longer occurring.

[NikolaKrstic94]

Updated to metal llama v2.12.0 and tested both unsloth/gemma-4-26b-a4b-it@q4_k_xl and unsloth/gemma-4-31b-it@q4_k_xl.

OpenCode seems to be working now. Model appears to be parsing tool responses properly. Tool use is working without error, and redundant/repeated tool call loops are no longer occurring.

Same here ,can confirm it works much much better.

[eikonomega]

I can confirm this same behavior on PopOS/RTX 5090 setup. Also any request that requires a tool call ends up in an infinite loop with Gemma4 26b and 31b models.

[bni]

I see this and then the agent just stops
<edit_file> <file_path>/Users/bni/Documents/freesynd/engine/src/system/sdl/system_sdl.cpp</file_path> <old_string> #include <SDL_image.h> </old_string> <new_string> #include <SDL3/SDL_image.h> </new_string> </edit_file> <edit_file> <file_path>/Users/bni/Documents/freesynd/engine/src/system/sdl/fstexture_sdl.h</file_path> <old_string> #include <SDL.h> </old_string> <new_string> #include <SDL3/SDL.h> </new_string> </edit_file>

Running latest llama.cpp like this:

.\llama-server.exe
--hf-repo unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL --temp 1.0
--top-p 0.95 --top-k 64
--alias "unsloth/gemma-4-26B-A4B-it-GGUF" --host 0.0.0.0
--port 8080 --reasoning on

[FricoRico]

VLLM v0.19.0 still showed issues and so did the nightly from yesterday. I'm unsure if this is an OpenCode problem or an inference side problem.

[JackKelly]

I can confirm that I'm seeing similar behaviour with opencode, vLLM v0.19.0, and Gemma 4 26B.