OpenClaw on your hardware vs a Dot in OpenAI’s cloud: which one still answers if that vendor is down?

If the vendor that is down is OpenAI, the Dot stops answering. OpenAI’s getting-started page describes a Dot as an always-on agent powered by GPT-6 Astra with its own cloud computer. That computer is OpenAI’s, not a box in your house. OpenClaw still answers only when the Gateway host is up and the model it is calling is not the vendor that failed. A local Ollama model on that host can keep replying through an OpenAI outage. An OpenClaw agent whose selected model is an OpenAI API, or Ollama’s cloud, goes quiet with that provider. OpenClaw does not have a spare brain that switches on because you self-host the Gateway.

The hardware in the title is the Gateway and, if you chose one, the model runtime next to it. It is not a promise that every OpenClaw install survives every outage. The Dot has no such hardware unless you separately connect your own computer, and that connection still depends on the Dot being up.

What does a Dot lose when OpenAI is down?

The agent, the cloud computer, and the chat that drives them. The product is a conversation in ChatGPT plus a cloud computer with its own files, software, and browser sessions. Cloud work continues while your devices are off because OpenAI’s side is still on. The reverse is the outage: your laptop can be open and the Dot can still be unreachable. OpenAI’s status page has already listed Dots, ChatGPT conversations, and computer use as affected during incidents. Those are the same systems a Dot is made of. I have not found a help article that says the Dot fails over onto your machine and keeps taking tasks while OpenAI is unavailable.

Chat and the cloud computer can fail separately, and that is not a local backup. People have reported the Dot conversation still responding while its cloud computer shows unavailable. That report is a partial failure, not a documented mode you can plan on. When it happens, the Dot cannot open the computer where its files and browser sessions live. A reply in the chat is not the same as the agent finishing the job on that computer. If the status page says conversations and Dots are both degraded, you should expect neither.

Connecting your own computer does not change the vendor. Access to the local machine is optional and starts off. You turn it on in the ChatGPT desktop app, the computer has to stay online, and the app has to stay open while the Dot uses it. The help text says that with local access on, a Dot can use your local browser when its cloud browser is blocked. Read that sentence narrowly. It assumes the Dot is running and able to start the local task. A blocked cloud browser is not an OpenAI-wide outage. If ChatGPT itself cannot answer, there is no agent left to send work to the laptop. Revoke access removes the local path. It does not install a second agent that lives only on the laptop.

When does OpenClaw still answer?

When the process that answers is on a machine you control, and the model weights or the model server are on a machine you control. OpenClaw is a self-hosted Gateway. There is no OpenClaw cloud that receives the message if your host is off. Channels, sessions, and the model call all sit behind that Gateway. If the host is asleep, nobody answers, including a local model. If the host is up and the selected model is local, an OpenAI outage is someone else’s problem.

Ollama is the local path the docs actually specify. OpenClaw talks to Ollama’s native API, at a base URL like http://127.0.0.1:11434 with no /v1 on the end, and a placeholder key of ollama-local for a machine on your network. The provider page lists three modes: cloud plus local, cloud only through ollama.com, and local only. Local only is the one that still answers when outside vendors are down. Cloud only is another vendor. A signed-in daemon that can also call :cloud models will fail those cloud model names even while a model you pulled to disk still runs. Pick the model that is on disk. A name that ends in a cloud route is not a local model because Ollama is installed.

The docs are explicit that a chosen model does not quietly swap. Selecting a model is an exact choice: if that base URL is unreachable, the next reply fails with the provider error instead of falling back to another model. A pin you set in chat is the same kind of strict choice. Changing the default primary later does not rewrite a pin. If the agent your Telegram chat is using is pinned to a hosted model, an outage of that host produces an error, not a surprise answer from the local model you installed last week. You can point that same chat at a local model. You have to do it before the outage, or during it, on purpose. The Gateway will not invent the switch.

Which OpenClaw setup dies with a vendor anyway?

Any setup whose model call leaves the building. A Gateway on a mini PC in the closet is still a client of Anthropic if the selected model is Claude, and a client of OpenAI if the selected model is an OpenAI API model. The mini PC being yours does not cache those APIs. Tokens, rate limits, and outages belong to the provider. When that provider’s status page goes red, the Gateway can be healthy and the reply can still fail. Look at the model ref the agent is actually using, not at the sticker on the case.

Ollama Cloud is the easy one to misread. The same provider plugin that talks to localhost can be pointed at https://ollama.com. That install is self-hosted OpenClaw and a hosted model. It will not answer an Ollama cloud outage. It also will not answer an OpenAI outage if you had assumed “local” without checking the base URL. The check in the docs is plain: from the Gateway machine, ask the tags endpoint on 127.0.0.1:11434, and look at openclaw models status. If the base URL is a public host, you have a vendor again.

The host has its own outage, and no vendor status page will mention it. Disk full, the service not installed, a laptop that sleeps, a model that was never pulled, a daemon that is not running under the same user as the Gateway. Those stop the reply while OpenAI is having a perfectly fine day. A Dot’s failure mode is concentrated: OpenAI is up or it is not, with the partial computer-unavailable case in between. OpenClaw’s failure mode is a list. The list is shorter only after you have watched one reply succeed with the network cable to the model provider unplugged. I would actually do that once. Pull a local model, set it, and confirm a reply with the hosted keys unused. Until that test passes, “on your hardware” is a hope.

What about the jobs, not just the reply?

A Dot’s job lives on the cloud computer. Files, installed software, and browser sessions are there. An OpenAI outage pauses that work. It does not move the files to your laptop. When the service returns, the getting-started page says the computer keeps state between periods of use. I have not found a retention clock for a multi-hour outage, so I will not invent one. A user report of a computer stuck on unavailable also said there was no restart control and no promise that the existing state was intact. Treat restoration as something you verify, not something the architecture guarantees in a help article.

An OpenClaw job lives on the host. Transcripts and auth profiles are under the Gateway user’s OpenClaw directory. A provider outage does not delete them. It also does not advance the task. When the model is reachable again, the session is still on disk because it never left. A local model that is too small for the task will answer and still do the task badly. Survival is not quality. If the work needed a hosted model you trust, the honest outage plan is to wait, not to pretend the local model is the same agent with the network removed.

Plugins and channels fail on their own clocks. Telegram can be up while OpenAI is down, which is why a local OpenClaw can still talk to you in the same chat. Telegram being down stops the message either way. A Dot’s Slack or mobile app is another door into OpenAI. If OpenAI is down, a second app does not route around it. If only Slack is down, the Dot can still be reachable in ChatGPT. Match the outage to the dependency before you blame the product that happens to be in front of you.

Which one do you keep for the afternoon the status page is red?

Keep OpenClaw on a host that stays on, with the model it will use during the outage already selected and already local, if the vendor you are worried about is OpenAI or another model API. Keep a Dot if you want the cloud computer and you accept that OpenAI’s outage is your outage. Do not describe the Gateway as outage-proof when its model ref points at a hosted API. Do not describe a connected laptop as a Dot backup when the agent that would use the laptop is itself an OpenAI service.

The split in the title is real only for one configuration. OpenClaw on your hardware, calling a model on that hardware, still answers when OpenAI is down. A Dot in OpenAI’s cloud does not. Every other mix, including OpenClaw calling OpenAI, fails with the vendor you chose.