Assistant: models without a tool template 400 on every data question over Ollama

[pliablepixels]

Ollama ships no tool template for some models (Gemma 3, Gemma 2). Any request carrying a tools field is rejected:

{"error":{"message":"registry.ollama.ai/library/gemma3:4b does not support tools","type":"invalid_request_error"}}

OpenAiProvider.chat attaches tools whenever the turn has any (app/src/lib/assistant/providers/openai.ts:629) and nothing catches the resulting 400, so it reaches the panel as a bad-request failure.

The failure is partial, which makes it look random: runAssistantTurn takes its tool list from opts.tools (agent.ts:221), so turns triaged CHAT or ACTION carry no tools and succeed, while every turn triaged ZONEMINDER fails. Greetings work, camera questions do not.

probeToolSupport / toolSupportFromError (openai.ts:355,427) already detect this exact condition, but are only wired into the settings UI (AssistantOllamaSection.tsx:170). The user gets a warning; the runtime still sends tools.

The portable JSON envelope already works for these models over the same path. Measured on the local prompt-eval harness (2 runs/case, temp 0):

Model	native tool	envelope
qwen3:8b	56/60	56/60
qwen3:4b-instruct	46/60	42/60
gemma3:4b	HTTP 400	48/60

Fix: when a server rejects a request with "does not support tools", record that baseUrl::model and retry the turn without the tools field, teaching the portable envelope instead. Mirror of the existing NATIVE_TOOL_SERVERS set.

This is the narrow fix. Whether to drop the tools field for everyone is a separate question that needs the envelope path measured across more models first.

[pliablepixels]

Claude here, assisting @pliablepixels.

Closing as won't-fix. The fallback worked (verified live against Ollama with gemma3:4b: the 400 disappeared and the agent loop completed end to end), but testing it surfaced a bigger problem that makes the fix pointless in practice.

Both no-tool-template models tried fabricate answers over correct data:

• gemma3:4b: given 3 events (FrontDoor 2, Front Yard 1) it answered "2 people... Front Door and Back Yard" and emitted invented event ids. Reproduced against fixtures and against a live ZoneMinder.
• granite3.3:8b: never called a tool at all. It wrote a fake tool result inline ("busiestHour 18:00-19:00, 25 events, Monitor Alpha, Monitor Beta"), and when the generic tool reminder fired it fabricated a second, different answer.

grounding.ts catches neither, by design: it decides denial-of-data and raw-JSON echo only, on the stated assumption that supplied counts leave "nothing left for the model to derive and get wrong". That assumption holds for the qwen family and fails for both models this issue would have unblocked.

Staying on qwen, which supports tools natively, so the fallback has nothing to do. The branch is deleted.

Two findings worth keeping:

1. probeToolSupport / toolSupportFromError already detect this exact condition but are wired only into the settings UI, so the runtime still sends tools and 400s. If a no-tool model is ever wanted again, that is the hook.
2. The tool-loop contract in AGENTS.project.md says "the turn schema makes the answer branch unreachable until a real tool result exists". True on WebLLM and Apple; NOT true on the Ollama native path, where free prose is accepted. The granite transcript is that mismatch in action, and genericToolReminderSent being one-shot means an ignored reminder ships the fabrication. Filed separately if it is ever worth fixing.