Running a model locally is simple until the model does not fit, the context grows, or two agents need the same GPU. At that point, it becomes a memory-planning exercise.

Ollama Cloud lets local tools run hosted models, so you can use a larger model without changing the workflow you already have. It also brings plan limits, a network hop, and a provider dependency.

This guide compares the options.

Snapshot: Prices, limits, models, and integrations below were checked on 28 August 2026. This is a point-in-time guide, not a promise that a model tag or plan will be around forever.

What Ollama is

#

Ollama is software for running and using open models. It can download a model, run it on your machine, and make it available through a command-line tool, desktop app, and local API. The Ollama quickstart shows the basic flow on macOS, Windows, and Linux.

It is not a model or a coding agent. It is the layer in the middle:

model maker releases a model → Ollama runs the model → .NET app or coding agent sends requests

That middle layer is the reason Ollama shows up in so many local-AI setups. An application or agent can talk to one familiar interface while the selected model changes. By default, the model runs locally. Ollama Cloud adds the option to run selected models in Ollama’s hosted service instead. Ollama’s Cloud documentation describes this as offloading cloud models while keeping the same local tools.

Choose the setup that matches the job

#

You do not need to pick one option for every task. Keep private or offline work local, use the cloud for a large repository task, and put a small model-access layer in the application.

How Ollama Cloud works

#

Ollama’s Cloud documentation describes cloud models as hosted execution behind the same local workflow. Sign in, pull a cloud-tagged model, and carry on using the normal Ollama endpoint:

1
2
3

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-cloud

This lets a local agent or .NET app keep talking to http://localhost:11434 while model execution runs elsewhere. For a service deployment, Ollama also offers a direct API at https://ollama.com/api, using OLLAMA_API_KEY. Check /api/tags when you deploy because model names can change.

Your data leaves the machine

#

Ollama says it does not see prompts or data for local inference. For cloud-hosted models, it says it processes prompts and responses to run the service but does not store, log, or train on their content. This is still hosted processing. If your policy says the code cannot leave the machine, use local inference.

Ollama documents OLLAMA_NO_CLOUD=1 and disable_ollama_cloud for local-only operation. The FAQ has the details.

Cloud tags can be retired separately from local models. Pin the model ID in configuration, record it in telemetry, and keep a tested fallback. Ollama publishes retirement notices.

Plans and usage, as of 28 August 2026

#

Source: Ollama pricing, checked 28 August 2026.

This is not a simple monthly-token plan. Individual cloud limits reset on five-hour and seven-day windows, and usage varies by model plus input, cached-input, and output tokens. A long-context agent task can use capacity differently from a few chat prompts. Local runs are not provider-metered, but the machine is still the limit.

Choose a model by the work, then measure it

#

Start with the task, not the largest model your budget or hardware can reach:

1. What must it do? Coding, tools, structured output, vision, reasoning, or plain chat?
2. How much needs to fit? Repository files, search results, tool definitions, and the answer all share a context window.
3. What happens when it is wrong? A throwaway completion and a multi-file refactor deserve different quality bars.
4. What does “fast” mean? Quick first token, steady generation, several agents at once, or a cheap overnight batch?
5. Can you run it reliably? Check the model tag, data policy, region, limits, and fallback.

For local Ollama, model weights are only one factor. OLLAMA_NUM_PARALLEL grows the context-memory requirement; OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE affect loading and queueing; Flash Attention and OLLAMA_KV_CACHE_TYPE can reduce memory use for long contexts. The Ollama FAQ explains the defaults and trade-offs.

For coding agents, context is often the limit. Ollama’s current Codex CLI and OpenCode guides recommend or require at least 64K; Cline starts at 32K. Treat these as starting points. Test the agent with a real .sln, code changes, and tests.

Ollama’s API gives you total_duration, load_duration, prompt-evaluation, and output-evaluation timings. Add client-observed time to first token and wall-clock time for a fuller picture. The fields are documented in the API usage reference.

For a basic benchmark, use a short C# question, a refactor that must pass dotnet test, a repository-level task at the intended context size, and two concurrent requests. Record the model, provider, plan, region when known, context, fixture, runtime version, and failures. Measure completed work as well as tokens per second.

When another cloud fits better

#

Ollama Cloud keeps the local workflow familiar. If the job needs something else, another provider may fit better.

Compare providers with the same task, context, model revision, and definition of success. Do not compare a published best-case throughput number with an unrelated model.

Agent support needs testing

#

Ollama’s integration index currently includes Claude Code, Codex App/CLI, OpenCode, Copilot CLI, Droid, Goose, Pi, and several editors. A successful connection is only the first step.

Test each agent and model with a refactor, a failing-test diagnosis, a tool sequence, and a repository task. Tool calling, structured output, vision, and long-context planning depend on the model as well as the agent.

Keep the .NET integration simple

#

Start with Ollama’s native /api/chat endpoint for local and direct-cloud experiments. If the application needs provider-neutral composition, streaming, middleware, and telemetry, Microsoft.Extensions.AI gives you IChatClient.

Keep keys on the server, log the endpoint/model/context/timings, set timeouts and cancellation, and test the fallback. A small model-access layer is easier to maintain than provider calls throughout the codebase.

The takeaway

#

Use local Ollama when control and offline operation matter most. Use Ollama Cloud when you want a bigger model without changing your everyday workflow. Use a gateway, specialist provider, or dedicated capacity when model choice, latency, governance, or sustained throughput matters more than workflow continuity.

Choose the option that matches the work and verify it with your own tests.

Related reading and primary sources

#

• Running Local AI with .NET and Ollama
• Hybrid AI: Combining Local and Cloud Models in .NET
• LiteLLM: A Unified AI Gateway You Can Self-Host
• Building a Local AI Coding Workstation with Qwen3.8-27B and llama.cpp
• Ollama pricing, Cloud documentation, FAQ, and API usage metrics
• OpenRouter Models, Together AI inference, Fireworks serverless inference, Groq models, and Microsoft Foundry Models