Ollama is the model half of a local AI agent. Here are the two halves it does not ship.

No. Fazm is a consumer Mac app that ships with Claude Sonnet 4.6 as the default model, hardcoded as DEFAULT_MODEL at acp-bridge/src/index.ts line 1245. The interesting thing for someone researching Ollama is that the part of Fazm that reads and drives the Mac is completely model-agnostic. The mcp-server-macos-use binary speaks MCP over stdio and returns plain UTF-8 text; any model that can consume tool responses, including a local Ollama-served model, could be wired to the same perception and action layer. Fazm uses Claude because it is fast and already trained on tool use, not because the tree mechanism depends on it.

Ollama is a model-serving runtime. `ollama run llama3.1` gives you a REPL that returns text. It has no code path that reads your screen, no code path that synthesizes a mouse click, and no code path that types into the focused app. Turning a local model into an agent requires at least two more layers wrapped around it: a perception layer (something that reports what is on the screen as tokens the model can reason about) and an action layer (something that translates a model's text output back into CGEvent, keyboard, and shell calls). Ollama's scope deliberately stops before those layers begin.

Three reasons, all worse on small local models than on frontier cloud models. First, size: a base64-encoded 4K Retina screenshot is typically 500 KB to 5 MB of text in a tool response, versus a few kilobytes for a full AX tree dump. For a 7B local model with an 8K or 32K context window, that difference is the gap between one step and a hundred. Second, precision: the tree already has element roles, titles, and CGFloat frames. The model substring-searches for the word 'Send' and gets back `[AXButton] "Send" x:842 y:712 w:68 h:32 visible`. A VLM has to infer the same thing from pixels. Third, speed: a traversal of a real Fazm Dev window takes about 0.72 seconds and returns 441 elements. Encoding, shipping, and prefilling a 4K screenshot on a consumer GPU is slower.

A Swift binary that implements an MCP server over stdio and exposes six tools: macos-use_open_application_and_traverse, macos-use_click_and_traverse, macos-use_type_and_traverse, macos-use_press_key_and_traverse, macos-use_scroll_and_traverse, and macos-use_refresh_traversal. Under the hood it calls AXUIElementCreateApplication(pid) and AXUIElementCopyAttributeValue(kAXFocusedWindowAttribute), walks the tree depth-first, and emits one text line per element with role, title, x, y, width, height, and a visibility flag. The ACP bridge registers it at acp-bridge/src/index.ts lines 1056-1064 whenever the binary exists on disk. It is not gated to Claude, it is gated to whatever model the bridge is currently talking to.

Technically yes. The pattern is: run your Ollama model in the tool-use mode supported since Llama 3.1 and DeepSeek-R1, define the same six _and_traverse tool schemas, and proxy tool calls to an MCP server that wraps AXUIElement. Every one of those tools should return not just the action result but the post-action accessibility tree in the same tool response, because that is what collapses observe-act-observe into a single round trip. Fazm ships the server half of this stack as the bundled binary. The client half (the inference loop that speaks to Ollama instead of Anthropic) is the part you would write.

Most of it shows up in the prefill. A 500 KB base64 screenshot at ~1.3 bytes per token is on the order of 350K input tokens for a single observation step. On Anthropic's API that is expensive but tolerable. On a 7B Ollama model running on a Mac with 32 GB of unified memory, prefilling that many tokens is the difference between an interactive agent and a background task. The accessibility tree dump is closer to 10K tokens for the same screen, which is the range these models actually feel fast in.

On most of them. Finder, Mail, Calendar, Messages, Safari, Slack, Notes, Reminders, and the System Settings panel expose a full tree via AX. Catalyst apps (including the Mac WhatsApp client) also work, which is why Fazm bundles a separate whatsapp MCP that goes deeper into that specific app. The edge cases are apps that render directly to a Metal or OpenGL canvas and skip AX entirely, usually games and a few Qt or SDL ports. For those apps any local-AI-plus-Mac agent has to fall back to the screenshot path, which Fazm does via a separate capture_screenshot tool.

You can do that, and projects like the Hugging Face Open Computer Agent run Qwen2-VL-72B for exactly this reason. The tradeoff is that on a consumer Mac, a 72B VLM is too big and a small VLM is not accurate enough. A 7B to 32B text-only Ollama model paired with an AX tree dump tends to outperform a similarly-sized VLM paired with a raw screenshot, because the tree has already done the vision work. The tree approach essentially offloads 'where is the Send button' from the neural net into a 21 MB Mach-O that walks a C API in under a second.

Yes. Fazm. The desktop binary registers macos-use, playwright, whatsapp, google-workspace, and fazm_tools as builtin MCP servers (BUILTIN_MCP_NAMES at acp-bridge/src/index.ts line 1266). The system prompt at Desktop/Sources/Chat/ChatPrompts.swift line 56 explicitly forbids browser_take_screenshot for desktop apps and routes them through macos-use instead. The model is Claude, not Ollama, but the perception and action layers are the same ones a local-first implementation would need, and they are open to inspection on disk after any install.

Ollama in 2026 is the clear winner of the local-model-runtime layer; it hit 52 million monthly downloads in Q1 and HuggingFace hosts 135K GGUF-formatted models aimed at it. That layer is solved. The open frontier is not 'which local model runs fastest', it is 'what does the model look at, and what does the model control'. The answer that works on a Mac is the accessibility tree for perception and CGEvent-plus-AXPress for action. The answer that works everywhere a browser runs is Playwright. Ollama stays where it is strongest: model serving, prompt templating, and OpenAI-compatible APIs. Everything above it is the agent framework, and that is the layer most Ollama-on-Mac tutorials skip entirely.