bug: Large XML-heavy system prompt breaks tool calling across multiple Ollama models (Qwen3, Qwen2.5, Devstral)

[andrewgwoodruff]

Environment

• OpenCode: 1.4.6
• Model: qwen3-coder:30b via Ollama
• Ollama: 0.20.7
• OS: macOS Darwin 25.4.0 (Apple M5 Pro)
• Project: ~73 skills loaded from .claude/skills/

Problem

When OpenCode loads skills from a Claude Code project, the system prompt reaches ~41KB, and the skills listing is serialized as XML tags (<available_skills>, <skill>, <description>, etc.). I'm thinking that this is causing qwen3-coder:30b to switch from OpenAI JSON tool-call format to its native HERMES XML format; OpenCode can't parse HERMES XML, so all tool invocations fail silently or log invalid Invalid Tool.

Reproduction

1. Open a project with 50+ Claude Code skills in .claude/skills/
2. Configure Ollama qwen3-coder:30b as the model (via @ai-sdk/openai-compatible provider pointing to http://localhost:11434/v1)
3. Run any prompt that requires a tool call (e.g. "list top-level directories")
4. Observe output like:

   <function=bash><parameter=command>ls</parameter></function>
   

   instead of a JSON tool_calls response

Root cause analysis

The system prompt size and XML structure is the trigger. Verified via proxy logging between OpenCode and Ollama:

• OpenCode system prompt with skills loaded: 41,804 bytes, contains XML-tagged skill list
• With this prompt + 45 tools → model outputs HERMES XML (fails, invalid Invalid Tool)
• With a minimal plain-text prompt + same 45 tools via direct Ollama API → model outputs valid OpenAI JSON tool_calls (succeeds)
• Streaming with 45 tools in isolation works correctly, so it seems that this is not an Ollama streaming bug

The XML tags in the skills listing (<skill>, <description>, <location>) appear to signal to qwen3-coder that it should respond in XML, overriding the tool-call format the model would otherwise use. Note: I haven't confirmed whether it's the XML structure specifically or just the prompt length; a 41KB plain-text prompt as a control would settle it, but the XML hypothesis is the stronger lead given the model behavior.

Possible mitigations

1. Serialize skills in JSON or plain-text format instead of XML tags in the system prompt
2. Add HERMES XML tool-call parsing as a fallback (similar to OpenCode can not support DeepSeek tool calling method: DSML(DeepSeek Makeup Language) #24566 for DSML)
3. Expose a config option to disable skills injection into the system prompt for local/non-Claude models

Related

• Progress halts with qwen 3.6 35b-a3b with naked tool call in the console #24316: similar HERMES XML symptom with Qwen 3.6 35b-a3b ("naked XML at the end")
• Agent prompt field is not sent as system message to Ollama-compatible local models #24239: agent prompt field / system message handling with local models

[andrewgwoodruff]

Additional testing, confirmed model-agnostic

After filing this issue I ran the same three-tier tests against two additional models to determine whether this was Qwen-specific.

Models tested

Model	Family	Size	Tool call result
qwen3-coder:30b	Qwen	18GB	HERMES XML output
qwen2.5-coder:32b	Qwen	19GB	Plain-text JSON {"name":"bash","arguments":{...}}
devstral:24b	Mistral	14GB	Plain-text JSON (test 1), hallucinated without tool call (test 2), no output at all (test 3)

Tests run per model

1. Simple tool call: "List files in the current directory using a bash command"
2. File read + analysis: "Read README.md and give me a one sentence summary"
3. Multi-step: "Find all TypeScript files in apps/ai, read one, tell me what it does"

Conclusion

All three model families fail tool calling when given OpenCode's full ~41KB XML system prompt. The failure modes differ per model family (HERMES XML, plain-text JSON, hallucination/silence) but the root cause is the same. This is not a Qwen-specific quirk; it would appear to affect any Ollama model exposed to this system prompt.

Direct Ollama API calls with a clean system prompt work correctly across all models tested.

[andrewgwoodruff]

Follow-up: format comparison testing

After filing this I ran some controlled tests to figure out whether the XML serialization format specifically was the problem, or if this was just general model unreliability. Tested three formats — XML (current behavior), Markdown (verbose: false), and JSON — against devstral:24b via Ollama, 50 runs each, same system prompt and tool definitions across all three.

Format	Prompt size	Pass rate
XML (current)	7,019 bytes	68% (34/50)
Markdown	3,654 bytes	74% (37/50)
JSON	6,611 bytes	86% (43/50)

JSON came out significantly ahead — 18 points over XML and 12 over Markdown. Worth noting that JSON and XML are nearly the same prompt size, so the difference is about format, not just token count.

I'm wondering if the right fix is to change fmt() in skill/index.ts to serialize skills as JSON by default rather than XML. The XML format seems to be a Claude-specific assumption that leaks into how other models interpret the prompt; JSON is format-neutral and the numbers back that up. The non-verbose Markdown path already exists in fmt() but JSON appears to be the stronger option based on this data.

Happy to open a PR for this if the approach sounds reasonable to you. The change would be fairly contained — the serialization logic is in one function, and the fix would make JSON the default with XML as an opt-in for Anthropic models if needed.