Local AI agent vendor revocation risk is layer-by-layer, not all-or-nothing

What “vendor revocation” actually means

The phrase covers more ground than a one-time account suspension. On a normal year a working AI workflow can be broken by any of these without warning:

• An automated trust-and-safety review concludes your usage looks like abuse and your account is suspended pending appeal. Anthropic did this to the OpenClaw team in 2025; the pattern repeats across providers every quarter.
• A model your workflow depends on is deprecated on 60 days notice, the API starts returning model not found, and your agent code path breaks until you migrate.
• Rate limits tighten silently during peak hours, your agent loops on retries, and the user experience degrades into a slow hang.
• A region, capability tier, or pricing change cuts off a feature your workflow assumed (long context, vision, tool-use schema).

None of this requires a vendor to be malicious. It just requires you to have built on a single endpoint with no swap path. Calling your agent “local” does not change any of the four scenarios above; it changes which parts of the stack still function while you fix the model dependency.

Layer by layer: what dies, what lives

A desktop agent has at least four layers. Treat each as a separate risk question. Two of them are unaffected by any cloud event. One of them is the entire reason single-vendor agents fail. The fourth is your escape hatch.

The escape hatch is one text field

The reason this is worth writing about is that the mitigation is not a roadmap item or a developer-only knob. It is a single text field in the Settings UI, wired to one environment variable on the agent subprocess. When you change the URL, the bridge restarts automatically and the next message goes to the new endpoint.

The wiring is small enough to read in one sitting. Setting lives at Desktop/Sources/MainWindow/Pages/SettingsPage.swift:885 as @AppStorage("customApiEndpoint"). The injection happens in Desktop/Sources/Chat/ACPBridge.swift:468-470:

// Custom API endpoint (proxies through Copilot,
// corporate gateways, local model servers, etc.)
if let customEndpoint = defaults.string(forKey: "customApiEndpoint"),
   !customEndpoint.isEmpty {
  env["ANTHROPIC_BASE_URL"] = customEndpoint
}

Anything that speaks the Anthropic message protocol works on the other end: a corporate proxy that re-keys the request, a self-hosted gateway, a local model server with an Anthropic shim, or a third-party provider that implemented the same surface. The agent on your Mac never has to know the difference.

Three destinations, one variable. If the first one stops accepting your traffic, you flip the variable. The clicks, typing, file ops, and AX-tree reads on the left side of that diagram never change shape regardless of which destination is live.

Screenshot agents vs. accessibility-tree agents under revocation

This part is not obvious until you trace what each architecture actually does on every step. Use the toggle below to see the same workflow under two designs.

What this looks like during an actual revocation

Imagine your Anthropic key is suspended at 2pm on a Tuesday. Here is the actual sequence with Fazm running on your Mac, in the order you would experience it:

1. 2:00pm. You ask the agent to refile a row in your CRM. The agent is already moving (open the tab, focus the field, read the current value) before any model call. The first three accessibility actions succeed.
2. 2:00pm + 2s. The agent needs to decide which row matches your description and calls the model. The call returns a 401 or authentication_error.
3. 2:00pm + 3s. The bridge surfaces the error in the chat. Anything that did not need that model call (your in-progress files, the open browser tabs, the agent UI itself) is unaffected.
4. 2:01pm. You open Settings > Advanced > AI Chat. You toggle Custom API Endpoint on and paste your fallback URL. The bridge restarts automatically.
5. 2:01pm + 4s. You re-send the message. It goes to the new endpoint. The agent picks up the AX-tree state of the CRM tab where it left off and completes the row.

The total recovery is one toggle, one URL paste, one re-send. None of the work-in-flight on your Mac is lost because the execution layer never touched the vendor.

What you should actually do about this

If you are evaluating a desktop AI agent under any kind of vendor-risk lens, three concrete checks separate honest architecture from marketing:

1. Where does the click come from? Read the source. If the answer is “send pixels to a vision model and wait for coordinates,” the architecture is vendor-coupled at the action level. If the answer is “query the accessibility tree,” the action layer is yours.
2. Can the model endpoint be changed without a rebuild? A user-facing setting that injects a base URL counts. A hard-coded SDK call does not.
3. Is the source readable? You cannot audit either of the above on a closed agent. Open source is the only way to verify the swap path is real and not a marketing slide.

Fazm passes all three by construction: AX engine, customApiEndpoint setting, MIT-licensed source on github.com/m13v/fazm. That does not eliminate vendor revocation risk; it moves the recovery from days to seconds and limits the blast radius to one kind of step in the workflow.