Context
Discussion #418 surfaced an Ollama/local-model compatibility issue around tool-call transcripts. Some Ollama-served models, especially llama3.x and qwen*-coder-style models, can fail or hang when a tool message is followed directly by the next non-assistant turn. The proposed local patch sets provider = "ollama" and enables requires_assistant_after_tool_result for Ollama configs.
This belongs primarily in yoagent, then yoyo should consume the new first-class constructor.
Proposed sequence
-
Update yoagent:
- Add a first-class
ModelConfig::ollama(...) preset.
- Set
provider = "ollama".
- Set
compat.requires_assistant_after_tool_result = true for Ollama.
- Make
OpenAiCompatProvider actually honor requires_assistant_after_tool_result by inserting the required synthetic assistant message after tool results.
- Add serialization tests for
assistant(tool_calls) -> tool -> assistant(empty).
-
Release a new yoagent version.
-
Update yoyo-evolve:
- Bump the
yoagent dependency.
- Change the Ollama branch in
create_model_config to use the new constructor, e.g.:
"ollama" => {
let url = base_url.unwrap_or("http://localhost:11434/v1");
ModelConfig::ollama(url, model)
}
- Keep generic
custom / local neutral:
- Do not enable the Ollama transcript workaround for every local OpenAI-compatible endpoint.
- Generic local endpoints can still set
provider = "custom" or provider = "local" for identification.
Why not change all local models?
ModelConfig::local(...) covers LM Studio, vLLM, llama.cpp, Ollama, and arbitrary OpenAI-compatible servers. The assistant-after-tool-result workaround appears useful for Ollama/model-family quirks, but making it global could regress servers that expect stricter OpenAI-compatible transcripts.
Validation
After the yoagent release and yoyo update, test with Ollama models such as:
llama3.1:8b
qwen2.5-coder:7b
Useful smoke test: ask yoyo to list files in a directory and report the largest file. The important behavior is that it completes cleanly after receiving a tool result instead of hanging or failing the next request.
Related: #418
Context
Discussion #418 surfaced an Ollama/local-model compatibility issue around tool-call transcripts. Some Ollama-served models, especially llama3.x and qwen*-coder-style models, can fail or hang when a
toolmessage is followed directly by the next non-assistant turn. The proposed local patch setsprovider = "ollama"and enablesrequires_assistant_after_tool_resultfor Ollama configs.This belongs primarily in
yoagent, then yoyo should consume the new first-class constructor.Proposed sequence
Update
yoagent:ModelConfig::ollama(...)preset.provider = "ollama".compat.requires_assistant_after_tool_result = truefor Ollama.OpenAiCompatProvideractually honorrequires_assistant_after_tool_resultby inserting the required synthetic assistant message after tool results.assistant(tool_calls) -> tool -> assistant(empty).Release a new
yoagentversion.Update
yoyo-evolve:yoagentdependency.create_model_configto use the new constructor, e.g.:custom/localneutral:provider = "custom"orprovider = "local"for identification.Why not change all local models?
ModelConfig::local(...)covers LM Studio, vLLM, llama.cpp, Ollama, and arbitrary OpenAI-compatible servers. The assistant-after-tool-result workaround appears useful for Ollama/model-family quirks, but making it global could regress servers that expect stricter OpenAI-compatible transcripts.Validation
After the yoagent release and yoyo update, test with Ollama models such as:
llama3.1:8bqwen2.5-coder:7bUseful smoke test: ask yoyo to list files in a directory and report the largest file. The important behavior is that it completes cleanly after receiving a tool result instead of hanging or failing the next request.
Related: #418