How I use local and cloud AI

Linux gives part of my setup a persistent home for agents, supporting tools, and recurring work. I also use cloud agents when they suit the task. My daily machine is where I review results, make decisions, and pick up the next piece of work.

Persistence has a less glamorous side. A service can stay available while its instructions become outdated. A saved project note can describe yesterday's state accurately and still be wrong for today's task. Running the system means checking those differences and deciding which record needs to change.

I treat that maintenance as part of the work. Adding another capability is only useful if I can tell when it was used, what it produced, and whether the result belongs in the project. An inventory of installed tools tells me what might be possible. It does not tell me which workflows are dependable.

The agent host runs the process that coordinates a task. A model endpoint supplies model responses. Tools may read files, retrieve information, or operate software. Each connection has its own behavior and access boundary, even when the user sees a single conversation.

Ollama is a useful example of why the distinction matters. Its official documentation describes local model use as well as cloud-hosted models, and provides a way to disable its cloud features for local-only mode. Having Ollama installed is therefore insufficient evidence for a claim that an entire workflow stays on one machine.

I have also used an Ollama service alongside the rest of my setup. What matters for a particular task is the selected model route and the tools it can call. I want to know where the request is processed, what leaves the host, and which services can see the information.

A persistent setup can accumulate a convincing history of activity. I still need to open the artifact. If a task was meant to change a file, the file is the evidence. If it was meant to repair a workflow, I need to exercise the affected path. A completion message helps me find the result; it cannot replace inspecting it.

I apply the same distinction to maintenance. A successful health check can confirm that a service responds. It cannot establish that an agent retrieves the right project context or handles a difficult task well. Those need their own examples and checks. Keeping the claims separate helps me decide what to investigate next.

I also keep company work separate from personal experiments. Convenience is a poor reason to mix context or expand access. The useful setup is one where I can give a task the material it needs and understand the boundary around that work.

The choice between local and cloud changes with the work. A local service gives me control over the machine and its upkeep. A cloud service can take some of that infrastructure work off my hands. In either case, I still need to understand access, model routing, and how to recover when something fails.

For client work, I also think about the people who will use and maintain the setup after delivery. A service that only its original builder understands is difficult to hand over. I want the next person to know how it runs, where the important decisions live, and how to check the output.

That is the reason I keep working on my own environment. I can try an approach, inspect what breaks, and improve it before deciding where it belongs in a client brief.