The Complete Guide to Claude Agent SDK Credits: How claude -p and GitHub Actions Billing Changes on June 15, 2026

Starting June 15, 2026, usage of the Claude Agent SDK, claude -p, and Claude Code GitHub Actions will no longer count toward your Claude plan's usage limits, and will instead be consumed from a dedicated monthly credit (the Agent SDK credit). The Agent SDK credit is a monthly allowance reserved for "programmatic use of Claude," granted to paid Claude plans at roughly Pro $20 / Max 5x $100 / Max 20x $200 per month. Your subscription's usage limits themselves stay the same and remain reserved for the "interactive use" of Claude Code, Claude Cowork, and the Claude apps (source: Anthropic Help Center).

The developers affected by this change are those running background automation with claude -p or the Agent SDK. Automated runs that were previously covered by your flat subscription allowance will, from June 15, be drawn from the credit pool — and once you exhaust it, you'll either be "billed at standard API rates" or "stopped." Which one happens depends on the "usage credits" setting on your account.

This article goes beyond explaining the announcement to serve as a practical guide on "what to check before June 15, and how to operate after." For how to implement the Agent SDK itself, see the Claude Agent SDK implementation guide; for the full Claude Code pricing structure, see the complete guide to Claude Code pricing plans.

What changes on June 15, 2026

The only thing that changes is the billing bucket for "programmatic use of Claude." Announced by Anthropic on May 14, 2026 (as reported by ITmedia) and taking effect on June 15, this change separates programmatic usage — which previously consumed your Pro or Max plan's usage limits — so that it draws from a dedicated monthly credit instead.

The credit applies to the following four usage types:

1. Claude Agent SDK use in your own projects (Python / TypeScript)
2. The claude -p command (Claude Code's non-interactive, headless mode)
3. Claude Code GitHub Actions (CI integrations for PR review, issue handling, etc.)
4. Third-party apps using Agent SDK authentication (external tools that authenticate with your Claude subscription)

Monthly credit by plan

Source: Use the Claude Agent SDK with your Claude plan (Anthropic Help Center)

The five rules of the credit

1. Granted per user (no pooling or sharing within a team)
2. No rollover (anything unused disappears at the monthly refresh)
3. Auto-refreshed in line with your monthly billing cycle
4. Requires a one-time opt-in (claim) the first time (subsequent renewals are automatic)
5. Credit is consumed before other billing sources

Why it was separated from the interactive allowance

Distilling the official explanation, the design intent is to protect the interactive allowance from being eaten up by background automation. Automated runs via the Agent SDK or claude -p can run 24/7 on cron or CI, so their consumption is an order of magnitude different from interactive use. When they share the same allowance, you end up hitting your usage limit on an interactive Claude Code session in the afternoon, right after you ran your automation. The two allowances are now fully separated and cannot be drawn against each other. If your automation exhausts its credit, interactive Claude Code keeps working — and vice versa.

Are you affected? A by-usage-type decision table

There is only one criterion: is a human interacting in real time, or is a program calling Claude automatically? Usage via an API key (pay-as-you-go) was already billed separately from your subscription, so it's unrelated to this change.

Concretely, three types of developers are affected.

Type 1: People running claude -p on cron or a scheduler. Morning report generation, periodic log analysis, automated content creation, and so on. Depending on execution frequency × consumption per run, the Pro $20 allowance may not be enough (see the estimates below).

Type 2: People using Claude Code in GitHub Actions. If you run automated PR reviews or issue triage under subscription auth, that consumption moves to the credit pool. A new design risk emerges: CI stopping when the credit runs out (anyone with PR automation or test automation built into CI should review this).

Type 3: People building products or internal tools with the Agent SDK. If you've embedded the Agent SDK into your own product and use subscription auth during development and testing, that falls under the credit pool. Note that if you use an API key in production, you're unaffected. The server-managed Claude Managed Agents assumes API keys, so it's out of scope too.

Conversely, if you only use Claude Code interactively in the terminal, or only add notifications or auto-formatting via hooks (hooks themselves don't consume tokens), nothing changes for you.

[Steps] Measure your automation cost before June 15

The first thing to do is not to plan countermeasures, but to measure "how many tokens of cost your automation consumes per month." Because credits are denominated in USD, only once you understand your consumption in dollar terms can you judge whether you'll "fit within the $20 allowance." Before June 15, you can measure while keeping your current operations running as-is.

Step 1: See recent session consumption with the /cost command

Running /cost inside a Claude Code session displays that session's token consumption and an approximate dollar conversion. If you have a script running via claude -p, just running the same prompt once in an interactive session and checking /cost gives you a sense of the per-run scale.

Step 2: See your monthly total on the Console usage screen

The usage screen in the Claude Console and the usage settings on your Claude account let you review your history. Because the display location for Agent SDK credit balance and consumption history will be finalized after the change takes effect (we'll update this article once confirmed), knowing where the current usage screen is beforehand will make post-migration monitoring smoother.

Step 3: Aggregate local logs with a community tool

Claude Code saves session logs locally (under ~/.claude/projects/) in JSONL format. Using a community-built CLI tool that aggregates these (such as ccusage, distributed on npm) lets you list daily and per-model token consumption with dollar conversions. Its biggest advantage is that you can back-calculate monthly consumption from the past one or two months of actuals.

# Example of a community-built tool (daily consumption aggregation)
npx ccusage@latest daily

Step 4: Break automation tasks down "by type"

Beyond the total, break it down to which task eats how much. It changes the resolution of your decisions.

• Task name (e.g., morning report generation, automated PR review, log analysis)
• Execution frequency (times/day)
• Approximate cost per run (from steps 1–3)
• Is it OK for that task to stop? (acceptable downtime)

This breakdown becomes the input to the decision framework below.

Worked example: koromo's daily article-generation routine

As a concrete example, koromo runs a routine (once daily) that starts a headless session via a remote trigger every morning at 9:00 to auto-create a draft PR for an SEO article. Here's how you'd apply the steps above to this type of automation.

1. Run the same instruction once in an interactive session and use /cost to gauge the per-run consumption scale (for long-output tasks like article generation, output tokens typically account for the majority of the cost)
2. Convert to a monthly figure with "per-run cost × runs per month (30 for daily)"
3. For automation that's once daily and about one article, Pattern A's calculation below is a reasonable yardstick. However, article generation is heavier on output tokens than a fixed-format report, so add the difference from Pattern A's assumption (5,000 output tokens) to your estimate. If you "process multiple articles or multiple repositories per run" or "use Opus," plugging your own measured values into the Pattern B/C formulas is more reliable

The point is that once you do this calculation at the start of the month, the rest is just pace monitoring. The measurement itself takes less than 30 minutes.

[Estimates] How many days will the credit last? Per-plan simulation

In short: light cron automation has plenty of headroom within the Pro $20 allowance, mid-scale operation including CI integration has its tipping point at Max 5x's $100, and running heavy agents on Opus won't fit even in $200. Below are transparent calculation examples using standard API rates (as of June 2026: Opus 4.8 input $5 / output $25, Sonnet 4.6 input $3 / output $15, Haiku 4.5 input $1 / output $5, all per million tokens; cache reads are about 0.1× of input. Source: Anthropic official pricing page). Cache-write cost (1.25× of normal input) is omitted for simplicity. Actual consumption varies greatly with prompt design and cache efficiency, so always cross-check against your measurement from the previous section.

Pattern A: Light cron (once daily, Sonnet 4.6)

Assume generating a fixed-format report once each morning. Input 50K tokens (90% cache reads), output 5,000 tokens.

• Per run: new input 5K×$3/M + cache read 45K×$0.3/M + output 5K×$15/M ≈ $0.10
• Monthly (30 runs): about $3 → plenty of room in the Pro $20 allowance (in theory you could run up to 6 times a day)

Pattern B: Mid-scale CI (10 runs/day, Sonnet 4.6)

Assume processing 10 automated PR reviews per day. Input 100K tokens (70% cache), output 8,000 tokens.

• Per run: new 30K×$3/M + cache 70K×$0.3/M + output 8K×$15/M ≈ $0.23
• Monthly (300 runs): about $70 → exhausts the Pro $20 around day 9 of the month. Max 5x $100 is the required line

Pattern C: Heavy agents (20 sessions/day, Opus 4.8)

Assume running long autonomous agents. Input 200K tokens (80% cache), output 20K tokens.

• Per run: new 40K×$5/M + cache 160K×$0.5/M + output 20K×$25/M ≈ $0.78
• Monthly (600 runs): about $470 → not enough even with Max 20x $200. Consider overage billing or migrating to API keys for the excess

An easily missed point: token volume and cost aren't proportional

In agent-style workloads, the bulk of input tokens are reads from the prompt cache. Because cache reads cost about a tenth of normal input, you routinely see an inversion where "the cache that accounts for 90% of token count is less than half of the cost." Before you panic that "we'll never have enough" based on token count alone, always measure in dollar terms. Conversely, automation where the cache isn't effective (a design that re-sends the full context every time) costs significantly more than these estimates.

Decision framework: four options

Once you have the gap between your measured monthly consumption and your credit allowance, you have four options. Which is right is determined by two axes: "the overage amount" and "how painful it is when it stops."

Diagnostic flow

1. Measured monthly consumption < 80% of the credit allowance → Option 1. Just decide whether to turn usage credits OFF for a "stop within the allowance" safe design, or leave them ON as insurance
2. You'll overrun, but within a few tens of dollars a month → Option 2. But be sure to check the "usage credits" setting and spending limit described below
3. Large overage, business-critical → Option 3. The Agent SDK keeps working with no code changes by simply switching authentication to an API key (set ANTHROPIC_API_KEY). For CI and production workloads, this is the proper path
4. You have a task where you thought "wait, do we even need this automation?" → Option 4. This change is a good occasion to take stock of your automation. Even a $0.5-per-run task is $15/month of waste if it's a report nobody reads

The important thing is that you can choose a different option per task type. A realistic answer is a combination like "the morning report stays within credits (1), PR review moves to an API key (3), and the experimental cron nobody used gets retired (4)."

Is "just switch to Codex" actually a solution?

In response to this change, some are considering migrating to other coding agents such as OpenAI's Codex CLI. The conclusion is that "migrating because of a pricing change" usually doesn't pay off. First, every vendor's subscription tends to place some restriction or separate allowance on automated and headless use; a service that lets you "run unlimited background execution for a flat fee" isn't structurally sustainable. Anthropic's change here is, more naturally, a road others will travel sooner or later. Second, migration carries the cost of rebuilding assets like CLAUDE.md, skills, hooks, and MCP configuration. Rather than paying the migration effort for a difference of a few tens of dollars a month, lowering consumption itself with the optimizations described below (model downgrades, cache design) is the more rational choice in most cases. You should consider switching only when you're dissatisfied with functionality or quality — not pricing.

[Steps] Opt-in and checking the "usage credits" ON/OFF

There are two setting checks to do before June 15. Both are done from your Claude account settings screen.

1. Opt in to (claim) the Agent SDK credit

Credits are not granted automatically — the first time, you need to actively receive them (opt in). If you reach June 15 without opting in, your claude -p and GitHub Actions jobs may stop working. Claim it from Anthropic's notification email or from your account settings. Once you've opted in, subsequent monthly refreshes are automatic.

2. Check the "usage credits" ON/OFF

This setting determines the behavior when credits run out. At the time of writing, "Settings → Usage → Usage credits" is said to be the relevant screen (the menu name and placement may change going forward; if you can't find it, look for the usage-related screen within your account settings).

• ON (enabled): After credits run out, the overage is automatically billed pay-as-you-go at standard API rates. Automation doesn't stop, but charges are incurred
• OFF (disabled): Once you use up your credits, requests via the Agent SDK stop. Automation won't run until the next month's refresh, but no surprise charges from credit overage are incurred

Which should you choose? The "stops" vs. "uncapped" trade-off

For personal development and experimental use, OFF is recommended. Automated runs of a coding agent can have accidents where consumption balloons to several times the expected amount due to retry loops or context bloat. With OFF, the worst case is just "automation stops until month's end," with zero monetary damage.

On the other hand, if your business can't have its CI or scheduled processing stop, you'll need ON — but in that case, also check whether a spending limit setting is available and, if so, be sure to set it to create a "doesn't stop, but isn't uncapped either" state. To prevent the "I suddenly found hundreds of dollars in charges" scenario, the combination of allowing overage billing and a limit is essential.

Cautions for GitHub Actions and team usage

Team operations have two pitfalls that individual use doesn't.

Pitfall 1: Credits can't be pooled

Credits are granted per user and cannot be summed or shared within a team. There's no "$500 allowance from 5 people at $100 each" — only the credit of the authenticated user running the CI job is consumed. In other words, consumption concentrates on the account used to authenticate GitHub Actions, and only that user's credit runs out first. Since there's currently no way to even out consumption variance among members, for CI use it's a cleaner design to migrate to an API key (managed under the team's budget) rather than piggybacking on a particular user's subscription auth.

Pitfall 2: CI stops when credits run out

With usage credits OFF, when credits are exhausted, Claude Code GitHub Actions jobs will keep failing until the next month. If automated PR review is at the "nice to have" level, a month's-end stop has minor real impact, but if you've built it into merge requirements, the whole team's development stops. For workflows used as merge blockers, finish one of the following before June 15: (1) migrate to API-key authentication, or (2) add a fallback that treats the review as skipped when the job fails.

Per-seat credits on Team plans

Team plans have different credit amounts by seat type (Standard $20 / Premium $100). Know who has which seat, and note that if the account running your automation is a Standard seat, its allowance is only the equivalent of a personal Pro ($20).

Five optimizations to make your credit last longer

Even the same automation can consume several times less credit depending on its design. Here they are in order of how worthwhile they are to revisit on June 15.

1. Downgrade the model — Opus is overkill for routine processing. Sonnet 4.6 is 40% less than Opus 4.8 (input $5→$3), and Haiku 4.5 is 80% less ($5→$1). Classification, extraction, and fixed-format reports are often fine on Haiku, and this alone can transform your estimate
2. Make prompt caching effective — Just structuring things so that invariant parts (system prompt, reference documents) are pinned at the front and per-run content is placed at the end can reduce input cost by up to roughly a tenth. Also note that if the cron interval is longer than the cache TTL (5 minutes to 1 hour), the cache has expired
3. Revisit execution frequency — Does that hourly job really need to run every hour? Running something hourly when daily would do is 24× the consumption just from that
4. Trim the output — Output tokens cost 5× the input rate. Simply changing a "detailed report" into a "diff-only changes report" drastically cuts output cost
5. Don't over-supply context — A design that reads the entire repository every time is wasteful even with caching effective. Insert preprocessing that narrows down to the target files before passing them in

Build a monitoring mechanism for your balance first

Just as important as optimization is making the balance visible. Because credits refresh monthly with no rollover, if you can see the pace of "what percentage you've consumed by what day of the month," you can notice exhaustion a week ahead. Concretely, two simple rules are enough: (1) build a habit of checking the Console usage screen once a week, and (2) temporarily reduce automation frequency if the monthly consumption pace exceeds "the elapsed-day percentage + 20%." With zero monitoring, you'll only notice when CI goes down due to month's-end credit exhaustion, and you'll spend extra time investigating the cause. Design it so you notice before it stops, not investigate after it stops.

Actual behavior from June 15 onward (updated as it takes effect)

This section will be updated continuously after June 15 with behavior, screen wording, and error messages confirmed in a real environment. As of now (June 13), what's confirmed from official information is the following.

• If opted in: consumption from claude -p, the Agent SDK, and GitHub Actions is automatically deducted from the credit (no code changes needed)
• If not yet opted in: programmatic use may be restricted (specific error wording to be confirmed after it takes effect)
• Credit exhausted + usage credits OFF: requests stop (what error appears in the CLI to be confirmed and added after it takes effect)

If claude -p suddenly stops working, first suspect the two causes "credit not opted in" and "credit exhausted." You can check the balance on the usage screen within your account settings (the exact display location will be added after it takes effect). If it stopped due to another error, refer to the reverse-lookup index in 50 Claude Code error fixes.

Frequently asked questions

Summary — a checklist for before June 15

This change is not a "price increase" but a structural shift in which, in exchange for protecting the interactive allowance, automation gets a clear ceiling. Here's what to do, organized.

• Determine whether your usage type is in scope (claude -p / Agent SDK / GitHub Actions / third-party apps)
• Measure your monthly consumption in dollar terms with /cost, the Console, and local-log aggregation
• Assign each of the four options (within credits / allow overage / API key / scale down) per task type
• Opt in to (claim) the Agent SDK credit
• Set "Settings → Usage → Usage credits" ON/OFF per your policy (OFF recommended for individuals; if ON, also check the spending limit)
• Review the authentication method of GitHub Actions workflows that are part of merge requirements

If you want to systematically grasp Claude Code from basics to operation, see the complete guide to Claude Code as well.

If you need support with introducing Claude Code or the Agent SDK in your organization, cost design for automation workflows, or API migration, feel free to reach out to koromo's AI development support service. We'll work alongside you from introduction through operational design, including the pitfalls that only become clear from real-world operation.