Your Claude automation starts metering today (June 15). A quick checklist to avoid surprise charges

Update (June 16, 2026): After this article was published, Anthropic emailed eligible users to say it is not making this change, which had been set for June 15. For now, Agent SDK and claude -p usage continues to work with your subscription exactly as before, and there is no credit to claim. Subscription usage limits are unchanged. Anthropic says it will give advance notice before any future change takes effect.

So the "conversation vs automation" split described below is postponed for now. Whether the direction itself is withdrawn, or will return on a revised plan and timeline, is not clear from the current notice. The body below remains as an explanation of what was originally announced. Note that the official help page had not been updated at the time of writing and still shows the June 15 date.

A change to Claude's paid plans takes effect today, June 15, 2026. Your monthly fee is not going up. What changes is that usage which used to come out of a single pool splits into two: the part where a person is in a conversation, and the part where a program runs on its own. The details are in Anthropic's help center, and every number and scope in this post comes from that page.

Starting June 15, 2026, Claude Agent SDK and claude -p usage no longer counts toward your Claude plan's usage limits. Your subscription usage limits stay the same and stay reserved for interactive use of Claude Code, Claude Cowork, and Claude.

https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan

The side that gets affected is the second one. If you have been running automation inside your subscription plan, part of that usage leaves the flat-rate pool today and starts metering. To be precise, what you spend beyond a newly granted monthly credit either bills at standard API rates or stops. If you only chat through the app or the terminal, nothing changes for you.

The first thing to get right is which of your own usage is in scope. Get this wrong and you risk either stopping automation you wanted to keep running, or triggering charges you did not expect. This post gives you a checklist to avoid surprise charges as a same-day fix, then connects it to the larger question of how to design your automation from here.

What is changing

There is one line to draw: is a person typing and waiting for a response, or is a program calling Claude on their behalf? The former keeps using your subscription usage limits exactly as before. The latter is what the new monthly credit covers.

Here is the official breakdown.

If you open the app and chat, or type into Claude Code in the terminal and wait for replies, June 15 looks the same as before. Those keep drawing from your subscription usage limits and never touch the new credit. If that is you, there is nothing to do today.

The dividing line is whether you operate Claude by hand or have code operate it for you. Running claude -p from a shell script or cron, having a homegrown app built on the Agent SDK, wiring Claude Code into a GitHub Actions CI step. If any of these sound familiar, the checklist below is for you.

Why it split into two

Before the checklist, the background helps you make the call. Note that Anthropic has not stated the reason outright; what follows is my reading of what the announcement implies.

The flat-rate subscription pool let programmatic use, which should run on metered API pricing, run far more cheaply than it otherwise would. Unlike a conversation, automation is not bound by human typing speed. A script or an agent fires requests back to back without pausing, so token consumption climbs even within the same monthly fee. The flat pool absorbed that non-stop consumption. Run the same work through metered API pricing instead, and the gap widens the longer it runs.

In other words, the flat-rate plan was effectively subsidizing the cost of automation. Conversation has a natural ceiling because the human pauses; automation has no such brake. Keep both in the same pool, and the heaviest automation users get the biggest discount, while the gap between cost and price keeps growing.

Read the split as ending that subsidy and it makes sense. The conversational part stays inside the flat rate; the part where code runs on its own moves toward metering that tracks real cost. Conversation and automation went into separate wallets because their cost structures were different to begin with. It is less a price hike than a separation of things that had been mixed together.

This reading carries into the decisions later in the post. Automation is no longer an extra bundled into a flat rate; it has become something you design with cost in mind.

A checklist to avoid surprise charges

To sort out whether you are in scope and to avoid surprise charges or unexpected stops, here is what to check today. Go through it in order and you will know which side you are on and what to set.

First, check whether your day-to-day use is interactive or non-interactive. Chatting on the app or web, typing into Claude Code in the terminal or IDE and waiting for a reply, Claude Cowork. If that is all, you are out of scope and the rest is unnecessary. Most people stop here.

Second, find every place that runs on its own. Are you calling claude -p from cron or a shell script? Is there a homegrown script or app (Python or TypeScript) built on the Agent SDK? Is Claude Code wired into CI, GitHub Actions in particular? All of these are in scope. The ones running quietly in the background are the easiest to miss, so it is worth opening your job definitions, crontab, and repository workflows once to check.

Third, check the authentication path of any third-party tools. If an editor extension or an external agent tool is linked to your Claude account and authenticates through the Agent SDK on your subscription, it is in scope. Even if you never wrote claude -p yourself, a tool making non-interactive calls behind the scenes counts.

Fourth, check whether those authenticate via subscription or an API key. Automation that already authenticates with a Claude Platform API key is out of scope for this change. Pay-as-you-go billing continues, unaffected by the monthly credit. This is the final fork for whether you are in scope.

If you only use it interactively, there is nothing to do today. Only if you fall into automation, third-party tools, or the Agent SDK, and you are running on subscription authentication, do you move on to the next step.

If you are affected, what to do

What you do divides into two stages on a time axis: the same-day fix you finish today, and the deeper rework you take your time over. The first keeps automation from stopping, but it is a stopgap; the real solution is in the second.

Quick fix: claim the credit and decide how it stops

Eligible plans get a monthly credit. Officially it is called the "Agent SDK credit," but it is not limited to people writing the SDK directly. The claude -p calls in cron or CI, the GitHub Actions integration, and the third-party tools you checked above all draw from this same credit. Even if you never touch the SDK, if something runs Claude non-interactively, you are in scope. The credit equals your plan's monthly fee.

On seat-based Enterprise plans, Premium seats are eligible but Standard seats are not. You claim the credit once through your account (a one-time opt-in), and it refreshes automatically each billing cycle after that. From June 15, eligible users are said to receive an email with claim instructions.

Here the path forks. If you plan to keep using automation, the first move is to not miss that email and claim the credit. If instead you would rather avoid being charged for automation, or you are fine letting it stop, there is no rush to claim. It starts with deciding whether you will keep running automation at all.

Next, decide what happens once the credit runs out. Agent SDK usage draws from this credit first, and what happens beyond it depends on a setting. With "Extra Usage" enabled, the overage bills at standard API rates and automation keeps running. Without it, requests stop the moment the credit is exhausted and stay stopped until it refreshes.

For a production workflow you cannot afford to stop, enabling extra usage to keep it running is the safer choice, though it leaves room for an unexpectedly large bill. For experimental automation that can stop without hurting, you might deliberately leave it off and let the credit act as a spending ceiling that is never crossed. You weigh "how bad is it if it stops" against "how scared am I of surprise charges."

While you are at it, note the credit's constraints. It is granted per user and cannot be pooled or shared across a team. It resets monthly and unused credit does not roll over. If your team runs automation, the idea of "everyone drawing from one person's credit" does not work, and that is worth keeping in mind.

Deeper rework: choose the authentication path as a design decision

The quick fix was about getting by within the credit you are given. The deeper rework is reconsidering, from the ground up, which authentication path your automation rides on.

Anthropic positions the monthly credit as "sized for individual experimentation and automation." Read the other way, shared production automation is not expected to fit within the credit. In fact, Anthropic points teams running production automation to a Claude Platform API key. API-key usage is out of scope for this change: pay-as-you-go continues and no monthly credit is granted.

This is where the earlier "automation is no longer an extra" reading pays off. When you build automation, which path you put it on, subscription auth or API-key auth, has become a design decision that shapes both cost structure and behavior at the limit.

For light experiments or personal helper automation, the subscription credit covers it. The way it stops when the credit runs out works as a spending ceiling you never cross. For production automation that hurts when it stops, or workflows shared across a team, API-key auth is easier to handle: consumption shows up directly as billing so it reads cleanly, and you can manage the balance with auto-reload and usage alerts. Both stop when the balance runs out, but subscription auth is a flat pool tied to your plan fee, while the API key is a balance you fund yourself. To run something steadily in production, the API key, whose ceiling is not pinned to your plan fee, gives more operational freedom.

Objections worth raising

A few objections come to mind against the picture above. Let me raise them and answer each.

Objection 1: Just put everything on an API key

So why not put everything on an API key and stop worrying about two wallets?

There is something to this. Unify on an API key and conversation and automation both run on the same pay-as-you-go billing, with no need to watch a subscription credit and an API balance separately. But for conversation, moving to an API key tends to cost more. The subscription is designed so that, within your usage limits, conversation runs flat-rate and effectively unlimited. Move that to metered API pricing and every single conversational turn that used to be covered by your monthly fee turns into per-token billing. Keep conversation on the subscription's flat rate and split only the heavy automation onto an API key. That is the realistic landing point.

Objection 2: My automation is light, so it fits

My automation is light, so it fits within the credit I am granted, right?

In many cases, yes. If you only run a script now and then, the granted credit is enough. The problem is estimating "it probably fits" without knowing your own consumption. If you keep an agent running constantly or call it often in CI, you can use up the credit faster than expected. Even when the judgment that it fits turns out right, it is safer to confirm the basis once. Take the run frequency you found in the checklist and reconcile it against actual consumption on the billing screen after the change takes effect.

Objection 3: It is a price hike in the end

Whatever you call it, is this not a price hike in the end?

For users who ran heavy automation on the flat-rate pool, it is indeed a real increase in burden, because the part that was cheap moves closer to real cost. But this is closer to correcting a distortion than an unreasonable hike. Until now the flat-rate subscription subsidized the cost of automation, and the heavier the user, the larger the benefit. The split moves things toward how they arguably should be: conversation flat, automation at real cost. Conversation-centric users see no change in usage limits or feel; the ones affected are limited to the layer that had been benefiting most. It is not an across-the-board hike but the removal of a subsidy that had been riding along.

A good moment to revisit your automation design

Once the checking and the fix are done, what remains is a design question. This change is a good moment to revisit how you design your automation.

Even before this, there was a split in practice: API keys for automation built into production systems, subscription-authenticated Claude Code for scripts at hand. But as long as you ran on subscription auth, that choice never showed up in cost, because the flat pool absorbed it. From June 15, the choice of path feeds straight into cost and availability.

The more you build and run your own agents, the bigger the impact. There are three axes to judge by.

• Does it hurt if it stops
• Do you need consumption to be readable
• Is it shared across a team

Against these three, you sort which workflows stay on the subscription credit and which move to an API key. Light experiments that can stop use the credit as a spending ceiling; production or shared workflows you cannot stop go on an API key where consumption reads cleanly. The change is a good occasion to inventory your automation once.

Put plainly, the era of treating automation as something that "just runs, loosely, inside a flat rate" ends here. Until now, running an agent left its cost dissolved into the flat rate, out of sight. From here, cost follows automation everywhere. Since it costs more the more it runs, you will weigh, from the design stage, whether a given automation earns its cost.

The same-day fix is simple. Check whether you are affected, and if so, claim the credit and decide how it stops. That is all. What remains beyond it is the homework of how to watch the cost and value of your automation. The cost of automation, which had been hidden inside the flat rate, has come into the open. That, I think, is the real substance of this change.