How to Make Your $20 Claude Extra Usage Credit Last on Third-Party Apps

1. What the extra usage credit is and how to claim it

In early April 2026, Anthropic deposited free extra usage credits into the accounts of existing Claude subscribers. The amount depends on your plan:

To claim it, you need to have subscribed before April 3, 2026 at 9 AM PT, enable extra usage in your account settings, and click the claim button on the Usage page banner. The credit expires 90 days after claiming and unused balances do not carry over.

The credit works across Claude.ai, Claude Code (the terminal CLI), Claude Desktop, and third-party apps that connect to your Claude account. But how it gets consumed depends on where you use it.

2. The third-party app billing trap

Here is the part most coverage of this promotion glosses over. Claude.ai, the mobile app, and Claude Desktop all draw from your base plan allowance first. Extra usage only kicks in after your plan limits are exhausted. So for direct Claude usage, the $20 credit is a safety net.

This changes the calculus. If you spend most of your time on Claude.ai, the $20 sits untouched until you hit your plan limit. But if you connect a third-party tool like Cursor, Windsurf, Cline, or a desktop automation agent, every action that tool takes draws from your extra usage balance from the first request.

The rate at which a tool drains that balance depends entirely on how many tokens it sends per action. And that is where the architecture of the tool matters enormously.

3. Why screenshots eat your credits: the token math

Screenshot-based AI agents (like Claude Computer Use, or any tool that captures your screen and sends it to a vision model) work by taking a screenshot, encoding it, and sending it as image tokens in the API request. Image tokens are significantly more expensive than text tokens.

A typical 1920x1080 screenshot uses roughly 1,600 to 2,000 image tokens per request. A 10-step workflow where the agent takes a screenshot before each action sends 16,000 to 20,000 image tokens just for perception, before counting the text tokens for reasoning and tool calls.

Compare that to sending a structured text description of the same UI. The macOS accessibility tree for a typical application window might be 200 to 500 text tokens. The same 10-step workflow would use 2,000 to 5,000 text tokens for perception instead of 16,000 to 20,000 image tokens.

The practical result: a screenshot-based agent can drain a $20 credit in a fraction of the actions that a text-based agent would take. If you are paying attention to how long your extra usage lasts, the tool architecture matters more than how many tasks you run.

4. How accessibility-API tools cut token spend

Fazm is a macOS desktop automation agent that uses the operating system's accessibility framework instead of screenshots as its primary perception method. When Fazm needs to interact with an application, it queries the macOS accessibility tree and gets back structured text like this:

[Group] "AI prompt"
  [Button] "Voice input" x:612 y:480 w:32 h:32
  [TextField] "Ask AI anything..." x:280 y:476 w:320 h:40
  [Button] "Submit" x:648 y:480 w:32 h:32

This structured representation gives Claude everything it needs to decide which element to interact with: the role (Button, TextField), the label ("Voice input", "Submit"), and the exact coordinates. No vision model call required. The text weighs a few hundred tokens instead of thousands of image tokens.

Fazm does still use screenshots in specific situations where visual context helps (reading a chart, verifying a layout). But the source code actively limits this. In acp-bridge/src/index.ts, there is a constant called MAX_IMAGE_TURNS set to 20. After 20 image turns in a single session, screenshots are silently dropped to prevent runaway vision token costs and avoid Claude's stricter 2000px dimension limits on sessions with many images.

This is a deliberate design choice: accessibility data first, screenshots as a capped fallback. The result is that a typical Fazm automation session sends mostly text tokens to Claude, keeping per-action costs low and making your extra usage credit stretch further.

5. How Fazm tracks your per-action cost

Most third-party tools that connect to Claude do not show you what each action costs. You find out when you check your usage page after the fact. Fazm takes a different approach.

In the file acp-bridge/src/patched-acp-entry.mjs, Fazm patches the Claude SDK's response stream to intercept the total_cost_usd field from every successful API response. It computes a per-turn cost delta by subtracting the previous session cost from the current cumulative total. This avoids double-counting across multi-turn conversations.

// From patched-acp-entry.mjs
const prevSessionCost = session._sessionCostUsd ?? 0;
session._lastCostUsd = item.value.total_cost_usd - prevSessionCost;
session._sessionCostUsd = item.value.total_cost_usd;

Fazm also tracks whether each action used the built-in API key or your personal Claude account, storing usage data separately for each mode. This means you can see exactly how much of your extra usage credit each automation session consumed.

When Fazm detects that credits are exhausted (either the built-in key or your personal account), it surfaces a clear error message instead of failing silently. For built-in credits, it suggests switching to your personal Claude account. For personal account limits, it points you to Claude Pro for higher limits. No guessing about why an automation stopped.