Ollama Cloud Models 2026: What :cloud Tags Really Do

By AIFoss · 10 min read
ollamaprivacyselfhostedcloudai

TL;DR: Ollama model tags ending in :cloud don’t run on your hardware — they route every prompt to Ollama’s datacenter servers through the same API your local models use. Ollama’s privacy policy promises zero retention and no training, but you’re still trusting a third party. If you chose Ollama for privacy, audit your model list today.

:cloud tagsLocal GGUF on your GPUCloud GPU rental (RunPod)
Best forFrontier-size models with zero setupPrivacy, offline use, zero marginal costBig models with full control of the box
Where prompts goOllama’s servers (+ partner endpoints for some models)Nowhere — your machine onlyYour rented VM — you control logging
Price / CostFree tier (rate-limited), paid plans aboveElectricity + hardware you own~$0.30–$6/hr depending on GPU
The catchPrompts leave your machine; API looks identical to localVRAM caps you at ~30B-class models on one cardYou manage the stack yourself

Honest take: :cloud tags are a genuinely useful escape hatch for the occasional 480B-class job, but they should never have shipped with an API surface indistinguishable from local inference — check ollama ps, and if privacy is the whole point of your setup, pull explicit local tags only.

Ollama built its reputation on one sentence: your data never leaves your machine. That sentence is still true — for local models. But since the v0.30 series, the model library has carried a second category: cloud models, tagged with a :cloud suffix (written -cloud on some model pages). qwen3-coder-480b:cloud, kimi-k2.6:cloud, and minimax-m3:cloud all look like ordinary pulls, respond to the same ollama run command, and answer on the same localhost:11434 API. None of them execute a single token on your GPU.

That design is convenient and quietly dangerous. Convenient because a 480B mixture-of-experts coding model becomes available to a laptop with no VRAM at all. Dangerous because the whole point of running Ollama, for a large share of its users, is that prompts stay home — and the difference between “stays home” and “goes to a datacenter” is now three characters at the end of a tag that plenty of tutorials copy-paste without comment.

Tested against Ollama v0.32.5 (released July 27, 2026). Everything below assumes that version or newer.

How :cloud routing actually works

When you run a cloud-tagged model, the Ollama client doesn’t download weights. It downloads a small manifest that tells your local Ollama server to proxy requests for that model name to Ollama’s hosted inference fleet. Your prompt goes out over TLS to ollama.com infrastructure, gets processed on datacenter GPUs, and the response streams back through your local server as if it had been generated in your living room.

Three practical consequences:

  1. The API surface is identical. Any tool pointed at http://localhost:11434 — Open WebUI, Continue.dev, a Python script — works unchanged. Nothing in the response schema says “this came from a server in another country.”
  2. You need an account. Cloud models require ollama signin with a free ollama.com account. The free tier is rate-limited (Ollama adjusts the exact hourly and daily caps over time — check ollama.com for current numbers), with paid plans above it. This is the clearest tell: local Ollama has never needed an account for anything.
  3. Model naming is the only routing signal. Drop the suffix and ollama pull qwen3-coder:30b gives you real local weights. Keep it and you’ve configured a thin client.

None of this is hidden, exactly — Ollama documents cloud models openly. But “documented” and “obvious at the moment of use” are different things, and the moment of use is where privacy decisions actually happen.

The 60-second audit: is your setup actually local?

Run this on any machine where privacy matters. First, list what’s installed:

$ ollama list
NAME                        ID              SIZE      MODIFIED
qwen3-coder-480b:cloud      a1b2c3d4e5f6    -         2 days ago
qwen3-coder:30b             f6e5d4c3b2a1    18 GB     3 weeks ago
gemma4:12b-it-qat           0a1b2c3d4e5f    7.0 GB    5 weeks ago

Two tells in that output: the :cloud suffix in the name, and the missing size column — there are no weights on disk to measure. Now confirm what’s actually consuming hardware during a request. Start a generation, then in a second terminal:

$ ollama ps
NAME                        ID              SIZE      PROCESSOR    UNTIL
qwen3-coder-480b:cloud      a1b2c3d4e5f6    -         cloud        4 minutes from now

A local model shows something like SIZE 18 GB and PROCESSOR 100% GPU. A cloud model shows no size and no local processor allocation, because your GPU is idle — nvidia-smi during inference will confirm near-zero VRAM movement. If you see that combination and you didn’t knowingly opt in to hosted inference, you’ve found a leak in your privacy posture.

The third check is the network itself. Fully local inference generates no outbound traffic during generation. If you want proof rather than trust, watch for it:

# Bind Ollama to loopback so nothing else on the LAN can reach it
export OLLAMA_HOST=127.0.0.1

# During a local generation, this should show no new connections to ollama.com
ss -tnp | grep ollama

OLLAMA_HOST=127.0.0.1 doesn’t block cloud routing — outbound proxying still works — but it closes the separate and worse problem of your Ollama port being reachable from outside, which is how 175,000 Ollama instances ended up exposed to the public internet. For a hard guarantee against cloud routing, block outbound traffic from the Ollama process at the firewall, or simply never sign in: no account, no cloud inference.

What Ollama says happens to your prompts

Ollama’s privacy policy is, credit where due, one of the stronger ones in this space. For cloud models it states that prompts and responses are processed transiently to provide the service, are not logged, are not retained, and are never used for training. For models served through hardware partners, Ollama says it requires the same zero-retention, no-training terms contractually.

That last clause deserves more attention than it gets. Not every :cloud model runs on infrastructure Ollama owns. An open issue on the Ollama GitHub tracker (#14279) asks whether the cloud version of Qwen3.5-397B-A17B is served through Alibaba’s own API endpoint — an endpoint whose standard terms retain prompts and responses — and as of early August 2026 the issue has no maintainer answer. I’m not claiming your prompts are being retained; I have no evidence of that. The point is narrower and more important: with a :cloud tag, the retention question is answered by policy documents and contracts you can’t inspect. With local weights, it’s answered by physics.

If your threat model includes “my prompts must not exist on anyone else’s hardware, ever” — legal documents, medical notes, proprietary code under NDA — then no policy wording closes that gap. Only local execution does.

The trap I actually hit: a coding agent that silently went hosted

This one cost me an afternoon. I’d set up a coding agent against localhost:11434 on a workstation whose 24GB RTX 3090 had been running qwen3-coder:30b for months. While testing bigger models I pulled qwen3-coder-480b:cloud, ran a few benchmarks, and moved on — but the agent’s config had a model-name wildcard that preferred the largest available tag. For two days, every completion request, including ones touching a client codebase, routed through hosted inference. Nothing failed. Nothing warned. Responses were actually better, which is exactly why I didn’t look.

The fix, and the lesson, in three steps:

# 1. Remove cloud tags entirely from privacy-sensitive machines
ollama rm qwen3-coder-480b:cloud

# 2. Pin explicit local tags in every client config — never wildcards
#    (Continue.dev, Open WebUI, aider: "model": "qwen3-coder:30b")

# 3. Sign out so future cloud pulls fail loudly instead of working silently
ollama signout

Step 3 is the real safety net. An unauthenticated Ollama cannot route to cloud models at all, so a stray :cloud tag in someone’s shared config errors out instead of quietly working.

Cloud tag vs. local alternative, model by model

The models offered as :cloud are exactly the ones too big for consumer hardware — that’s the sales pitch. Here’s the honest local counterpart for each, sized for real machines:

Cloud tagWhat it isFully-local alternativeHardware for the local option
qwen3-coder-480b:cloud480B/35B-active MoE coderqwen3-coder:30b — strongest coder most people can run24GB GPU (RTX 3090/4090 class)
kimi-k2.6:cloud~1T/32B-active MoEUnsloth 1.8-bit GGUF of Kimi K2.7 — barely — or Qwen3.6-35B-A3B24GB GPU + 256GB RAM for K2.7; 24GB GPU for Qwen3.6
minimax-m3:cloud1M-context frontier MoE (non-commercial license)GLM-5.2 2-bit GGUF, or accept a smaller context locally24GB GPU + 256GB RAM offload for GLM-5.2

Two things jump out of that table. First, for coding specifically, the local 30B option is closer to the 480B cloud model than the parameter counts suggest — the gap is real but it’s “senior dev vs. staff dev,” not “usable vs. useless.” Second, the true frontier models genuinely don’t fit consumer hardware at meaningful quality, and pretending otherwise helps nobody.

Which raises the third option the :cloud pitch skips: renting a GPU you control. A RunPod instance running vLLM gives you datacenter-class hardware where you decide what gets logged, for roughly $0.30/hr for a 24GB card up to ~$6/hr for multi-GPU configurations. That’s the middle ground for “too big for my RTX 4090, too sensitive for someone else’s API.” If you’re weighing buying versus renting long-term, the GPU buying guides at runaihome.com cover that math in detail.

When :cloud is the right call — and when it never is

Use cloud tags without guilt when:

  • The prompts are things you’d paste into any hosted chatbot anyway — public code, blog drafts, general questions.
  • You need a frontier-size model a few times a week, which makes both a hardware purchase and an hourly rental wasteful.
  • You’re evaluating whether a 480B model is enough better than your local 30B to justify infrastructure spend. Benchmarking through :cloud before committing is exactly what it’s good for.

Keep them off the machine entirely when:

  • The machine processes anything under NDA, HIPAA, GDPR special categories, or attorney-client privilege. Zero-retention promises are not a compliance substitute for data never leaving.
  • Other people or agents share the Ollama instance. My wildcard story above generalizes: you can’t audit every client config forever, but you can refuse to sign in.
  • You’re building a product whose privacy page says “inference runs locally.” One dependency update that prefers a bigger model tag and that sentence becomes false.

FAQ

Does pulling a :cloud model send my existing local data anywhere? No. Pulling only fetches a manifest, and local models keep running locally regardless of what else is installed. Data leaves your machine only when you send a prompt to a cloud-tagged model.

Can I block cloud routing permanently without watching my config forever? Yes — don’t sign in (or run ollama signout). Cloud inference requires an authenticated ollama.com account, so an unauthenticated instance fails loudly on any :cloud request. For defense in depth, add an outbound firewall rule for the Ollama process.

Is Ollama’s zero-retention claim trustworthy? It’s a clear written commitment, which beats most of the industry, and no contrary evidence has surfaced. But models served via partner endpoints add a contractual layer you can’t verify yourself (see ollama/ollama#14279). Trust it for convenience workloads; don’t lean on it for regulated data.

Sources

  • RTX 3090 — 24GB VRAM, the used-market sweet spot for running 30B-class local models
  • RTX 4090 — same 24GB but roughly double the inference speed for dense models

Was this article helpful?