claude-code·9 min read·
The 15 June 2026 Claude credit split: what UK indie hackers should do this month
Anthropic announced on 13 May 2026 that from 15 June, programmatic Claude usage moves to a separate monthly credit pool, capped at subscription price. Here is what the numbers actually mean for a UK indie hacker, and the four things to do in the four weeks of runway.
On 13 May 2026, Anthropic's developer account posted the change every UK indie hacker building on Claude needed to know about. From 15 June 2026, Claude Code usage splits into two distinct credit pools. Interactive use - you sat in front of a terminal, typing - stays under your Pro or Max subscription. Programmatic use - Agent SDK calls, claude -p headless runs, anything orchestrated from code - moves into a separate monthly pool, billed at API rates, capped at your subscription price.
The internet did what the internet does and lost its head for half a day. Most of the panic was wrong. The change is broadly good news for UK indie hackers. It is more transparent, more predictable, and removes a specific failure mode that was biting heavy SDK users (sudden throttling once a shared quota tipped over). But "broadly good news" still means there are four concrete things every UK indie hacker should do in the four weeks of runway between now and 15 June. This post is that list, with the numbers and the why.
What is actually changing
The shape, in plain English. Today, when you use Claude Code on a Pro plan at GBP 20/mo, both your interactive claude sessions and your headless claude -p cron jobs draw from the same Pro plan envelope. There is a soft fair-use ceiling, but in practice most UK indie hackers do not hit it.
From 15 June 2026:
- Pool A: interactive. Your
claudeterminal sessions, sat in front of a project, stay under your subscription. Unmetered for normal use, same as today. - Pool B: programmatic. Every Agent SDK call, every
claude -pfrom a script, every hook that fires a Claude run, every cron job, every webhook-triggered agent - draws from a separate monthly credit pool. Billed at API rates per token. Capped at your subscription price.
The cap is the load-bearing word. A UK indie hacker on the Pro plan at GBP 20/mo gets a separate GBP 20 of programmatic spend each month. Beyond that, the SDK pool either fails closed (default - your agent gets a clear "monthly pool exhausted" error) or rolls over to pay-per-token (only if you explicitly enable it on the key).
The numbers, summarised:
| Plan | Monthly price (GBP) | Interactive pool | Programmatic pool | Behaviour over cap |
|---|---|---|---|---|
| Pro | ~20 | Unmetered (fair use) | ~20 of API-rate spend | Fail closed by default |
| Max | ~100 | Unmetered (fair use) | ~100 of API-rate spend | Fail closed by default |
| Max+ | ~200 | Unmetered (fair use) | ~200 of API-rate spend | Fail closed by default |
The exact pence figures may shift slightly between now and the launch - Anthropic has signalled they will publish the final numbers seven days before 15 June. The structure is locked.
A worked example. Pro plan today, CLI interactively four hours a day, two claude -p crons (a 7am brief and a nightly QA agent). Bill: GBP 20/mo. Tomorrow, same usage, same bill: GBP 20/mo. The two crons are now itemised in Pool B and visibly cost, say, GBP 7 of the GBP 20 cap. You see the spend rather than guessing.
A heavier example. Max plan at GBP 100/mo, six production agents on Railway, SDK spend at full API rates would be GBP 230. Today you might be flirting with throttling. Tomorrow your bill is capped at GBP 100 - the GBP 130 difference is absorbed. You either let agents fail closed when the cap hits, or enable overflow on critical keys and pay for the overflow at API rate.
For broader context on the Agent SDK side of this, the Claude Agent SDK quickstart is the prerequisite. For the headless half, the claude -p scripting guide covers the script types you are about to audit.
Why this is good news, honestly
Three reasons the change is a net positive for UK indie hackers.
Transparency. Today, SDK spend hides inside a flat subscription fee. You cannot easily answer "how much did my morning brief cost this month?" From 15 June, you can. Per-agent keys (we cover this in a moment) give you per-agent spend lines. A UK sole trader making real cost-allocation decisions on whether to keep an agent running can do that with real numbers rather than guesses.
No more silent throttling. A handful of heavy SDK users in 2025 hit unannounced throttling when their share of a shared pool got noisy. The new model is explicit: you have a budget, you can see it, when it is gone it is gone. No surprise 429s mid-build.
The cap protects you. UK indie hackers worry about runaway agent costs more than almost anything else - and rightly. The cap means a tight infinite loop on a Sunday morning cannot cost you GBP 400 by lunchtime. It can cost you, at worst, your subscription price. The Anthropic console daily cap on the key adds a second belt.
The honest downside: a small number of pre-15-June heavy SDK users were getting a remarkably good deal under flat-rate. Those users will pay more from June. If you are one of them, you already know. Most UK indie hackers are not in that bracket.
The four-week plan: what to do before 15 June
Four concrete actions for the runway. None of them takes more than an hour. All of them pay off the day the split goes live.
1. Audit which scripts are interactive vs headless
The split hinges on this distinction. Spend twenty minutes walking your stack and write a list. For every script, cron job, scheduled task, webhook handler, and Discord bot that touches Claude, ask:
- Is a human sat in front of the terminal when this runs?
- If yes, it is interactive (Pool A). Tagged.
- If no, it is programmatic (Pool B). Tagged.
A simple table for your own records:
| Script | Trigger | Pool from 15 June |
|---|---|---|
claude in ~/projects/sg-storefront | Me, opening a terminal | A (interactive) |
prompts/morning-brief.md via Task Scheduler at 06:55 | Cron | B (programmatic) |
Discord /review worker on Railway | Webhook | B (programmatic) |
Nightly QA run via claude -p | Cron | B (programmatic) |
gh pr review prompt I run by hand | Me, in a terminal | A (interactive) |
This document does not need to be pretty. It needs to exist. Once you have it, you know exactly which scripts will start drawing from Pool B and you can budget for them.
2. Tag every cron with its expected daily token spend
For each entry in your "B (programmatic)" list, get a rough daily token spend. The cheapest way is to run the script with --output-format json (see the headless claude -p scripting guide for the flag) and capture the usage block from the response. The response includes input_tokens and output_tokens per turn; sum them across the run.
Multiply by the model rate (Sonnet around GBP 2 per million input tokens at the time of writing; Opus around GBP 12) and you have a per-run pence figure. Multiply by runs per day, multiply by 30. Now you know what fraction of your Pool B each agent eats.
A real example from an indie hacker stack the author runs:
- Morning Companies House brief, daily, Sonnet, ~5k tokens: 3p/run, ~GBP 0.90/mo.
- Nightly QA agent across three repos, daily, Opus, ~40k tokens: 48p/run, ~GBP 14.40/mo.
- Discord
/reviewworker, ~10 reviews/week, Opus, ~25k tokens: 30p/run, ~GBP 12/mo. - Weekly competitor scrape, weekly, Sonnet, ~30k tokens: 6p/run, ~GBP 0.24/mo.
Total Pool B forecast: roughly GBP 27.50/mo. On a Pro plan with a GBP 20 cap, this user is GBP 7.50 over cap and needs to either move to Max, drop the nightly QA to Sonnet (which cuts that line to around GBP 3/mo and brings the total under cap), or enable overflow on the relevant key. The tag-everything exercise made that decision obvious in fifteen minutes.
3. Move to per-agent API keys
If you currently have one Anthropic API key powering everything, change that this month. The Anthropic console lets you create as many keys as you like, each with its own daily spend cap, each visible as its own line in usage analytics.
Recommended shape for a UK indie hacker:
claude-code-interactive- the key your CLI uses (rarely, but handy as a fallback).agent-morning-brief- just for the 7am cron.agent-nightly-qa- just for the QA worker.agent-review-bot- just for the Discord worker.agent-misc- for ad-hoc experiments and prototypes.
Each gets a daily spend cap matching its expected daily spend plus a 50% buffer. A runaway loop on the QA agent can only eat the QA agent's daily cap before the key fails closed. Your morning brief is unaffected. Your Discord bot is unaffected. You have isolated the blast radius.
This is the single highest-leverage change in the four-week plan. Ten minutes of clicking in the Anthropic console, ten minutes updating your worker .env files, and you have gone from one black-box bill to a per-agent cost line.
4. Decide the headroom question: which plan, with how much buffer
The cap means your plan choice now has a clear meaning. Pool B = plan price. So:
- GBP 20 Pro plan. Right for: a UK indie hacker with one or two production agents and modest daily volume.
- GBP 100 Max plan. Right for: someone running a small fleet of agents, a public-facing worker, or a team of two-to-five sharing.
- GBP 200 Max+ plan. Right for: a small studio running ten-plus agents or a properly active production workload.
The thinking move: forecast your Pool B (you already did this in step 2), pick the plan whose cap is at least 1.5x your forecast, and reassess monthly. The cap is generous enough that almost no UK indie hacker will need to move past Max+ in 2026, and the under-cap headroom is genuinely yours - you can fire up new agents without worrying about the spike.
Cache your system prompts where you can. The Anthropic API supports prompt caching, which can drop the input-token cost of a repeated system prompt by 90%. For an Agent SDK worker that runs the same scaffold prompt fifty times a day, that is a real, line-item reduction in Pool B consumption. The Agent SDK exposes caching options on the query call; spend an hour wiring them up and your cron-heavy scripts get measurably cheaper from day one.
What does not change
Worth saying for clarity, because half the internet got this wrong on 14 May.
- Interactive Claude Code is not metered differently. Sitting at a terminal typing
claudeis identical to today. - The CLI does not lose features. All the hooks, MCP servers, subagent dispatch, plan mode, slash commands - all unchanged.
- The Anthropic API is not changing. If you use the raw API for non-agent workloads, billing is identical to today.
- No model deprecations are tied to this date. Opus 4.7, Sonnet 4.7, Haiku 4.5 all stay live.
The change is one specific thing: the source of credits that fund a specific kind of usage. That is it.
The bigger picture
The split says, explicitly, "we know you are building production agents, and we are pricing that as a first-class product rather than a fringe use of a developer CLI." Expect agent-specific features - improved caching primitives, agent-specific dashboards, tighter MCP integration - to land first in Pool B contexts.
The takeaway: this is Anthropic telling you the Agent SDK is the future and worth building on. The pricing change is the receipt.
Do the four things in the next four weeks: audit, tag, isolate keys, pick the plan. From the 15th onwards, every Claude-powered side project you ship has a clear, per-agent cost line - which means you can ship more of them, with confidence, without wondering at the end of the month where the budget went.
New here? IdeaStack publishes one deeply researched UK business opportunity every Thursday - real keyword data, competitor analysis, builder prompts. See the latest free report.
Frequently asked
What exactly is changing on 15 June 2026?
Anthropic is splitting Claude Code usage into two pools. Interactive use of the Claude Code CLI stays under your Pro or Max subscription with the same effective unlimited model. Programmatic use - Agent SDK calls, claude -p headless runs, anything called from code - moves to a separate monthly credit pool billed at API rates but capped at your subscription price. You will not pay more than your plan price for the SDK pool, but spend is now itemised.
Will I pay more after 15 June 2026?
Most UK indie hackers will pay the same or less. The cap on the SDK pool is your subscription price, so a Pro plan at GBP 20 a month tops out at GBP 20 of programmatic spend in that month - no surprise overage. If you are currently a heavy SDK user the cap protects you. If you barely use the SDK you will see the unused pool itemised but it does not stack onto your bill.
Does this affect claude -p scripts on my home PC?
Yes. Any invocation of claude -p that you call from a scheduled task, a cron, a hook, or another script counts as programmatic and draws from the SDK pool from 15 June. Interactive use - typing claude in a terminal and chatting - stays under the subscription pool. The distinction is whether a human is at the keyboard, not whether the tool runs locally or remotely.
Should I move to separate API keys per agent before 15 June?
Worth it if you run more than one production agent. Per-agent keys give you per-agent spend visibility in the Anthropic console, which makes the new itemised pool more useful. They also let you set per-agent daily caps so one runaway loop cannot eat the whole pool. Ten minutes of work, and you go from a single line on your bill to one line per agent. Worth doing before the split goes live.
What if my SDK usage exceeds the subscription cap?
Anthropic has confirmed the cap is hard - SDK calls beyond the pool either fail with a clear error or roll over to pay-per-token, depending on a setting you control. For UK indie hackers the safe default is to leave overflow off, which gives predictable spend. If you have a worker that absolutely must serve a customer-facing endpoint, enable overflow on that key only, set a separate daily cap, and treat anything above the cap as a cost-of-goods-sold.
