AI chat
AI chat in CMDOP is one surface backed by three things: jarvis (the server-side AI agent), local-LLM models running on your own machine, and cloud / gateway providers reached through the LLM gateway. You talk to one chat; CMDOP routes the turn to whichever model backs it. The agent loop, tools, and permission gate are identical regardless of which provider answers.
The three backings
| Backing | What it is | When it answers |
|---|---|---|
| jarvis | A server-side AI agent that runs triggers, webhooks, and a task queue, and speaks the same proto + tools as any other operator. It also summarizes long conversations to cut token debt. | Autonomous / scheduled work, and behind-the-scenes summarization. |
| local-LLM | Models you download and run locally via cmdop local-llm (Ollama / LM Studio also supported as providers). | Private, offline, or air-gapped chat — nothing leaves your machine. |
| Cloud / gateway providers | The default path: hosted models reached through the cmdop model gateway on the relay, authenticated by the sign-in your agent already holds — cmdop supplies the provider keys. A custom provider is the bring-your-own-key escape hatch. | When you want a frontier hosted model and are comfortable with the request leaving your contour. |
Whichever backing answers, it is the same agent loop and the same tool catalogue. There is no separate “AI mode” — chat, MCP, and the SDK all drive the one loop. See Agent loop and Tools.
jarvis — the server-side AI agent
jarvis is not a chatbot pinned to a single window. It is an always-on agent orchestrator: a trigger scheduler, a webhook receiver, and a worker pool that can run agent turns on its own. Because it joins the relay as an operator over the same protocol, anything a human-driven chat can do, jarvis can do on a schedule or in response to an event. jarvis is also the summary agent that compacts long transcripts so working memory stays small (see Memory).
Providers and the LLM gateway
CMDOP ships 19 provider presets so you rarely configure a raw endpoint by hand:
anthropic, zai, zai-cn, minimax, kimi, moonshot,
deepseek, mimo, alibaba, alibaba-us, openai, gemini, xai,
mistral, openrouter, groq, ollama, lmstudio, custom.
The ollama and lmstudio presets point at local runtimes; custom
lets you wire any OpenAI-compatible endpoint. Manage providers with:
cmdop provider list # see configured providers
cmdop provider add # add one (preset or custom)
cmdop provider default # back to the cmdop default
cmdop provider test <id> # verify connectivityThe cmdop model gateway is the default routing layer in front of the major model families — one place to hold keys server-side, pick a default, and route a chat turn to the right backend, reached with the sign-in your agent already holds. Configuring a preset above makes it a custom provider: chat then goes straight to that endpoint with your own key, bypassing the gateway. See How model access works for the full three-mode picture (gateway · custom provider · local).
One caveat worth knowing up front: vision / OCR is gateway-only. The
agent reads images via its view_image tool, which the gateway serves;
on a custom-provider or local chat, an image-analysis request returns a
clear error rather than silently doing nothing. And if the gateway is
unreachable or your sign-in lapses, a cloud chat turn automatically
degrades to a local model instead of hard-failing.
Choosing a model per chat
cmdop chat # default model
cmdop chat --model deepseek # pick a provider/model alias
cmdop chat --tools coding # full | coding | minimal tool profile
cmdop chat -m vps-audi # chat anchored to a remote machineLocal models keep the whole conversation inside your contour; cloud providers trade that for frontier capability. The choice is per chat.
Cmdop