Ollama Cloud solves a real problem: the largest models require hardware that small or medium-sized companies don’t want to buy. But “convenient access to power” turns into chaos if every service calls the cloud in its own way. Mature usage has one gateway.
Why one router, not direct calls#
Direct calls from multiple places mean scattered keys, no unified cost control, and the risk that personal data will leave without masking. A router (OpenClaw) is the single entry point to models: here, the decision is made on which model handles the task, here we mask PII, here we track cost, and fallback kicks in if the model returns an empty response. Such an LLM router is a single layer of control for the whole organization — no matter how many services rely on it.
Model selection for the task#
Not every task needs the largest model. The router directs classification and simple workflows to a small, inexpensive model, reserving power for tasks that truly require it (complex reasoning, long contexts). This is simultaneously the most important cost and quality lever.
In practice, most traffic can be handled by a smaller model class, leaving the most expensive power for a narrow slice of tasks. Below is an orientational mapping — we give cost relatively (orders of magnitude, not specific rates), because price lists change and depend on prompt length:
| Task type | Model class | Relative cost | When to choose |
|---|---|---|---|
| Classification, routing, tagging, simple selection | small | lowest | Short input, unambiguous answer, high volume |
| Data extraction, summarization, rewriting | medium | moderate | Structure and fidelity needed, but without multi-step reasoning |
| Complex reasoning, long context, document analysis | large | highest | The task needs a quality that only shows up with a bigger model |
The rule is simple: start with the smallest class that passes the quality test on your data, and raise it only where accuracy is genuinely lacking. How to pick a model for a specific task is broken down in detail in the article how to choose an AI model.
Cloud and GDPR in one workflow#
Ollama Cloud means processing outside your infrastructure — so treat it like any data export: masking PII before sending is mandatory, and sensitive paths are routed to a local model. For data that can’t leave, combine the cloud with self-hosting in a single, consistent router. Security and GDPR matter more than any single feature — how to set this up step by step is covered in the article on self-hosting and GDPR.
In practice, masking before a cloud call has several stages the router runs every time:
- Detect entities — find personal and sensitive data in the prompt: names, emails, phone numbers, national ID numbers, addresses, customer identifiers.
- Mask or pseudonymize — replace them with stable placeholder tokens (e.g.
CLIENT_1,EMAIL_1), keeping the mapping only locally. - Send the masked prompt to the cloud — the model sees the structure of the task but not the real data.
- Restore the values in the response on your infrastructure, based on the local map.
Some data we don’t mask but simply never release: paths touching documents under confidentiality, special-category data (e.g. health), or content whose disclosure risk is too high are routed by the router entirely to the local model. That is a deliberate decision in one place, not a hope that every developer remembers it.
Telemetry: see what you’re paying for#
One gateway provides one source of truth about usage: which tasks generate cost, how traffic is distributed across models, and where it’s worth shifting workloads to a local model. Without this observability, cost optimization is guesswork.
To make “see what you’re paying for” concrete, the router logs a set of fields on every call:
- model and class (tier) — which model handled the task and from which shelf (small/medium/large).
- input and output tokens — because these are what translate into cost.
- latency — response time, helpful when choosing between models of similar quality.
- estimated cost — computed from the token count and the rate of the given class.
- whether PII was masked — a trace that the path went through the required masking.
- whether a fallback or block fired — a signal that the model returned an empty response or the task was stopped.
These fields add up to a picture that lets you make decisions based on numbers, not impressions: where to lower the model class, which tasks to move locally, and where cost grows faster than value. The full cost breakdown of an entire agent — not just the model calls themselves — is laid out in the article how much an AI agent costs.
FAQ#
How does Ollama Cloud differ from self-hosting?#
Ollama Cloud is on-demand power without your own hardware — low entry threshold, variable cost. Self-hosting has a higher entry threshold but full control and predictable cost at scale. A hybrid of both is often optimal.
Can I use Ollama Cloud in compliance with GDPR?#
Yes, provided you mask personal data before sending, limit scope to the minimum, and route sensitive paths to a local model. The router enforces these rules in one place, instead of relying on each developer’s discipline.
Why use a router when I can call the API directly?#
Direct calls scatter control: cost, security, and model selection diverge across services. A router centralizes decisions, PII masking, fallback, and telemetry — the difference between an experiment and a production system.