Running Agentic LLM Workflows Locally: Ollama vs a VS Code Agent Extension

TwoTwo quite different decisions get bundled together whenever someone asks "should I run my AI coding agent locally": which model runs the reasoning, and which harness turns that reasoning into edited files, executed commands and browser actions. Ollama answers the first question — it is a local model runtime, not an agent. The agent layer, historically supplied in this space by the VS Code extension Roo Code, is what plans tasks, edits files and asks for approval before running commands. This piece looks at what each actually does, how they fit together, and what changed in 2026 when Roo Code shut down its extension — a useful reminder that "agentic coding tool" is presently one of the least stable categories in software to write about.

Ollama: a Local Model Runtime

OllamaOllama is an open-source tool for downloading and running large language models on your own machine — macOS, Linux, and Windows [1]. It wraps llama.cpp-style inference in a small daemon with a command-line client and a local REST API, so the mental model is close to Docker: pull an image (model), run it, talk to it over a local port.

Installation is a single command on Linux and macOS:

curl -fsSL https://ollama.com/install.sh | sh

Models come from Ollama's library (llama.com/library at the time of writing hosts variants of Llama, Mistral, Gemma, Phi and DeepSeek, among others) and are fetched with pull, then invoked with run:

ollama pull llama3.2
ollama run llama3.2

The server listens on port 11434 by default and exposes two generation endpoints: /api/generate for single-turn completions and /api/chat for multi-turn conversations that carry message history, plus supporting endpoints for pulling, listing and inspecting models [2]. A minimal call looks like:

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.2",
  "messages": [{"role": "user", "content": "Explain quantum computing."}]
}'

Behaviour is customised through a Modelfile — a small declarative build script, not unlike a Dockerfile, that names a base model and layers configuration on top of it. The core instructions are FROM (required — the base model or a GGUF weights file), PARAMETER (runtime settings such as temperature or num_ctx, the context window size), TEMPLATE (the prompt template sent to the model), SYSTEM (a system message), and, for fine-tuned variants, ADAPTER for LoRA/QLoRA adapters [3]. A working example:

FROM llama3.2
PARAMETER temperature 0.7
PARAMETER num_ctx 4096
SYSTEM """You are a concise assistant that answers in UK English."""

ollama create mymodel -f Modelfile
ollama run mymodel

That syntax is genuine and matches Ollama's own reference — worth flagging because a lot of secondary tutorials reproduce it with subtle drift (missing quotes around SYSTEM, invented instructions). Running models locally means inference cost is hardware, not API billing, and prompts never leave the machine — which matters for anything touching client code, credentials in a working tree, or regulated data. The trade-off is that you now own model updates, GPU/CPU sizing, and the ceiling on model quality: local models trail the largest hosted models on hard reasoning and long-context tasks, and Ollama's own benchmarking claims are limited — most performance figures in this space come from the model providers' own published benchmarks (Llama, DeepSeek, and so on), not from Ollama itself, so treat throughput comparisons circulating in blog posts with the same scepticism you'd apply to any unaudited number.

The Agent Layer: What Roo Code Was, and What Replaced It

OllamaOllama runs a model; it does not decide what to do with one. That is the job of an agent harness — something that turns a task description into a plan, edits files, runs shell commands, and asks a human before doing anything destructive. In the VS Code ecosystem, Roo Code (a fork of the earlier Cline project) filled this role: an extension that could read a workspace, propose diffs, execute terminal commands with approval gates, and — relevant here — point at any OpenAI-compatible or Ollama-hosted endpoint instead of a cloud model [4]. Wiring it to a local model meant setting the provider to Ollama, giving it the base URL (http://localhost:11434) and picking a pulled model from the list the extension queried automatically.

That description is now historical. In April 2026 the Roo Code team announced they were sunsetting the product, and by 15 May 2026 the VS Code extension, its cloud service and router were shut down and the GitHub repository archived, with the original team moving to a hosted cloud agent (Roomote) instead of an editor-embedded one [5]. A community fork (ZooCode) has attempted to keep the extension alive, but the vendor-maintained tool this piece originally set out to compare no longer exists in the form most of the coverage of it describes.

The practical successor — and the tool anyone following this comparison today should actually install — is Cline, the project Roo Code was forked from, and the one Roo's own shutdown notice pointed users back toward. Cline is an open-source (Apache-2.0) autonomous coding agent, distributed as a VS Code/JetBrains extension, an SDK and a CLI, that supports the same bring-your-own-model pattern: point it at Anthropic, OpenAI, OpenRouter, or a local Ollama server [6]. The architectural comparison below applies to Cline (and to Roo Code's surviving forks) as much as it did to Roo Code itself, because the pattern — editor-embedded agent talking to a locally- or cloud-hosted model over an HTTP API — is the constant; the specific extension name is not.

Comparing the Two Axes

TheThe useful comparison is not "Ollama vs the extension" — they are not substitutes — but two separate axes that combine:

• Where the model runs. Local (Ollama, or a similar runtime like LM Studio or llama.cpp directly) keeps data on the machine and removes per-token billing, at the cost of hardware spend, manual updates, and a real capability gap against frontier hosted models on hard multi-step reasoning. Cloud model providers (Anthropic, OpenAI, and others) remove the hardware and update burden and currently lead on capability, at the cost of sending code and prompts off-machine and paying per token.
• What drives the editing loop. An editor-embedded agent (Cline, and previously Roo Code) lives where the code already is, applies diffs you review inline, and is well suited to iterative, supervised work. A model runtime like Ollama has no opinion about editing loops at all — it is a dependency other tools call into, whether that is an editor extension, a custom script, or a terminal harness.

The two axes are independent: a locally-run 8B model wired into Cline gives you a fully offline, zero-marginal-cost agent with reduced reasoning quality; a hosted frontier model wired into the same extension gives you stronger reasoning at the cost of sending your codebase over the network per request. Teams handling sensitive code or working offline generally accept the capability trade for the first combination; most teams optimising for output quality choose the second. There is no tool-level reason you can't switch between the two per-task — the point of the provider abstraction both extensions expose is exactly that it costs you a settings change, not a rewrite.

A Minimal Agent Loop Against Ollama's API

ForFor anyone who wants to see the mechanics rather than trust an extension's UI, a bare agent loop against Ollama's chat endpoint is short enough to be worth reading end to end:

import requests

class OllamaAgent:
    def __init__(self, model_name, base_url="http://localhost:11434"):
        self.model_name = model_name
        self.api_url = f"{base_url}/api/chat"
        self.history = []

    def send(self, prompt):
        self.history.append({"role": "user", "content": prompt})
        payload = {
            "model": self.model_name,
            "messages": self.history,
            "stream": False,
        }
        response = requests.post(self.api_url, json=payload, timeout=120)
        response.raise_for_status()
        reply = response.json()["message"]["content"]
        self.history.append({"role": "assistant", "content": reply})
        return reply

agent = OllamaAgent("llama3.2")
print(agent.send("Write a Python function that returns the nth Fibonacci number."))

This is deliberately minimal: no file access, no command execution, no approval gating. That gap — between "can call a model over HTTP" and "can safely propose and apply changes to a real codebase" — is precisely the work an agent harness like Cline does, and it is substantial: sandboxing shell commands, diffing and applying edits, tracking multi-step plans, and giving a human a chance to say no before anything runs. Reimplementing it from a raw API loop is a reasonable learning exercise; it is not a substitute for the harness in daily use.

Related Topics

• LLM-Based Model Explanation — interpretability techniques for understanding what a model is actually doing, relevant when trusting an agent's plan.
• CLI-First — why command-line-first tooling composes better with agent harnesses than GUI-only workflows.

References

1. Ollama, official documentation and download. https://ollama.com and https://docs.ollama.com/
2. Ollama API reference (generate and chat endpoints). https://github.com/ollama/ollama/blob/main/docs/api.md
3. Ollama, Modelfile reference. https://github.com/ollama/ollama/blob/main/docs/modelfile.md
4. Roo Code documentation, "Using Ollama With Roo Code" (archived reference; product discontinued May 2026). https://docs.roocode.com/providers/ollama
5. RooCodeInc/Roo-Code, GitHub repository (archived 15 May 2026) and sunset notice. https://github.com/RooCodeInc/Roo-Code
6. Cline, open-source autonomous coding agent. https://github.com/cline/cline