Bug: long running agent tasks in Ollama leads to unexpected stop tokens before tool calls
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 74/100
Línea de trabajo
Start in src/eca/llm_providers/ollama.clj and read normalize-messages, comparing its message handling with the Anthropic adapter’s merge-adjacent-assistants. Check how request JSON keys are encoded and how assistant history items become Ollama chat messages. Done means prior tool calls are sent with the expected key and consecutive assistant content and tool calls are grouped as described; the issue names no test file, so locate the relevant provider tests.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
Describe the bug
When using the Ollama API and long running agent tasks, the models (tested on qwen 3.5/3.8) emit unexpected stop tokens where a tool call is expected.
To Reproduce
Steps to reproduce the behavior:
- Use a model hosted by Ollama with the Ollama Api
- Start a long running task
- At some point the model outputs:
Now I edit file X <stop_token>
Expected behavior
The model emits a tool call request instead of the stop token.
Cause and fix
The reason for the behavior is twofold. Both problems are in normalize-messages in src/eca/llm_providers/ollama.clj.
-
Previous tool calls are silently dropped. The assistant tool-call messages are built with the key
:tool-calls, and the body is encoded with a plain(json/generate-string body)(no key-fn), so the wire key is"tool-calls". Ollama's/api/chatexpectstool_calls(API docs) and silently ignores unknown fields, so the request succeeds but the model never sees its earlier tool calls. (The response side already reads:tool_callscorrectly.) -
One model response is sent as several assistant turns. Each history item becomes its own message: the reasoning (as plain
content), the visible text, and the tool call. Ollama renders every assistant message as its own finished turn. The model's history therefore contains many turns of the form "I'll do X now", followed by an end-of-turn marker. That never happened during generation, where the call followed in the same turn. The model imitates the pattern and ends its turn right after announcing the action, so the stop token becomes likely. Each failure also adds another such example, which is why it gets worse in long sessions.
Fix
- Use
:tool_callsinstead of:tool-calls. - Merge consecutive assistant messages into one (reasoning first, then text, joined by a blank line, with all tool calls concatenated). A
toolmessage between two responses keeps them separate. The Anthropic adapter already does this withmerge-adjacent-assistants.
Workaround until released
Pointing the provider at Ollama with "api": "anthropic" avoids the problem, because that adapter already merges messages and sends tool_use blocks (Ollama converts them to tool_calls).
- Lenguaje dominante
- Clojure
- Estrellas
- 1k
- Forks
- 82
- Merge medio
- 2 d 2 h
- PR fusionados (30 d)
- 21
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de editor-code-assistant/eca
-
Models doesn't work when fetchModels: false is usedPosiblemente ocupada @zikajk la tomó hace 8 días. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
editor-code-assistant/eca#661 · 1 asignado ·
Los mantenedores suelen responder en 2 días
-
bug
Dificultad 4/5 1-2 días Aptitud para principiantes 54/100
editor-code-assistant/eca#674 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
editor-code-assistant/eca#671 · 2 comentarios ·
Los mantenedores suelen responder en 2 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
editor-code-assistant/eca#670 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
editor-code-assistant/eca#669 ·
Los mantenedores suelen responder en 2 días
Todos los issues de editor-code-assistant/eca
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
WG adoption
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
clojure-emacs/cider#4224 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100