[Feature Request] Multi model support

[omsenjalia]

🤖 Feature Request: Multi-Model Support (Ollama + Cloud Models)
Problem
agentchattr is locked to Claude Code, Codex, and Gemini CLI. No way to use local models or mix models by task.
Proposed solution
Add Ollama and OpenAI-compatible endpoint support as a new agent type in config.toml:

[agents.mistral]
type = "ollama"
model = "mistral-nemo"
ollama_url = "http://localhost:11434"
color = "#f97316"
label = "Mistral"
roles = ["review", "summarize"]

[agents.qwen]
type = "openai_compat"
base_url = "https://api.ollama.ai/v1"
api_key_env = "OLLAMA_CLOUD_KEY"
model = "qwen2.5-coder:32b"
roles = ["codegen", "refactor"]

These agents join the same chat room, respond to @mentions, and participate in agentic loops like any other agent — no CLI subprocess needed, just a polling wrapper calling the model API.
Why it's useful

Route cheap/fast tasks (triage, summaries) to a local 3B model instead of burning cloud tokens
Keep sensitive code fully local via Ollama
Assign models by role: one for codegen, one for review, one for routing
Works in air-gapped environments

Implementation surface
Mostly contained to agents.py (new OllamaAgent class) and a new wrapper_api.py for the trigger loop. config.toml schema would need type, model, base_url, api_key_env, and optionally roles. MCP tools are already model-agnostic so mcp_bridge.py wouldn't need changes.

[bcurts]

Thanks - I will look into this just as soon as multi-agent sessions (multiple claude's/codex/geminis etc) is shipped with a few more ux tweaks that are already working.

[ghostreindeer09]

Hey! Happy to help out here. Before we bring in new agents like Ollama or Qwen, I can put together a small PR to introduce a BaseAgent interface.
It’d refactor the current agents (Claude, Codex, Gemini) so they all follow the same standard interface (send, receive, name) without changing how they work.
This way, adding new agents later will be way easier and safer.
Does that sound like a good first step?

[bcurts]

Thanks for the offer! We actually went ahead and built this a bit differently than a BaseAgent refactor.

The existing CLI agents (Claude, Codex, Gemini) each have their own terminal wrappers with tmux/conpty integration, keystroke injection, process management, etc. They're fundamentally different from API-only models, so a shared interface wouldn't buy much — it'd be an abstraction over things that don't actually share behavior.

Instead we built wrapper_api.py — a lightweight bridge that connects any OpenAI-compatible model endpoint to the chat room. It:

Registers with the server (gets a status pill, activity tracking, multi-instance support — all the same infrastructure the CLI agents use)

• Watches for @mentions via the existing queue system
• Reads recent chat context, formats it into OpenAI messages, calls the model's /v1/chat/completions, and posts the response back

To add a local model, you just create a config.local.toml (gitignored) with a few lines:

[agents.qwen]
type = "api"
base_url = "[http://localhost:8189/v1"](http://localhost:8189/v1%22)
model = "qwen3-4b"
label = "Qwen"

Then run python wrapper_api.py qwen (or double-click start_api_agent.bat). Works with Ollama, llama-server, LM Studio, vLLM — anything that exposes the OpenAI-compatible API.

Already tested with Qwen3-4B locally and it's working, including multi-instance support (qwen, qwen-2, etc.).

Shipping it now!

[omsenjalia]

Thanks for the offer! We actually went ahead and built this a bit differently than a BaseAgent refactor.

The existing CLI agents (Claude, Codex, Gemini) each have their own terminal wrappers with tmux/conpty integration, keystroke injection, process management, etc. They're fundamentally different from API-only models, so a shared interface wouldn't buy much — it'd be an abstraction over things that don't actually share behavior.

Instead we built wrapper_api.py — a lightweight bridge that connects any OpenAI-compatible model endpoint to the chat room. It:

Registers with the server (gets a status pill, activity tracking, multi-instance support — all the same infrastructure the CLI agents use)

* Watches for @mentions via the existing queue system

* Reads recent chat context, formats it into OpenAI messages, calls the model's /v1/chat/completions, and posts the response back

To add a local model, you just create a config.local.toml (gitignored) with a few lines:

[agents.qwen]
type = "api"
base_url = "[http://localhost:8189/v1"](http://localhost:8189/v1%22)
model = "qwen3-4b"
label = "Qwen"

Then run python wrapper_api.py qwen (or double-click start_api_agent.bat). Works with Ollama, llama-server, LM Studio, vLLM — anything that exposes the OpenAI-compatible API.

Already tested with Qwen3-4B locally and it's working, including multi-instance support (qwen, qwen-2, etc.).

Shipping it now!

Another suggestion: if possible in the ui give us option to make an agent (people who are not good with editing configs can create agents from the website). And another thing. In the config file add an option "context window". As not all ollama models have the same context window. (Default is like 128K)

[omsenjalia]

And if you can create cron loops (the AI agents work togather to create an app or an feature togather everyday at a specific time) it would be great...

[omsenjalia]

A freind of mine has a project like the one I suggested above. Check it out! https://github.com/ikislay/auto-claude

[bcurts]

Both good ideas! For now:

UI agent creation: on the radar for a future update. Right now it's a 5-line config file which keeps things simple and predictable. PRs welcome if someone wants to tackle it.

Context windown: the wrapper sends a fixed window of recent chat messages (configurable in local toml), so context limits aren't really a factor. The OpenAI-compatible API handles context sizing on the model side.

[omsenjalia]

Both good ideas! For now:

UI agent creation: on the radar for a future update. Right now it's a 5-line config file which keeps things simple and predictable. PRs welcome if someone wants to tackle it.

Context windown: the wrapper sends a fixed window of recent chat messages (configurable in local toml), so context limits aren't really a factor. The OpenAI-compatible API handles context sizing on the model side.

Okay. 1 more thing... How to automatically generated those ai hat icons for the new added ai agents?

[bcurts]

Re: the scheduler good idea! I'll add it to the roadmap :)

[omsenjalia]

Re: the scheduler good idea! I'll add it to the roadmap :)

Another thing. Generate a to do board/kanban dashboard with this same themeing schemes so the AI models can keep up with tasks. And another thing, add a like "enabled = true" so we can enable to disable the ai model. For example I don't have access to claude or codex (free tier) so I don't enable then and only use ollama/open router free models.

In the kanban dashboard you can let the ai model list it's task to it's section and move it to completed or to be done by itself.

[omsenjalia]

We still need image support btw.

[omsenjalia]

And a chat history button

[omsenjalia]

And you know that claude code has that esc button shortcut that lets us move back (for example you wanna go the start of the convo without starting another chat). Maybe do something like this.

[bcurts]

Re: the scheduler good idea! I'll add it to the roadmap :)

Another thing. Generate a to do board/kanban dashboard with this same themeing schemes so the AI models can keep up with tasks. And another thing, add a like "enabled = true" so we can enable to disable the ai model. For example I don't have access to claude or codex (free tier) so I don't enable then and only use ollama/open router free models.

In the kanban dashboard you can let the ai model list it's task to it's section and move it to completed or to be done by itself.

In the current version you don't see agents that aren't actively running.