Try to ollama run qwen3-coder:480b on a 32 GB laptop and it ends one way: it doesn't. A 480-billion-parameter model, even quantized to four bits, wants far more memory than a personal machine has. For years that was the hard ceiling on running models locally — the model you could use was the model that fit in your VRAM, full stop. You either bought a workstation with three GPUs or you gave up and pointed your code at somebody's hosted API, which meant a different SDK, a different auth story, and your requests leaving the building.

Ollama's cloud models, in preview since September 2025, remove that ceiling without touching the thing that made local Ollama worth using in the first place: the interface doesn't change. You still talk to localhost:11434. Your scripts, your editor plugin, your OpenAI-compatible client — none of them learn anything new. Only the compute leaves the machine.

The whole trick is a suffix

A cloud model is an ordinary model name with -cloud appended. At launch the roster was small and pointed at the workloads that hurt most on consumer hardware:

qwen3-coder:480b-cloud
gpt-oss:120b-cloud
deepseek-v3.1:671b-cloud

You need Ollama v0.12 or later and an ollama.com account. Sign in once, then run the model exactly as you would a local one:

ollama signin
ollama run qwen3-coder:480b-cloud

The load-bearing part of that command is cloud. It tells the local daemon to route inference to Ollama's infrastructure instead of trying — and failing — to hold 480B parameters in memory. There is no multi-gigabyte download waiting to happen first. When you pull a cloud model, the daemon fetches only a tiny manifest of metadata, a few hundred bytes describing the model, and nothing else. Run ollama ls afterward and the cloud entries show a size of -, because there is nothing on disk to measure.

That is the sleight of hand worth appreciating: the model appears in your local model list, answers on your local port, and behaves like every other model you have — but the weights never touch your SSD and never fight your GPU.

What actually runs where

It helps to be precise about which half of the system stays on your machine and which half crosses a network boundary, because the mental model matters when something breaks.

Stays local:

the CLI and the interactive prompt
the API surface — you are still calling http://localhost:11434
your authentication state; the local daemon is signed into your account and attaches the credentials for you

Goes remote:

the model weights
the inference compute
the request itself, which leaves your machine and travels to Ollama's datacenter-grade hardware

So the daemon is acting as a transparent proxy. A request hits localhost, the daemon notices the -cloud suffix, staples your auth on, and forwards it. From the perspective of any tool sitting on top — Open WebUI, the Python SDK, the JavaScript SDK, a raw curl — nothing distinguishes a cloud call from a local one. That compatibility is the actual product. The big models are the headline; the fact that your existing wiring keeps working is why it's usable.

Two ways to call it from code

There are two access patterns, and picking the wrong one is the most common early mistake.

Through the local daemon (the hybrid path), you keep the -cloud suffix and need no key in your code, because the daemon already holds your session:

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Explain a B-tree"}],
  "stream": false
}'

Directly against ollama.com, you drop the suffix, talk to the remote host over HTTPS, and authenticate with an API key generated at ollama.com/settings/keys:

export OLLAMA_API_KEY=your-key-here
curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{"model": "gpt-oss:120b", "messages": [{"role": "user", "content": "Explain a B-tree"}]}'

Use the first pattern on a developer machine where the daemon is already signed in. Use the second from a server or a container where you don't want a running daemon in the loop — it's a plain hosted endpoint at that point. The Python client is the same object either way; you just change the host and pass the bearer header.

The privacy line, and the caveats it doesn't cover

The pitch leans hard on one sentence, and it's worth quoting exactly:

Ollama's cloud does not retain your data to ensure privacy and security.

For a lot of teams that no-retention posture is the difference between "we can try this" and "legal says no." Take it as stated, but read it for what it is: a claim about retention, not a claim that your prompts never leave the building. They do. That is the trade you are making the moment you type a -cloud suffix.

Two operational caveats fall out of that, and neither is in the marketing copy. First, cloud models need connectivity — they will not work on a plane, in a hotel, or on flaky Wi-Fi, and a local-only fallback is a genuinely different model, not the same one degraded. Second, you have inherited a distributed system's failure modes. A cloud model can be unreachable because of the network, your account, a quota, or a remote outage — none of which can happen to weights sitting on your own disk. Build the retry and the fallback you would build for any external dependency, because that is now what it is.

What it costs, right now

At preview the terms are deliberately simple: it's free to try with a free account, and there are hourly and daily limits in place to keep capacity sane. The blog is explicit that metered, usage-based pricing is coming so you can consume the larger models in a measured way — the free preview is the on-ramp, not the destination. Plan for the day the meter turns on rather than wiring a 671B model into a hot production path on the assumption it stays free.

The takeaway

Don't think of this as "Ollama added a cloud." Think of it as localhost:11434 becoming a stable contract that can front hardware you don't own. That's the reusable idea: keep one local interface your whole toolchain already speaks, and let a suffix decide whether the request is served from your GPU or a datacenter's. Pick one 480B-class model, run it behind the exact client you already use, and watch every downstream tool keep working unchanged. If nothing in your stack had to be rewritten, you've understood the point — and you've also found the one dependency you now need to write a fallback for.

Sources: Cloud models — Ollama Blog, Cloud — Ollama Docs