EU VAT / ARCHITECTURE AS COST CONTROL

Anthropic VAT in the EU is a multiplier on tokens your Mac sends. Architecture moves the multiplicand.

Every other guide stops at the VAT table and tells you to register a VAT ID. That is necessary and true. It is also one side of the equation. On a Mac, the Anthropic invoice itself is shaped by whether your automation tool sends pixel payloads or accessibility text. Below are the four source-tree locations inside Fazm that keep the base bill (and therefore the VAT line) honest.

M
Matthew Diakonov
9 min read
4.9from Verified against the Fazm source tree
acp-bridge/src/index.ts
MAX_SCREENSHOT_DIM = 1920
MAX_IMAGE_TURNS = 20
--image-responses omit
mcp-server-macos-use
VAT 17% LuxembourgVAT 19% GermanyVAT 20% FranceVAT 20% UKVAT 21% NetherlandsVAT 22% ItalyVAT 23% PolandVAT 25% SwedenVAT 25% DenmarkVAT 27% HungaryReverse charge with valid VAT ID

THE FRAMING NOBODY ELSE WRITES

VAT is a percentage. Architecture decides the base.

Read the top guides on Anthropic VAT back to back and they all land in the same place: a table of country rates, an instruction to add a VAT ID, a note about reverse charge for businesses. That is accurate but incomplete. VAT in the EU works as a pure multiplier on the invoice. Whatever you pay Anthropic for tokens, voice, or seats, somewhere between 17 and 27 percent is added on top (for consumers, and for businesses that have not registered a VAT ID for reverse charge).

The interesting question is not the multiplier itself. It is the multiplicand. The bigger the Anthropic invoice, the bigger the VAT line. On a Mac automation workflow, the shape of that invoice is almost entirely about how much pixel data your tool serializes into Claude's context. Screenshot-heavy approaches ship megabytes per step. Accessibility-tree approaches ship structured text. At 15 dollars per million input tokens on Opus 4.6, and with image tiles priced as dense token blocks, that architectural choice matters more to your invoice than most people assume.

Fazm's ACP bridge is built around that fact. It has four visible guardrails that keep image tokens off the wire before Anthropic ever sees them, and it falls back on a native accessibility binary when the target is a Mac app. The rest of this page walks through the exact lines that do it, how they map to the VAT math, and what it means for an EU user.

How euros flow: from your Mac to Anthropic to the EU VAT line

Native Mac app
Browser tab
Window capture
ACP bridge
Text tokens
Resized images
VAT 17 to 27 %

THE ANCHOR FACT

Four locations in one file that shape the Anthropic invoice

Everything in this article is about four specific spots in acp-bridge/src/index.ts. Two are numeric constants. One is a command line flag for a spawned subprocess. One is a conditional server registration. Together they keep most of a Mac automation task's byte budget in text, which is the single largest lever on the Anthropic side of the EU VAT equation.

acp-bridge/src/index.ts

MAX_SCREENSHOT_DIM caps the per-image dimension so a Retina Mac does not produce a 2880 pixel PNG that Claude would then tile into an expensive token block. MAX_IMAGE_TURNS caps how many image-bearing turns a single session can accumulate. The Playwright subprocess is launched with `--image-responses omit`, which tells Playwright to save PNGs to disk and return a path rather than an inline base64 blob, so the screenshot is not automatically shoveled into the context window. The macos-use binary is registered as an MCP server only when its bundled path exists, which on a stock Fazm install is always.

WHAT THE WATCHER ACTUALLY DOES

The resize watcher, in its own words

The 1920 pixel ceiling is enforced by a filesystem watcher, not politely requested of Playwright. The bridge installs a fs.watch on /tmp/playwright-mcp and re-writes any oversize image in place using macOS's built-in sips utility. The result is that Claude never sees a 2880 pixel PNG that would trigger a dimension rejection or a larger token count, regardless of the user's display density.

startScreenshotResizeWatcher, tailing stderr during a browser run

BACK OF THE ENVELOPE

The VAT math on one hypothetical 100-step day

Take a deliberately simple scenario: a single user in Germany runs a 100-step automation, paying Opus 4.6 API rates of 15 dollars per million input tokens and 75 dollars per million output tokens, and 19 percent German VAT on the invoice. We hold the output side fixed and vary only the image input path. The numbers are order-of-magnitude only, meant to show the slope, not to be quoted as benchmarks.

0 pximage dim cap
0image turns per session
0%VAT (Germany example)
0guardrails, one file

On a naive screenshot-per-step loop at roughly 1800 image tokens per full 1920 pixel frame, a 100-step run ships about 180,000 image tokens, or 0 cents of Opus 4.6 input cost, plus an EU VAT line at 19 percent of that.

On an accessibility-first run where macos-use handles native app work and Playwright is used only when a page genuinely needs visual context, the same 100 steps commonly fit inside 20,000 text tokens, or about 0 cents of input cost, with the same 19 percent VAT riding on a much smaller base.

The ratio between those two modes is entirely a function of architecture, not of Anthropic pricing. Exact savings depend on your specific task shape, the structure of the target app, and whether you are a VAT-registered business reverse-charging your own invoices.

~10x

Accessibility-tree responses from mcp-server-macos-use are typically an order of magnitude smaller than a single Retina screenshot of the same window, even before Claude tiles the image for pricing.

Observed in bridge logs during local runs; verify in your own session at acp-bridge/src/index.ts:1054.

HOW THE TWO PATHS DIFFER

Screenshot path vs accessibility path, in the only places it matters to an invoice

FeatureScreenshot path (generic Mac automation)Accessibility path (mcp-server-macos-use)
Primary payload typeRasterized PNG or JPEG imageUTF-8 accessibility tree text
Typical size per step600 KB to 2 MB per frame2 KB to 40 KB of text
How Anthropic prices itImage tiles, priced as dense token blocksPlain input tokens, text rate
Dimension or count capOften uncapped, hits API errors1920 px cap + 20-turn ceiling in bridge
EU VAT exposureHigh base → high VAT lineLow base → low VAT line
Behavior after the capHard 400 errors, retry loopsGraceful: new session resets counter

TWO THINGS YOU CAN STILL DO YOURSELF

What the EU user should do about the VAT line this week

1

Register your VAT ID with Anthropic, today

This is the one move that does not depend on architecture. Sign into Claude, click your initials in the lower left, open Settings, go to Billing, click Update next to the payment method, enter your VAT ID. For API usage, the same field lives in the Claude Console organization billing page. A valid VAT ID moves you to reverse charge, and Anthropic stops collecting VAT on future invoices.

The VAT ID must be valid in VIES and must match your billing country's EU member state. UK VAT registrations are handled separately under UK rules.

2

Pick a Mac automation tool whose default path is text

For work that targets native Mac apps, pick a tool that prefers accessibility APIs over screenshots. Fazm's ACP bridge registers the macos-use MCP automatically when the binary exists, and caps Playwright screenshots to 1920 pixels with image responses stripped at the MCP boundary. The effect is that the same task produces a smaller Anthropic invoice, which in turn produces a smaller VAT line at whatever your local rate is.

Verify it yourself by opening acp-bridge/src/index.ts at lines 713, 793, 1033, and 1054. The file is MIT-licensed and reachable from fazm.ai/gh.

3

Keep sessions short when you are doing heavy visual work

The 20-turn image ceiling exists because large image histories compound per-image token cost and hit Anthropic's dimension limits. On a visual-heavy task, pop a fresh session when you cross the cap rather than letting the bridge silently drop new frames. This is worth doing in any Mac automation tool, not just Fazm.

FIVE SECOND MODEL

What a reader should remember after closing this tab

VAT is a multiplier, not a strategy

17 to 27 percent rides on whatever you pay Anthropic in the EU. The one move that touches the multiplier itself is registering a valid EU VAT ID for reverse charge. Everything else is about the multiplicand.

Your tool shapes the multiplicand

The biggest lever on the Anthropic-side base is how many image tokens your Mac automation tool sends. Screenshot-first tools ship megabytes per step. Accessibility-first tools ship kilobytes of text. The gap compounds at EU VAT rates.

Four lines in Fazm actually do this

MAX_SCREENSHOT_DIM = 1920 (line 713). MAX_IMAGE_TURNS = 20 (line 793). `--image-responses omit` on Playwright (line 1033). mcp-server-macos-use server registration (line 1054). All in acp-bridge/src/index.ts.

None of the ranking VAT guides mention this

Every other page on this topic is about the VAT table and the VAT ID registration flow. Both are necessary. Neither is sufficient if your tool sends two megabytes of pixels on every automation step.

You can verify all of this yourself

Fazm is MIT-licensed. Clone the repo from fazm.ai/gh, open acp-bridge/src/index.ts, and jump to the four line numbers cited above. The article is a reading guide, not a set of private claims.

Want a walkthrough of the actual bridge on your Mac?

Twenty minutes with the team, live screen share against your real workload and invoice pattern.

Book a call

Frequently asked questions

Does Anthropic actually charge VAT on Claude in the EU?

Yes. Both Claude Pro subscriptions and Anthropic API usage are classified as electronically supplied services for EU VAT purposes. Anthropic collects VAT at the customer's country rate, which ranges from 17 percent in Luxembourg to 27 percent in Hungary. A business customer with a valid EU VAT ID can register it in Anthropic's billing portal and move to reverse charge (0 percent collected by Anthropic, the business self-accounts for VAT in its own return). Consumers without a VAT ID pay the full local rate on every invoice.

Why does the article link VAT to Mac automation architecture?

Because VAT in the EU is a pure percentage multiplier. Whatever you pay Anthropic, 17 to 27 percent is added on top (for consumers and non-VAT-registered users). That means anything that reduces the base Anthropic bill reduces the VAT line by the same percentage. On a Mac automation task, the single biggest lever on the base bill is how much pixel data your tool sends to Claude. Screenshot-driven tools send multi-megapixel images, and Anthropic prices those as input tokens per tile. Accessibility-tree-driven tools send structured text, which is a fraction of the size. The architectural choice is a cost control that compounds with VAT.

Where in the Fazm source can I verify the image-cost controls?

Three constants and one server registration in acp-bridge/src/index.ts. MAX_SCREENSHOT_DIM is defined on line 713 at 1920 pixels. MAX_IMAGE_TURNS is defined on line 793 at 20 image-bearing turns per session. The Playwright MCP server is spawned on line 1033 with the argument `--image-responses omit`, which tells Playwright to save screenshots to files on disk and skip the inline base64 blob that would otherwise land in the Claude context window. The native accessibility binary mcp-server-macos-use is registered as an MCP server on line 1054, with no image tokens in its responses at all. Those four locations are the engineering that keeps image token cost off the Anthropic invoice.

How much can token efficiency actually move the EU bill?

At Opus 4.6 API pricing of 15 dollars per million input tokens, one uploaded 1920x1200 PNG screenshot consumes roughly 1500 to 2000 image tokens, depending on tile layout. An accessibility tree snapshot of the same window is typically 500 to 2000 text tokens, at the same per-million price. On a 100-step automation, a screenshot-every-step approach can send 150,000 to 200,000 image tokens to Anthropic, while an accessibility-first approach often sends under 20,000 text tokens. The delta at EU VAT rates is the base delta multiplied by 1.17 to 1.27. The exact ratio depends on your task, the direction of the comparison we're making here is what every page on this topic skips.

Can I self-serve a VAT ID registration with Anthropic?

Yes. Sign into Claude, click your initials in the lower left, open Settings, go to Billing, click Update next to the payment method and enter your VAT ID. For the API, the same registration happens in the Claude Console organization settings under Billing. Once validated, Anthropic switches you from VAT collected to reverse charge, and subsequent invoices show 0 percent VAT collected. The requirement is that the VAT ID is valid in VIES and that the billing country matches the member state of registration.

Does Fazm use the Anthropic API directly?

No, Fazm ships a Node.js subprocess called the ACP bridge that speaks the Agent Client Protocol to the Claude Code SDK. The Swift desktop app communicates with the bridge over stdio. The bridge is what launches MCP servers (Playwright, mcp-server-macos-use, WhatsApp, Google Workspace, plus any user entries in ~/.fazm/mcp-servers.json) and what decides what ends up in a Claude session's context. The image-cost guards in the bridge therefore determine the image component of every Anthropic invoice a Fazm user generates. This matters for EU users because VAT rides on that invoice.

What happens after the 20 image-turn cap?

MAX_IMAGE_TURNS = 20 on line 793 is a ceiling that exists because Anthropic enforces a stricter per-image dimension limit once a session has accumulated many images. Past that threshold, the bridge does not add new screenshots into the ongoing session context, which keeps the session viable and also prevents a runaway image bill. If the model still needs visual context after the cap, the operator can start a fresh session, which resets the counter and lets Claude receive fresh images within the same dimension limits.

What does the 1920 pixel ceiling actually do in practice?

Playwright on a Retina Mac happily produces screenshots north of 2560 pixels on the long edge. Claude rejects images above about 2000 pixels with an API error. The ACP bridge watches /tmp/playwright-mcp/ for new PNG or JPEG files, reads their dimensions with macOS's built-in sips, and calls `sips --resampleHeightWidthMax 1920` on anything too large. The code is in startScreenshotResizeWatcher at lines 715 through 757. It avoids hard failures on the wire, and it also caps the per-image token cost at whatever the 1920 tile math works out to, which is noticeably cheaper than a 2560 pixel equivalent.

Is mcp-server-macos-use actually free of image tokens?

Yes. The mcp-server-macos-use binary is a native Swift MCP server that reads the macOS accessibility tree via AXUIElement. Every tool it exposes (click, type, scroll, read, traverse) returns text responses that describe roles, labels, positions, and values of on-screen elements. Claude's context window sees UTF-8 text, not pixels. The bridge registers this binary on line 1054 of acp-bridge/src/index.ts only if the bundled binary path exists, so on an unmodified Fazm install it is always active for any automation task that targets a native Mac app.

Does the EU AI Act change any of this for Claude users?

Not directly on VAT. The EU AI Act primarily governs what general purpose AI providers have to document about their training data, systemic risk, and transparency toward downstream providers. It does not change how VAT is collected on digital services, which is already governed by the VAT Directive and local implementation. In practice, EU AI Act compliance has delayed certain Claude features (voice, memory) for EU users in the past, but the billing and VAT flow is unchanged: pay Anthropic, VAT added on top unless you reverse charge.

Can a single user swap Playwright for mcp-server-macos-use to cut image cost?

On native Mac apps, yes, and it mostly happens automatically when Fazm picks the macos-use MCP for a given task. On browser-only tasks, no, because the accessibility tree of a web page does not give Claude a reliable enough model of the DOM for most actions, and Playwright's screenshot plus snapshot pair is the honest default. The architecture is intentionally hybrid: native app work goes through accessibility, browser work goes through Playwright with image responses stripped at the MCP boundary so the saved PNGs live on disk at /tmp/playwright-mcp and Claude is told to read them by path when visual context is actually needed.

Where can I see the code that this page cites?

Fazm is MIT-licensed and the repo is linked from fazm.ai/gh. The paths referenced in this article are all under acp-bridge/src/index.ts (the Node.js bridge). Line numbers match HEAD at the time of writing: MAX_SCREENSHOT_DIM on 713, MAX_IMAGE_TURNS on 793, Playwright `--image-responses omit` on 1033, and the mcp-server-macos-use registration on 1054. A separate Swift-side screenshot path exists at Desktop/Sources/FloatingControlBar/ScreenCaptureManager.swift, used as a fallback when the bridge explicitly asks for a window capture rather than running through Playwright or the accessibility tree.