sdods agent generate -p rwa-bank --adapter ollama --model llama3.1:8b --plan docs/test-plans/contacts.md --eventsIt calls feature_list, reads the result, calls feature_list again with the same arguments, and keeps going until the turn budget stops it. No proposal. It is not confused about the tool — it just never seems to remember it already called it.
Budget never fires, which I assume is because nothing is billed.
Accepted answer
Repeating the same call with the same arguments is almost always the model not seeing its own previous turn, and on Ollama that means context.
ollama psLook at the CONTEXT column. Ollama loads a model with a 4096-token context by default whatever the weights allow, and it truncates a longer prompt silently. An agent prompt carries the tool schemas, so it is over 4096 on turn one; by turn three the earlier tool results have fallen off the front and the model genuinely does not know it called anything.
agents:
provider: ollama
local:
contextTokens: 16384or server-wide with OLLAMA_CONTEXT_LENGTH=16384 ollama serve.
SDODS is supposed to refuse a job whose prompt cannot fit rather than let it be truncated, so if you got no such refusal, check that the adapter really is ollama and not openai pointed at the same endpoint — the OpenAI protocol has no way to set or read the context size, which is exactly why the native adapter exists.
Do not raise it to the model's maximum, though. An oversized num_ctx on a laptop spills the KV cache out of memory and ten-second turns become minutes, which looks like a different bug entirely.
Raise it to what the job needs. 16k was enough for generate here; 32k for anything reading a long plan.
On the budget: correct, budgetUsd never fires on a local model because nothing is billed, so maxTurns is the only bound that matters there. Set it deliberately per role rather than leaving the default:
agents:
maxTurns: { healer: 30, generator: 20 }A loop that costs nothing still costs you an afternoon.
Once the context is right, llama3.1:8b is honestly a reviewing and reading model rather than a generating one. It calls tools reliably, which is the hard part, but generate from a plan is patchy at 8B and usually fine at 14B.
qwen2.5-coder:14b is the one that changed our results, at the cost of a slower first turn.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question