Where to spend an API credit that expires every month

The last post was about cloud-session credit. This one is about a different pool. Claude Max, Ultra and Team plans now include a monthly credit for the Claude API: $100 on Max, $200 on Ultra, up to $500 pooled across seats on Team. You claim it once, by linking a Console organization to your plan. After that it lands in that organization every billing cycle, or monthly on annual plans. It does not roll over: whatever is left when the cycle ends is gone. Anthropic covers the details in the Platform docs and in a Help Center article. The second one is where the fine print about Claude Code lives.

CHOD had the Console open, a balance just under $200, and a fair question: "I really don't know how to use this up." The answer came from crossing things out.

What we crossed out

**Our own products.** Where our products call a model, they do it on a paid API billed to a company card, and they stay that way. This credit belongs to one person's subscription, renews on that person's billing date, and stops cold when it runs out. That makes it the wrong thing to put under something people rely on. The books stop adding up, because the cost lands on whichever subscription happened to pay, on a different date for each. Running out is an outage: when the balance is gone, requests stop. And the rules of a perk can change. Anything a customer touches gets a bill we can predict.

**Anything customer-facing**, for the same reason, including a bot people talk to. A bot inside our own team's Discord is fine; a bot we offer to other people is a product.

**Interactive Claude Code.** The Help Center lists interactive Claude Code — terminal, IDE, desktop, web — as not covered. It runs on the plan anyway.

**A GitHub Action that reviews every pull request.** This was the tempting one. The Help Center lists "runs started by the Claude Code GitHub Action" among the runs the credit does not cover. A home-made workflow that calls Claude with our own key may well be covered, but it sits right next to that line. It would also put an API key inside CI, within reach of pull-request code unless the workflow is set up with care. And we don't pay for hosted CI on private repos.

What was left

The same Help Center article names the shape that is covered: "API credits cover `claude -p` and the Claude Agent SDK when you run them yourself with an API key."

That is how most of our compute already runs. Our command-line tool, clikae, starts headless Claude Code runs on our accounts; its `burn` command is one `claude -p` run. A burn passes its whole environment to Claude Code, and Claude Code bills an API key instead of the plan's login when `ANTHROPIC_API_KEY` is set. We confirmed that from the Console balance. So the bridge from our usual runs to "spend the credit" is one variable in front of a command we already type every day.

That left the second question: what work should go there. The credit is gone at the end of the cycle and stops when it is empty. So it should buy work that is worth doing and harmless to stop. If it runs out mid-month we review one pull request fewer, and no customer notices.

What it bought

A read-only review of a pull request we had already merged, by a separate run that had never seen it: **$1.10**, measured from the Console balance before and after. It found two real problems. One was an attribute whose documented default, written out explicitly, made a countdown visibly run backwards half the time. The other was a test the pull request claimed would catch a mutation (a deliberate break of the code it protects); it stayed green when the reviewer made that break.

The fix, with a test for each finding that goes red when its fix is undone: **$2.08**.

Since then we send each pull request to a separate reviewer before it merges. One of them found a blocker in a larger change, a shared corner dock for our embeddable widgets. In installed-app mode, an empty bottom bar put a MutationObserver into an infinite loop and froze the page. Our widget versions are immutable once published, and on any page the first copy to load owns that bar. Shipped, the bug could not have been fixed by a later version on pages where the old copy loaded first. Found before release, it was a one-line fix.

How cold were the reviewers, really

A "cold reader" is a reviewer that comes to the work without the author's context. Our reviewers were separate runs that had never seen the pull request. We assumed they still carried our shared long-term memory, because the burn's own log said it had linked it. So we went to check.

They didn't carry it, and not on purpose. Each run was started from a temporary directory under `/var/folders`. On a Mac `/var` is a symlink to `/private/var` — the same trap as last time. clikae linked our memory at the path it was given; Claude Code resolved the real path and kept its session, and an empty memory folder, there. Every reviewer's transcript sits next to that empty folder. So the reviewers had no memory, but they still had our skills and our connected tools, which don't depend on the directory. That makes them half cold, and only by accident. The path bug is filed.

The deliberate version is a clikae switch: `--ephemeral`. It swaps long-term memory for a throwaway directory, drops our own skills and our connected tools, and writes no transcript in headless mode. It has a history, though. To swap the memory it moves the real one aside for the length of the run. Once, that move landed under a session someone was actively working in on the same account, and that session could no longer save anything new. So the rule we run by now is to do cold reads on an account nobody is working in. The swap has nothing to land on, and the reader is clean.

The first thing we cold-read that way was this post. The reviewer knew nothing about us. It fetched the page we were citing and reported that the page did not say what we said it did. The Platform docs only list Claude Code as not covered. The `claude -p` exception, the sentence this whole post rests on, is in the Help Center article, which we had not linked. A reviewer that shared our assumptions would have trusted the citation. The stranger checked it. That is why the citations above point where they do.

Notes from setting it up

• **Key scope: pick Workspace, not Organization.** The Console's create-key dialog explains why: an Organization-scoped key can call the Admin API, and every other request must carry an `anthropic-workspace-id` header. Claude Code doesn't send that header, so the key fails on the first call.
• **The link is one-way.** Each plan links to one Console organization, and you can't change it yourself. Pick the organization you will actually build in.
• **Two calendars.** The credit follows your billing cycle; the Console's spend cap resets on the first of the month. The credit's expiry date is shown under *Promotional credits* on the Billing page.
• **A key per account, named for it.** We name keys `clikae-burn-<account>` and store them under that name. A burn picks its account by name, and the key value never has to be typed or pasted into a conversation.

The shape

A credit that expires is a budget with a deadline. We spent it by elimination: not on the product, not on anything customer-facing, not on a GitHub Action. What was left was headless runs we start ourselves, buying more eyes rather than more hands. The eyes are worth most when they are a stranger's.