Default agent?

[SerhiiYashchuk]

I'm using local LLMs with the help of Ollama. After configuring multiple agents, each with a different model, I see that ZeroClaw forces Ollama to load a particular agent. When I have a chat with agent A, as soon as the agent finishes its reply, Ollama loads agent B, even though I don't need it. This creates significant delays because Ollama has to switch back to agent A when I give it another prompt and my VRAM cannot hold more than one model at a time.

Is there a way to fix this? Maybe set a default agent or configure whatever part of ZeroClaw that's causing this model switching?

[Audacity88]

There are two separate things here:

1. default_agent only decides which agent to use when the client does not specify an agent.
2. It does not make every internal/background model call use that agent's model.

If you are using ACP / an IDE client and have more than one agent configured, make sure the client is sending agentAlias on session/new, or set:

[acp]
default_agent = "agent-a"

That fixes accidental session selection, but it probably will not fix the Ollama model swap you are describing if another configured provider is being used for summarization/classification/background work.

For local Ollama setups where only one model fits in VRAM, the safest pattern is to make the chat model and the auxiliary providers resolve to the same Ollama model/provider alias for that agent:

[providers.models.ollama.agent-a]
model = "model-a"

[agents.agent-a]
model_provider = "ollama.agent-a"
summary_provider = "ollama.agent-a"
classifier_provider = "ollama.agent-a"

If the agent shares a runtime profile that sets a different context-compression summarizer, either remove that profile-level override or point it at the same model:

[runtime_profiles.local.context_compression]
summary_provider = "ollama.agent-a"

The summary_provider part is the one I would check first. We had a related class of issues where context-compression summarization could be surprising with shared runtime profiles and multiple providers/models. Current config supports per-agent summary_provider specifically so the summarizer is explicit instead of accidentally pulling a different model into Ollama.

If this is a channel integration rather than ACP/Web UI chat, also check classifier_provider: reply-intent classification can make a small model call before/around message handling unless the channel path bypasses it. ACP direct sessions skip that channel classifier.

If it still swaps after those fields point at ollama.agent-a, please paste the relevant non-secret parts of:

[acp]

[providers.models.ollama.*]

[agents.agent-a]
[agents.agent-b]

[runtime_profiles.*.context_compression]

and the log lines around the unexpected Ollama request. The useful thing to identify is which ZeroClaw path is issuing the call to model B: session selection, summarization, channel classification, delegation, or something else.

[VectorPeak]

The useful thing to trace is the request that happens after agent A finishes. If Ollama loads agent B at that point, ZeroClaw or the client is likely making a follow-up/background call using B’s configured model, not switching the active chat agent.

The most practical workaround is to make any “utility” / background / fallback model config point at the same model as the agent you’re actively using, or disable that background feature if ZeroClaw exposes a setting for it. Common culprits in tools like this are title generation, summarization, context compaction, indexing, or “default” model calls made by the IDE client after a turn completes.

A good way to narrow it down is to check the ZeroClaw logs and Ollama request logs for the model name immediately after the response completes. If the request is coming from the IDE/ACP client, pin that client to agent A explicitly rather than relying on default_agent.

If there is no config for this, I’d treat it as a ZeroClaw issue/feature request: background calls should either use the active agent’s model, use an explicitly configured utility model, or be disableable. On single-model VRAM setups, silently loading another agent’s model after every turn is pretty costly.

---

If my answer solved your problem, you can click answered the question. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆

[SerhiiYashchuk]

In my case it was summarization. I did not configure any model for it, so I guess ZeroClaw picked whichever it liked. Setting a specific small model for summarization helped me fix the issue. Thanks!