🚀 New Model: caal-qwen3.5-9b

[cmac86]

Just published a new fine-tuned model based on Qwen3.5 9B that significantly outperforms the previous Ministral-based models.

Results

84/85 tests passed (99%) on the 85-test evaluation suite:

Category	Score
Single tool calls	27/27
Argument formatting	19/19
Conversational (no tool)	10/10
Multi-turn chains	28/29

For comparison, the previous best (Ministral 8B) scored 78/85 (92%) and was stuck at 6/10 on conversational tests.

What changed

• Base model: Switched from Ministral 8B to Qwen3.5 9B. Qwen3.5 natively handles multi-step tool chains, which Ministral could not.
• Training approach: Last-turn-only SFT — previous conversation turns are included as context but only the final response is trained on. This preserves Qwen's strong base behaviors while teaching it CAAL's specific tools.
• 3-step tool chains work: e.g., search vast.ai for GPUs, look up a contact's email, then send them the results via Gmail — all in one request.

Try it

ollama pull coreworxlab/caal-qwen3.5-9b

Requires ~5.4 GB VRAM (Q4_K_M quantization). Runs well on consumer GPUs (RTX 3060+).

Use with RENDERER qwen3.5 and PARSER qwen3.5 in your Modelfile — no custom template needed.

What's next

• Testing smaller variants (0.8B, 2B, 4B) for edge deployment
• Experimenting with QLoRA to reduce training costs
• Session greeting behavior (model currently skips greeting on session start)

Feedback welcome — let me know how it works with your setup.

[luanfernandes]

are you changing the default base model to this one? Or gonna try the smaller variants first?

[cmac86]

Hi @luanfernandes. the qwen3.5 model is showing promise. I was using ministral-3 as the base up until now but I think qwen3.5 has now taken the throne. I have done some testing on smaller variants as well and they are performing very well.

I'm thinking this will be the new default base model.

Why do you ask? What are you thinking?

[luanfernandes]

nothing much really, just curious to know how small can we go. I have a 1GB ram gpu idle here 😂

[cmac86]

Haha, yea me too. 1gb is a little tight! I've had some success with the qwen3.5:2b and I'll be releasing this soon. But the 0.8B is very limited with its tool calling. Would have to really simplify the tools for it to perform.

[vescreative]

I have an issue using this model. Call says: I encountered an error: registry.ollama.ai/coreworxlab/caal-qwen3.5-9b:latest does not support tools (status code: 400)

[cmac86]

@vescreative can you confirm what ollama version you have?

ollama --version

You should be running 0.17.5

[nerd8east-a11y]

I was having the same error while using ollama version 13.5 and had to update. I can confirm that everything works well with ollama version is 0.19.0-rc0.

[nerd8east-a11y]

One thing I noticed while testing this new model with my custom weather n8n workflow, is that it can no longer assume a location. It only works if I specify the location while talking to CAAL.
My webhook settings look like this:

_Weather tool - forecast and current conditions for USA.
Uses weather data from Visual Crossing.

Parameters:

• action (required): 'forecast' or 'current'
• location (required): City and State (i.e. 'Los Angeles, California'). The default location is Dallas, Texas.
• apiKey (required): {api key goes here}
• targetDay (optional): specific weekday like 'Monday', use only for 'on Friday' style queries. If none is provided, set it to the day of the week for "today"

Rules:

• If the location is not specified, use Dallas, Texas

Examples:

• "What is the current weather", then return {'action': 'current', 'location': 'Dallas, Texas', 'targetDay': ''}
• "What is the current weather for New York", then return {'action': 'current', 'location': 'New York', 'targetDay': ''}
• "Weather for Montreal on Wednesday", then return {'action': 'forecast', 'location': 'Montreal', 'targetDay': 'wednesday'}_

Before I was able to just ask CAAL "What is the current weather" and it would assume I was talking about my default location. Now, I can only get it to work if I specify the location. I am not sure if this is something I can fix on the webhook settings or somewhere else (maybe add my current location to the prompt itself?)

What do you think?

Thanks

[cmac86]

Hey @nerd8east-a11y This is actually a fine-tuning improvement, not a regression, though it changes the UX for your specific case.

The new qwen3.5-9b model is stricter about required parameters — when something is marked required: true, it won't fabricate a value from description text. The old ministral-3:8b was more lenient and would read the "default is Dallas, Texas" line as a hint. The new behavior is better for reliability (no hallucinated parameters) but worse for implicit defaults like yours.

Quick fix on your end — change location to required: false in your n8n webhook schema, and inside the workflow use an expression like:

{{ $json.location || 'Dallas, Texas' }}

This will assign Dallas, Texas to the location if the parameter doesn't exist. I don't know your workflow code so don't use this verbatim.

That way the model can skip the field when the user doesn't specify, and your workflow fills in the default. This is cleaner because the schema stays honest about what's required.

Better long-term fix — CAAL should probably support a user location setting that gets injected into the system prompt context. Then the model has "the user is in Dallas, Texas" as context and would naturally pass that to tools without relying on the description. I'll put in a feature issue for this.

Corey