As an indie developer running a pipeline that generates articles every night on a schedule, one date has been sitting at the back of my mind for weeks: June 15, 2026. From that day, the Claude Agent SDK, headless claude -p, Claude Code GitHub Actions, and third-party agents leave the old subscription limits behind and move to monthly credits billed at API rates.
The first time I read the announcement, I'll be honest—I couldn't immediately picture what in my own pipeline would cost how much, and when. Maybe you're in the same place: unsure whether interactive Claude Code stays the same, whether only the background jobs are affected, left with a vague unease and no clear line. With two days left, here's what I worked out while auditing my own setup.
What actually moves to "monthly credits"
The heart of the change is the unit of billing shifting from "subscription usage limits" to "credits handed out each month." Four things are in scope:
- Custom agents you wrote with the Claude Agent SDK
- One-shot runs via
claude -p(headless mode) - Claude Code GitHub Actions
- Third-party agent integrations
Put the other way around: the ordinary Claude Code session you open interactively in a terminal or IDE is not the direct target of this change. That's exactly where I got it wrong at first. I had braced myself for "all of Claude Code is getting more expensive," when the line was actually drawn only around runs that fire automatically, with no human at the screen.
From what's been reported, the monthly credit allowances correspond to roughly $20 for Pro, $100 for Max 5x, and $200 for Max 20x—and they don't roll over. That last detail matters for how you design your operations. Since unused credits don't carry into the next month, lopsided patterns like "run all my batches at the start of the month" become more wasteful than before.
First, count how many jobs run unattended
Before reading the pricing details, the first thing I did was take inventory of my setup. I had never actually counted how many times a day I was launching Claude with no human present.
The test is simple: is a person watching the screen and directing this run, or does it fire on its own? Only the latter is in scope this time. Open your crontab and CI definitions and surface every line that contains claude -p, every script that calls the Agent SDK, and every GitHub Actions workflow.
# List everywhere a headless run is invoked
grep -rn "claude -p" ~/scripts ~/.config 2>/dev/null
# Check automated runs registered in crontab
crontab -l | grep -v '^#'
# Find workflows that launch Claude in GitHub Actions
grep -rln "anthropics/claude-code-action\|claude -p" .github/workflows/ 2>/dev/nullIn my case, two verification scripts I'd forgotten about were still dangling. I hadn't noticed they were running because they were the kind of job where nothing breaks if they fail. Under monthly credits, this sort of "running but producing no value" unattended job quietly moves to the side that drains your credits. The first goal of the audit was simply to find what to switch off.
Decide, job by job, whether headless still makes sense
Once the audit gives you a list, go through each entry and judge whether it deserves to keep running automatically. I used three criteria.
First, does the frequency match the value? A job you run daily but whose output you barely use can drop to weekly, or stop. Because credits don't roll over, the frequency you shave off simply becomes headroom.
Second, does failure require a human to check? A job that always needs a review isn't well suited to running fully unattended in the first place. Rather than firing it headless and inspecting the result later, leaning it toward an interactive session tends to waste fewer credits. In my pipeline, I kept generation itself headless but moved the rewriting of articles rejected by the quality gate to the side where a person decides.
Third, is the execution model the one you intended? Automated runs have no human eyes on them, so they can quietly grind away on an expensive model without anyone noticing. Under a credit system that hits your cost directly, so pinning the model used in automated runs is the safe move. I cover the exact mechanism in Pin Your Execution Model with enforceAvailableModels, but the point comes down to this: it's the unattended runs that most need their model stated explicitly.
Keep the remaining balance somewhere visible
With non-rolling monthly credits, the scariest outcome is exhausting your allowance mid-month and having automated runs stop dead. In the subscription-limit era it was hard to feel yourself approaching the ceiling, but with credits you want to stay aware of "how much is left" at all times.
I put the remaining balance and usage pace on my status line. The setup details are in Claude Code Statusline — Displaying Rate Limits and Building Custom Scripts. Just having the number always in view, I now notice early when I've been over-running verification jobs this week.
It also helps to decide, once and properly, which model goes to which job—it makes the credit drawdown far easier to predict. The thinking in Claude Code Model Selection Strategy is a useful reference for assigning models per job.
The minimum to do in the two days before June 15
Time is short, so here's the priority order. First, surface every unattended run with the grep commands above. Second, stop the automated runs that produce no value. Third, for the jobs you keep, pin the execution model and make the remaining balance visible. Even just these three will spare you a scramble on the day.
It's also worth keeping in a corner of your mind that Sonnet 4 and Opus 4 retire from the API on the same day. If your automation scripts hard-code those model names, they'll stop working as of June 15. When you run the grep audit, check for hard-coded model names at the same time.
I haven't yet watched the real cost after the migration myself. How monthly credits play out in my own operations is something I'll come back to once I've seen next month's numbers. If this helps anyone else running automation get their plan straight for the day, I'll be glad.