Claude Cowork Mac alternative
The Claude Cowork Mac local alternative that operates the apps you are already logged into
Claude Cowork on Mac is a useful product. The detail every marketing page glosses: the work executes inside an isolated Linux VM running on Apple Virtualization framework, the model that drives it lives in Anthropic's cloud, and an active internet connection is required for the whole session. Your real Safari tabs, your real Mail account, your real Slack are on the other side of the VM boundary. Fazm is the macOS-native alternative that runs the agent loop as local subprocesses on your Mac and drives your real apps through the Accessibility API, with the Swift line that does it visible on GitHub.
Direct answer (verified 2026-05-08)
The closest local alternative to Claude Cowork on Mac is Fazm: an open-source macOS-native AI agent that drives your real macOS apps through the Accessibility API instead of running commands inside an isolated Linux VM. Source at github.com/m13v/fazm, $9.99/mo hosted or free from source, no Pro plan required. Cowork's VM model and always-on internet requirement are documented in Anthropic's help center.
What Cowork actually is, in one paragraph
Per Anthropic's own help center: Cowork is a mode inside Claude Desktop, available on Pro, Max, Team, and Enterprise plans. It executes shell commands and code inside an isolated virtual machine on your computer with controlled file and network access. On Apple Silicon Macs that VM is provisioned via Apple's Virtualization framework. The model itself and the orchestration loop run in Anthropic's cloud, and an active internet connection is required throughout every session. Files you do not explicitly share stay on your Mac; the work the agent does happens inside the VM.
Where the agent actually lives, in one diagram
The Cowork architecture has three sides: your prompt on your Mac, Anthropic's cloud holding the model and the orchestrator, and a local Linux VM on your Mac holding the tools. The reason your real apps are out of reach is that they live on a fourth side, the macOS host, which the VM deliberately does not see.
Claude Cowork on Mac, by component
Your prompt traverses the network to reach the orchestrator. The orchestrator decides actions, then issues those actions back into a Linux VM that lives on your Mac but is isolated from it. Your real macOS apps, on the left, never become destinations on the right.
Fazm vs Claude Cowork at a glance
Two ways to get an AI agent to do work on your Mac. The differences are in where the loop runs, what it can reach, and what it costs.
| Feature | Claude Cowork | Fazm |
|---|---|---|
| Where the work executes | Inside an isolated Linux VM running on Apple Virtualization framework. The VM is on your Mac, but it is a separate Linux system that does not see your real desktop apps. | Directly on the macOS instance you are already logged into. No VM, no second filesystem, no second browser profile to copy cookies into. |
| Internet requirement | An active internet connection is required throughout every Cowork session, per Anthropic's own help center. The model and the orchestration are in Anthropic's cloud. | Inference is the only thing that crosses the network, and the endpoint is pluggable. Default is Anthropic; you can route to a corporate Anthropic-compatible proxy, GitHub Copilot, or a local model behind a bridge. |
| How it controls apps | Computer-use mode points and clicks via screenshots inside the VM. The VM has its own clean Linux desktop. Your real Mac apps and your real logged-in browser sessions live outside that VM. | Real macOS Accessibility APIs against the user's frontmost native process. The probe at AppState.swift line 488 calls AXUIElementCreateApplication(frontApp.processIdentifier) and reads kAXFocusedWindowAttribute on the actual window you are looking at. |
| Source code | Closed. The Cowork desktop app and the VM image are vendor-shipped binaries. | MIT licensed at github.com/m13v/fazm. Read the AX probe, the agent bridge, the MCP wiring, and the WhisperKit voice path in the open. |
| Subscription gate | Pro, Max, Team, or Enterprise plan required, per Anthropic's help center. Pro is $20/mo; Max starts at $100/mo. The Mac binary is gated behind a paid Claude account. | $9.99/mo for the hosted build, no free trial, cancel anytime. Or build from source for free if you would rather not pay. |
| Hardware requirement | Apple Silicon required on Mac. The VM runs on Apple Virtualization framework, which only ships on M1, M2, M3, and M4 chips. Intel Macs are out. | Apple Silicon recommended for WhisperKit Neural Engine inference, but the agent loop and accessibility probe run on any Mac running macOS 14 Sonoma or later. |
| Voice input | Text-first chat. There is no built-in push-to-talk voice loop documented in the Cowork product page or help center. | Voice-first. Hold the function key, talk, release. WhisperKit transcribes on-device on the Apple Neural Engine; the audio never leaves the laptop. |
| Browser automation | The Cowork VM ships with a Linux browser that has no shared cookie jar with your real Safari or Chrome. To work in your logged-in accounts, the agent has to log in again, inside the VM, every session. | Drives your real, logged-in Chrome through the Playwright MCP attached to your existing user profile. Sessions, cookies, and 2FA state are the ones you already have. |
| App coverage | Linux apps installed inside the Cowork VM, plus whatever Anthropic exposes through MCP servers configured in the desktop app. | Any macOS app exposed via the Accessibility API (Mail, Notes, Calendar, Slack, Reminders, third-party apps that implement AX) plus everything in your real browser via Playwright MCP. |
The thing every Cowork review skips: which API drives the apps
Cowork's Mac story is dominated by the VM. What controls things inside the VM is straightforward: a Linux desktop, a browser binary, a shell. What controls things outside the VM is barely talked about, because the answer is “not much”. To click into your real Mail or your real Slack you would need an API that runs on the host macOS, and the VM is by design walled off from that.
Fazm is the inverse. The exact function that probes Accessibility runs every poll cycle, lives at line 488 of Desktop/Sources/AppState.swift in the open source repo, and looks like this:
// Desktop/Sources/AppState.swift, around line 488
let appElement = AXUIElementCreateApplication(frontApp.processIdentifier)
var focusedWindow: CFTypeRef?
let result = AXUIElementCopyAttributeValue(
appElement,
kAXFocusedWindowAttribute as CFString,
&focusedWindow
)That is the macOS Accessibility API operating on the actual frontmost process on your machine, identified by its real PID. There is no remote variant of these calls in the public Apple SDK. Any agent that wants to read or click into a real Mac app has to run on the same macOS instance as the windowserver, which is why a Linux VM on top of macOS, no matter how local it is, cannot reach your real apps. The Cowork VM runs on your machine but it is not your machine.
“An active internet connection is required throughout the session. Cowork runs in an isolated virtual machine (VM) on your computer with controlled file and network access.”
support.claude.com, Get started with Claude Cowork (article 13345190)
How Cowork's loop runs, step by step
You type a prompt in Claude Desktop
Cowork lives inside the regular Claude Desktop app. The trigger is on your Mac.
The prompt goes to Anthropic over the network
Anthropic's help center is explicit: an active internet connection is required throughout the session. The model and the orchestration loop live in their cloud.
Claude generates plan and tool calls in the cloud
Computer-use, file edits, and shell commands are decided by a model running on Anthropic's infrastructure, not on your Mac.
Tool calls execute inside the local Linux VM
Apple Virtualization framework spins up a fresh Linux VM on your Apple Silicon Mac. That VM is where every shell command, file write, and screenshot click happens.
Your real apps are on the other side of the VM boundary
Your Safari tabs, your Mail account, your Slack, your local files outside the working directory you shared, your Calendar. None of those are inside the VM. The agent does not see them.
How Fazm's loop runs, step by step
You hold the function key and talk
WhisperKit transcribes the audio on the Apple Neural Engine. The audio bytes never leave the Mac.
The Swift app routes the transcript to a local Node bridge
acp-bridge is a Node subprocess on your Mac. It hosts the agent loop and the Anthropic SDK. The bridge is in the open source repo at github.com/m13v/fazm.
MCP tools spawn as further local subprocesses
macos-use, playwright, whatsapp, and the in-house fazm tools each run as their own process on your Mac. Tool calls block synchronously on those local processes.
Inference is the only thing that crosses the network
The model endpoint is pluggable. Anthropic by default; or a corporate Anthropic-compatible proxy, GitHub Copilot, or a local Anthropic-shaped server.
Tool calls touch your real apps directly
AXUIElementCreateApplication takes your real frontmost PID. Playwright drives your real Chrome with your real cookies. There is no VM in between.
“There are things I literally couldn't get myself to do (hello, procrastination), and now I just get them done through Fazm. Vacation paperwork, ordering prescriptions from a screenshot, IKEA furniture with discounts applied, all perfect. I even built custom skills for Apple Reminders, my Synology NAS, and Plex. They just work.”
When Cowork is the right pick
To be fair to Cowork: a clean Linux VM with controlled file and network access is the safer environment for letting an agent run shell commands you have not personally read. If your workflow is “spin up a contained codebase, let the agent edit it, run tests, throw the VM away”, that is exactly the shape Cowork was built for, and the isolation becomes a feature instead of a wall. If you already pay for Claude Pro for the chat product, the agent is bundled. Anthropic's coverage is also broader than any single third-party app: any tool the model can write code for is a tool the agent can run.
The shape that makes Fazm the better pick is when the agent has to live inside the apps you already use, when you do not want a perpetual internet round-trip in front of every action, when you want to read the code that touches your microphone and your accessibility tree, or when you do not want to pay $20/mo for a chat tier you would not otherwise buy. The difference is which side of the VM boundary the agent sits on, and which side of the network the model sits on. Pick based on the workflow, not the marketing.
Want to see Fazm run the workflow you wanted Cowork for?
Twenty minutes, screen share, your real Mac apps. We will take a workflow you wanted Cowork to do and run it through Fazm, with the agent loop on your machine and the apps you are already logged into.
Frequently asked questions
What is Claude Cowork on Mac, in plain terms?
Cowork is a mode inside Claude Desktop where Anthropic's model can take on multi-step tasks: write code, edit files, browse the web, and run shell commands. On Mac, the heavy lifting happens inside a local Linux virtual machine spun up via Apple's Virtualization framework. The VM is sandboxed away from the rest of your Mac, which is why the file system and apps you see in Cowork are not your real ones unless you explicitly share a directory.
What does 'local alternative to Claude Cowork on Mac' actually mean?
Two different things, depending on who is asking. Some users want a local alternative because they do not want an active internet connection required for the agent to function; Cowork's help center confirms that connection is mandatory. Other users want a local alternative because they want the agent to operate the apps they are already logged into on their Mac, instead of a clean-room Linux VM that has no shared session state. Fazm answers both: the agent loop runs as local subprocesses on your Mac, and the tool calls drive your real macOS apps through the Accessibility API.
Does Cowork actually run locally?
The execution VM runs locally on your Mac. The model that decides what to do does not. Anthropic's help center is explicit that an active internet connection is required throughout every Cowork session, and the model and orchestration live on Anthropic infrastructure. So yes the Linux VM is on your machine; no the agent loop is not.
Why is the VM such a big deal for the user experience?
The VM is a separate operating system. Its filesystem is not your Mac's filesystem. Its browser does not share cookies, sessions, or 2FA state with the Safari or Chrome you have been logged into for years. If you want Cowork to use your real Gmail, you have to either share a working directory and hope, or sign in fresh inside the Linux VM browser every time the VM is rebuilt. For workflows that revolve around apps you are already logged into, that is friction. Fazm operates on the Mac you are already logged into, so there is no second login.
How does Fazm actually click into Mac apps without a VM?
Through the macOS Accessibility framework. AXUIElementCreateApplication takes the local PID of the frontmost app, AXUIElementCopyAttributeValue reads named attributes like kAXFocusedWindowAttribute, and the macos-use MCP traverses the resulting element tree. Those are the same APIs Apple ships for assistive technologies. They only work from a process running on the same macOS instance as the windowserver, which is why the Fazm agent has to live on your Mac, and why a remote agent on a server cannot do this no matter how good its model is.
Is Fazm cheaper than Claude Pro for the agent feature?
Yes if the agent is what you came for. Cowork is gated behind Pro at $20/mo or higher tiers. Fazm hosted is $9.99/mo with no free trial; building from source is free. If you already pay for Claude Pro for the chat product, you are paying once and the agent is bundled. If you signed up for Pro mostly for Cowork, the math changes.
Can I run Fazm on an Intel Mac?
Yes, the agent loop and the accessibility probe run on any Mac with macOS 14 Sonoma or later. Some on-device features like WhisperKit voice transcription benefit from Apple Silicon Neural Engine. Cowork on Mac requires Apple Silicon because Apple's Virtualization framework with the configurations Cowork uses is Apple Silicon only.
What does Fazm not do that Cowork does?
Cowork ships with a clean Linux VM and a working directory abstraction that is genuinely better for sandboxed code execution where you do not want the agent to touch the rest of your filesystem. If your workflow is 'spin up a project, let the agent edit a contained codebase, never touch my real apps', that is what Cowork is built for. Fazm is the opposite shape: the agent operates inside the apps you already use, with the permissions you have granted. The two are not interchangeable for every workflow.
Is Fazm open source for real, or only the wrapper?
For real. The Swift app, the acp-bridge agent loop, the macos-use MCP, the WhisperKit integration, the AX probe at AppState.swift line 488: all in the open source repo at github.com/m13v/fazm under MIT. The hosted build is a convenience; the underlying agent is auditable end to end.
Where do I verify the claims in this article?
Cowork's help center articles on support.claude.com cover the plan tiers, the always-on internet requirement, and the VM execution model (article 13345190 'Get started with Claude Cowork'). Anthropic's product page at claude.com/product/cowork describes the feature. Fazm source: github.com/m13v/fazm, with AppState.swift around line 488 covering the Accessibility probe used in this comparison.
On-device Mac AI agents and the tradeoffs
Keep reading
Claude Computer Use alternative: Fazm
Anthropic's Computer Use API plus Docker is impressive engineering. Fazm is the consumer-grade product wrapped around the same idea, with accessibility APIs instead of screenshots.
Accessibility tree vs screenshots for AI agents
Why named AX fields beat pixel coordinates for any agent that has to click around real apps, with the token math that backs it up.
Local LLM vs local AI agent on macOS
Running a model locally is not the same as running an agent locally. The agent loop is a separate piece of software, and where it lives matters more than where the weights live.