Local MLX model for desktop loops: the one settings field that wires it in

No, and that is the design. Fazm spawns the open source claude-agent-acp 0.29.2 (acp-bridge/package.json) as its agent loop, which speaks the Anthropic Messages API. To use a local MLX model you put a small Anthropic-compatible HTTP server in front of MLX (claude-code-mlx-proxy, vllm-mlx, mlx-omni-server, claude-code-local, or LM Studio 0.4 plus its /v1/messages endpoint). Fazm then routes through that server. The agent loop never imports MLX. The bridge stays Anthropic-shaped. Only the URL changes.

One field. Settings > AI Chat > toggle Custom API Endpoint, paste your local URL (the placeholder shown in the field is a generic proxy URL, but 127.0.0.1 plus whatever port your bridge picked is fine). On submit the bridge is restarted via restartBridgeForEndpointChange. Under the hood that field is an @AppStorage value at SettingsPage.swift line 885 keyed customApiEndpoint, and the bridge reads it on spawn at ACPBridge.swift lines 468-470 and exports it as ANTHROPIC_BASE_URL. That is the entire surface area.

Below 8B you will get the loop confused on multi-step tool sequences. 13B is the floor where you can reliably finish a 6-8 step desktop workflow that touches two apps. 30B class (Qwen2.5-Coder-32B-Instruct in 4-bit MLX, Llama-3.3-70B in 4-bit MLX on a 64GB Mac) is where it starts feeling like a normal Claude session, with the catch that prefill speed becomes the bottleneck once accessibility-tree input gets long. Generation tok/s past about 25 stops mattering; what matters is how fast the prefill chews through the system prompt plus tool schemas plus current screen state on each turn.

It does, and you can use a vision MLX model if you want, but the math punishes you. A typical macOS window vision-tokenizes to roughly 1500-3000 input tokens. The same window through the macOS accessibility API serializes to roughly 200-400 tokens of role+text+bbox per element. On a 13B MLX model that is the difference between two-minute turns and twelve-minute turns. Fazm exposes both paths: capture_screenshot is a tool the loop can call deliberately, but the default screen-state representation goes through the macos-use MCP server (bundled binary at MacOS/mcp-server-macos-use, registered in acp-bridge/src/index.ts line 1687) and feeds the model a compact tree, not pixels.

That is the bridge's problem, not the loop's problem. claude-code-mlx-proxy and vllm-mlx both translate the Anthropic tool-use block format to whatever native format your model speaks (Hermes-style, Llama-3.1-style, Qwen function calls) and back, so the agent loop on the fazm side keeps emitting valid Anthropic Messages and never knows the model wasn't trained on them. mlx-omni-server presents OpenAI-format tools, so for fazm specifically you want a bridge that explicitly speaks /v1/messages, not /v1/chat/completions. Read the bridge's README before picking a model: each one has a recommended set of tool-trained MLX checkpoints under huggingface.co/mlx-community.

Yes. The 20 stdio tools (execute_sql, capture_screenshot, request_permission, scan_files, ask_followup, routines_create, routines_list, routines_update, routines_remove, routines_runs, save_knowledge_graph, save_observer_card, speak_response, set_user_preferences, complete_onboarding, extract_browser_profile, edit_browser_profile, query_browser_profile, check_permission_status, and one more) are defined in acp-bridge/src/fazm-tools-stdio.ts and registered with the agent loop independently of the model behind it. The cron scheduler at acp-bridge/src/cron-runner.mjs spawns a fresh ACP session against the same bridge on each scheduled fire. From the model's point of view there is just a tool schema and the same Anthropic Messages format. The runtime swap is invisible to the rest of the system.

Tool-call discipline. A frontier model will plan a 6-step sequence and dispatch tools in the right order. A 13B MLX model will sometimes call the same tool twice in a row, sometimes skip a confirmation, sometimes return malformed JSON in a tool-input field. The 10s/120s/300s timeout tiers in acp-bridge/src/index.ts (TOOL_TIMEOUT_INTERNAL_MS, TOOL_TIMEOUT_MCP_MS, TOOL_TIMEOUT_DEFAULT_MS at lines 114-116) keep a stuck call from freezing the whole agent, but you will hit more of them. Mitigation is shorter system prompts, fewer tools loaded per session, and using the ask_followup tool aggressively so the model checks in instead of guessing.

Yes. Anything below 7B routinely fails to emit the tool-use block format reliably enough for the loop to stay in sync, even when the bridge pretends to translate. A 7B Qwen-Coder will limp through a single-app task. A 13B will do real desktop work for short sessions. A 30B 4-bit will hold up for an hour. A 70B 4-bit on a 64GB Mac is the comfortable floor for doing useful multi-app work all day, but you will pay for it in prefill latency. The cleanest test is: ask the model to capture a screenshot, name what it sees, then click the closest button to a specific element. If it does not chain those two tool calls correctly, the loop will not survive a real workflow.

Today, no. customApiEndpoint is a single field. Either it is empty (default Anthropic) or it has a value (your bridge). The toggle next to the field clears the value when flipped off, which restores the default endpoint immediately. If you want fast switching, the practical move is to point at a small front proxy on localhost (one nginx config, one route flag) that forwards either to your MLX bridge or to api.anthropic.com depending on which you want. The bridge restart on save takes about 1.5 seconds.