Before June 15: Which Claude Code Jobs Now Bill to the Agent SDK Credit
On June 15, 2026, the way Claude Code bills changes in a way that matters most to exactly one kind of user: anyone running self-hosted Claude Code agents on a schedule. From that date, claude -p and Claude Agent SDK usage stop counting against your subscription’s normal usage limits and instead draw from a separate, per-user monthly credit. If you run agents 24/7, you need to know which of your jobs moved buckets — because when the new credit runs out, those jobs stop.
This post maps it out: what changed, which dispatch paths bill to which bucket, and how to think about plan tiers across a fleet of agents on one machine.
What actually changed on June 15
Per Anthropic’s official guidance, starting June 15, 2026:
claude -p, the Agent SDK, and third-party apps built on the Agent SDK no longer count toward your plan’s interactive usage limits.- Instead, eligible plans get a separate monthly credit that only applies to Agent SDK usage: Pro $20, Max 5× $100, Max 20× $200 (Team and Enterprise also included).
- That credit refreshes with your billing cycle, does not roll over, and is per-user — it can’t be pooled, transferred, or shared across an organization.
- Agent SDK usage draws from this monthly credit first; once it’s exhausted, further usage only continues if you’ve explicitly enabled paid extra-usage. Otherwise it stops until the credit refreshes.
The headline for self-hosters: your interactive Claude Code session and your scheduled automation now bill from two different pools, and the automation pool is finite and non-shareable.
The question nobody’s answering: which of your jobs moved?
Most coverage of this change is a recap of the policy. The part that actually affects an always-on setup is concrete: for each way you invoke Claude, which bucket does it hit? Here’s the decision table for a typical self-hosted agent setup.
| How the job runs | Bills to | Notes |
|---|---|---|
| Your interactive Claude Code session (you, at the terminal or via a channel) | Subscription usage limit | Unchanged — this is “you using Claude.” |
A persistent agent session held open in tmux / a background process | Subscription usage limit | It’s still an interactive session under the hood, just long-lived. |
A scheduled claude -p one-shot (cron / launchd firing a headless run) | Agent SDK credit | This is the big mover. Every scheduled task you fire now draws the new credit. |
| Agent SDK code you wrote (a script importing the SDK) | Agent SDK credit | Same pool as claude -p. |
| Claude Code GitHub Actions / third-party apps on the SDK | Agent SDK credit | Counts against the same per-user credit. |
The pattern: anything a human triggers in the moment stays on your subscription; anything that fires headless on a schedule now competes for the fixed monthly credit. For a fleet that wakes agents on timers, that’s most of the automated workload.
What breaks when the credit runs out
This is the failure mode to design around. When the Agent SDK credit is exhausted and you haven’t enabled paid extra-usage, scheduled claude -p jobs don’t error loudly — they simply don’t run until the credit refreshes. A morning briefing that silently skips, a scheduled report that never lands. If you run unattended agents, budget the credit against your real cadence, or turn on extra-usage so jobs continue (at metered cost) past the limit.
Silent skips are the recurring hazard of unattended agents. A scheduled job that stops on an exhausted credit looks identical, from the outside, to one that died — which is why always-on setups need an independent liveness signal, not just “did the job run.”
Assigning plan tiers across a fleet
Because the credit is per-user and non-poolable, you can’t buy one big plan and spread it across ten agents’ worth of scheduled work. A few practical consequences:
- The credit is per Claude account, not per agent. Multiple agents that authenticate as the same account share that one account’s monthly credit. Splitting agents across separate accounts gives each its own credit — at the cost of separate subscriptions.
- Match the tier to the scheduled load, not the agent count. A fleet with light, infrequent scheduled tasks may live entirely inside a single Max credit; a fleet with heavy hourly automation will exhaust it and needs either a higher tier, separate accounts, or extra-usage enabled.
- Keep interactive and scheduled work in mind separately. Your day-to-day interactive use draws the subscription limit; your automation draws the credit. Sizing one doesn’t size the other.
How this works in Fleet
Fleet is the open-source, self-hosted platform for running persistent Claude Code agents on a Mac, and its design maps directly onto this split. Each agent holds a persistent interactive session (subscription limit) and also fires scheduled claude -p one-shots for timed work (Agent SDK credit) — so the two-bucket model isn’t abstract, it’s the daily billing reality of the setup. The same dispatch distinction that decides “which bucket” is the one Fleet already draws between a live session and a scheduled task.
If you want to see the dispatch patterns in code, Fleet is MIT-licensed and on GitHub.
Bottom line
Before June 15 — or right now, if you’re reading this after — audit your scheduled jobs. Anything firing claude -p on a timer now draws the per-user Agent SDK credit, not your subscription, and will stop when that credit is spent unless extra-usage is on. Size the tier to your automation cadence, remember the credit can’t be pooled, and put a liveness check on anything that runs unattended.
Next: if you’re running scheduled agents on a subscription, read up on the April 4 changes to subscription OAuth and keeping a headless agent alive across token expiry — both decide whether your 24/7 setup actually stays up. Or explore Fleet to see the whole persistent-agent stack.
Sources: Anthropic — Use the Claude Agent SDK with your Claude plan. Verified 2026-06-01; confirm current figures against Anthropic’s help center before relying on them.