Can you swap OpenClaw from Claude to a local model without changing the Telegram chat?

Yes. You can point the same OpenClaw Telegram chat at a local model without creating a new bot, a new token, or a new conversation. The Telegram account is a channel into the Gateway. Claude, through the Anthropic provider, and a local model, through Ollama or another provider on the host, are model refs the Gateway calls for a turn. In that chat you send /model with a session-only scope, or you change the configured default on the host and clear any pin this chat already has. The bot you already paired stays the bot.

What does not happen is a silent swap of the whole installation because you typed a model name once. OpenClaw treats a user selection as a pin on that session. Telegram’s on-screen provider picker is session-only even if you configured a broader scope. A pinned local model that is down fails the turn in the open. It does not quietly fall back to Claude. And changing the config default does not rewrite a session that is already pinned. Those three rules are why “the same chat” and “every future chat” are different jobs.

What stays put when the model changes?

The channel. Telegram is a bundled plugin. The bot token, the pairing approvals, and the session key for that DM live with the Gateway, not inside Anthropic. The model docs describe a ref as provider/model. That string chooses who answers. It does not choose which chat app the message came from. channels.modelByChannel can pin a channel or a DM peer to a model, and only when that session does not already have an active override such as one set with /model. A mapping is optional. You do not need a new Telegram bot to leave Claude.

The transcript stays too, in the sense that old replies are not rewritten. The iPhone app shows the originating model on a completed reply when the Gateway recorded it, and selecting another model does not change older replies. That is the right picture for Telegram as well: the next turn uses the model you just selected. The previous turn remains whatever model produced it. If you needed Claude’s answer in the context window, it is still text in the session. It is not a promise that a small local model will use that history as well as Claude did. Context limits are the local model’s problem, and a context-overflow error stays off the fallback path. OpenClaw tries compaction rather than hopping providers because the prompt got long.

How do you switch only this Telegram chat?

Send /model as a standalone message in the chat. On Telegram, /model offers a Browse providers button. /model list and /models open the provider menu directly. You tap a provider, then a model. Those callback selections always stay on this session. They do not update the agent default or the global default, even if agents.defaults.modelSelectionScope is set to agent or global.

From text, the scope flags are -s for this session, -a for the agent default as well, and -g for the shared global default. The config reference says the default scope is session: one chat does not change other chats or the configured default. Owner or admin authority is required for -a and -g. Without that authority, a bare command stays session-only and an explicit broader flag is rejected. The FAQ’s example of pinning a credential on the session looks like /model opus@anthropic:default -s. A local selection uses the same shape with an Ollama ref, ollama/ plus the id openclaw models list actually prints. I am not going to invent a model filename here. The list on your host is the list.

A selection without @profile keeps a compatible auth-profile pin. Another @profile replaces it. /model status shows the active profile, the candidates, and endpoint detail when you configured it. /model default -s clears only this session’s selection so the chat inherits the current configured default. It keeps a compatible auth pin and clears one that does not match the new provider.

That session pin is strict. If Ollama is unreachable, or the model id is wrong, the run fails visibly. It does not walk agents.defaults.model.fallbacks back to Claude. Fallback still applies to configured defaults, cron primaries, and auto-selected recovery. A /model you typed is you saying this provider, this model, this chat. OpenClaw will not second-guess it by calling Anthropic.

How do you make the local model the default without touching the bot?

Do it on the Gateway host, then unpin chats that are still stuck on Claude.

The FAQ lists the durable paths: openclaw models set with a provider/model ref, openclaw configure --section model, or an edit to agents.defaults.model in ~/.openclaw/openclaw.json. Onboarding can also choose Ollama and then Local or Cloud + Local. For a machine you actually own, the local path is: install Ollama, pull the model you intend to run, and point OpenClaw at Ollama’s native API. The provider docs are firm about the URL. Use http://127.0.0.1:11434 with no /v1 suffix. The OpenAI-compatible /v1 path breaks tool calling, and models can emit raw tool-call JSON as plain text. If Ollama is on another machine, the base URL is that host and port, still without /v1. Set api: "ollama" when you write the provider by hand. The placeholder API key the docs use for a local daemon is the literal ollama-local, or the OLLAMA_API_KEY environment variable set to that. It is not a secret you copy from a website.

Changing agents.defaults.model.primary does not rewrite existing session pins. If status says this session is pinned to one model and the config primary is another, and that the config primary will apply to new or unpinned sessions, this Telegram chat is the pinned one. Send /model default in it, session-scoped, so the pin clears. Other chats you never pinned pick up the new primary on their own. Cron jobs that inherit the default pick it up on the next run. Jobs with their own --model keep that job primary.

Agent and global updates from /model -a or -g can affect new sessions and existing unpinned ones. They do not rewrite other sessions’ explicit selections. Telegram button picks never become those broader writes. If you only tapped a model in the Telegram menu, you changed this chat. The next new DM can still be on Claude until the host config says otherwise.

What has to be true for the local model to answer in that same chat?

The Gateway has to be able to reach it, and the model has to fit the turn.

Ollama’s local-only mode is a daemon on a reachable host, serving local models, not a file you attach to Telegram. Cloud + Local can also see :cloud tags if you signed Ollama in. That is still Ollama’s cloud, which is not the same as “the weights are on my disk.” If the goal is a machine you can unplug from Anthropic, use a model you pulled, and check /model status until the ref does not point at Anthropic.

Cold local models time out more often than Claude’s API. The Ollama provider page calls that out and allows a longer timeoutSeconds, with an optional keep_alive so the weights stay loaded between turns. A first reply that fails after you switch is often a load, not a broken Telegram session. Retry once the daemon has the model resident. If it fails before any reply, a user pin stays failed. It will not spend your Claude key to paper over a cold start. That is what you asked for when you left the strict selection in place. If you wanted “try local, then Claude,” put the local ref in the configured primary and Claude in fallbacks, and do not pin the session with /model. Those are different policies. Mixing them up is how people think the swap “reverted.”

Tool calling is the other place a swap disappoints people who only checked that text came back. OpenClaw’s agent expects tools. The native Ollama API is the documented way to keep that. A model that cannot call tools will still occupy the Telegram chat. It will just be worse at the jobs you used Claude for. Read the model card you pulled. A tiny model on a Pi-class box can hold a conversation and still be the wrong primary for a Gateway that runs shell and browser tools. The swap is allowed. It is not automatically a good idea.

There is a separate utility model for short internal work: dashboard titles, some channel thread titles, progress narration, activity recaps. When you leave it unset, OpenClaw uses the primary provider’s declared small model when one exists. The docs name Anthropic’s as claude-haiku-4-5. An explicit utility model keeps its own provider. Switching the chat session to Ollama does not, by itself, prove those side calls moved. If the point of the swap is that Anthropic no longer sees this agent’s traffic, set the primary and look at the utility model instead of assuming one /model -s closed every path.

What should you leave alone?

Leave the Telegram bot token alone. Leave pairing approvals alone. Leave the chat. Creating a second bot to “be the local one” splits history and gives you two pairing problems. The model ref is the switch.

Leave fallbacks unset on a session you pinned, if the point is to stop using Claude. Leave them set on the default if the point is resilience. Do not put a public Ollama port on the internet so the Gateway can “see” it. Bind it where the Gateway already is, or on a tailnet host the Gateway can reach. A local model is only local if the network path is yours.

Leave the Gateway host awake. A local daemon on the same machine as the Gateway stops when that machine sleeps, and so does the bot’s ability to answer, even though the Telegram app on your phone still exists. The agent stops with the machine that runs the Gateway, and a model that lives on that machine stops with it too. Claude’s API would have had the same Gateway problem. It would not have had a second process to wake.

If an allowlist is set at agents.defaults.modelPolicy.allow, a local ref has to be permitted in full, ollama/ plus the exact id, or a provider wildcard. A bare filename is not enough once that list is active. The command fails before a normal reply. That is configuration, not Telegram rejecting the message. Fix the allowlist or pick a model /model list is willing to show.

A sane order for the same chat

Pull the local model and confirm the Gateway can call it with the native Ollama URL. In the Telegram chat you already use, send a session-only /model to the ollama/... ref and ask for something small. Read /model status. If you want this to stick for new chats, set the primary on the host, then /model default -s in any chat that status still calls pinned. Do not rotate the bot token. Do not open a new Telegram chat unless you want a new session on purpose. The conversation is allowed to change models. The thing you give up is Claude’s behavior on the next turn, not the chat itself.