What Claude Codes New Pool 2 Billing Means for Agent-Heavy Teams

# What Claude Code's New Pool 2 Billing Means for Agent-Heavy Teams

Anthropic split Claude Code billing on June 15. If you run subagents, hooks, or any programmatic automation, your costs just changed shape.

The change is straightforward on paper: programmatic usage -- the Claude Agent SDK, claude -p headless commands, GitHub Actions, and third-party apps authenticated through the SDK -- now draws from a separate monthly credit pool instead of your interactive subscription. But the practical effect is a structural shift in how agent-heavy teams need to think about cost. The $100-$200 monthly Agent SDK credit that comes with a Max plan evaporates fast when a single parallel-agent session can burn through $8,000-$15,000 in 2.5 hours.

I have spent the last week reading the community analysis, the GitHub issues, and the support documentation to understand what this means in practice. Here is the breakdown.

What changed on June 15

Before June 15, all Claude Code usage -- interactive terminal sessions, subagent dispatches, headless commands -- counted against the same subscription usage pool. On a Max 5x plan ($100/month), that pool included a generous amount of included usage. The pricing was opaque in a different way (cache costs dominated real bills, not token rates), but at least it was one pool.

Now there are two:

• Pool 1 (Interactive): Terminal or IDE usage with a human at the keyboard. Draws from your subscription usage limits as before. Unchanged.
• Pool 2 (Programmatic/Agent SDK): Subagents, claude -p, the Claude Agent SDK (Python/TypeScript), GitHub Actions integration. Draws from a separate monthly credit. Unused credits do not roll over. Once exhausted, overage is billed at standard API rates -- but only if you have usage credits enabled. If you have not enabled them, requests stop until the next billing cycle.

The credit amounts per plan:

| Plan | Monthly Agent SDK credit |

| ---- | ----------------------- |

| Pro | $20 |

| Max 5x | $100 |

| Max 20x | $200 |

| Team (Standard) | $20 |

| Team (Premium) | $100 |

| Enterprise (seat-based) | $200 |

One important detail: setting an ANTHROPIC_API_KEY environment variable overrides your subscription entirely. Claude Code then authenticates with that key and bills as pay-as-you-go API usage, regardless of plan. If you have automated workflows that set this key, you may already be on API pricing without realising it.

The three documented cost catastrophes

The community has already documented the failure modes. Three events from late May, before the billing split, show what happens when agent-heavy usage runs without cost controls:

1. Subagent runaway at $7,000/day. A financial services company launched what they described as a "simple" code quality project using Claude Code subagents. The initial prompt spawned 23 specialised subagents that continued analysing and optimising code for three days. No automatic termination protocol existed. The bill hit $47,000 before anyone noticed. The structural failure was simple: subagent fleets do not inherit the same runtime limits as single sessions. Each agent runs independently, and there is no operator-side primitive that says "if no human input has arrived in 30 minutes, halt everything."

2. Parallel-49 $15,000 burn. A developer orchestrated 49 specialised subagents in parallel using Claude Code's slash commands. The session sustained 887,000 tokens per minute for 2.5 hours. Each agent burned approximately 18,000 tokens per minute. The estimated cost was $8,000-$15,000 for a single session. The developer described it as compressing 150 hours of senior-developer work into 2.5 hours, which is a genuine productivity gain, but the cost side was invisible until the bill arrived.

3. $6,000 overnight cache-TTL loop. A developer running Claude Code left a session running overnight. Automatic compaction events fired during the session, writing the full accumulated context to cache at roughly $4 per event. Combined with cache reads on every turn at $0.33 per turn (at 650K context), the overnight burn hit $6,000. The Claude Code token counter showed nothing close to this figure.

Why these events are more likely now

The June 15 change makes these patterns more expensive, not less. Before, subagent usage was included in your Max plan's blanket coverage. Now every subagent call draws from the Agent SDK credit pool, and once that credit is exhausted, you are paying full API rates.

Consider: a 49-agent parallel session burning 887,000 tokens per minute at Opus 4.8 rates ($5/Mtok input, $25/Mtok output). At a 3:1 input-to-output ratio, that is roughly $11 per minute. In 9 minutes you have exhausted the Max 5x plan's entire $100 Agent SDK credit for the month. After that, every minute costs $11 at standard API rates until you hit the billing dashboard.

The token counter in Claude Code does not show you this. It shows per-session token counts, not aggregate fleet velocity. It does not surface cache read or write costs. It does not tell you when you have crossed your Pool 2 credit limit.

What you should do now

There are practical controls you can install today. None of them require changing your workflow, just adding observation and guardrails.

1. Model tiering via subagent config. Not every subagent needs Opus. Set CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6 as an environment variable to default subagents to Sonnet. Reserve Opus for the subagents that genuinely need it. The cost delta is 3:1 on input ($3 vs $1 per Mtok for Sonnet vs Haiku, or $5 vs $3 for Opus vs Sonnet) and 5:3 on output.

2. Install a subagent budget guard. The open-source cc-safe-setup project includes a subagent-budget-guard.sh hook that tracks per-session parallel subagent count and warns when crossing a configurable threshold. It is advisory only -- it does not block -- but it surfaces the information the Claude Code UI does not.

3. Fleet-idle watchdog. If your team runs subagent fleets, install a watchdog that monitors aggregate fleet activity and halts the fleet when human input has been absent for a configurable window. Without this, an unattended fleet runs until the credit runs out.

4. Cache-hit monitoring. The biggest hidden cost is context-cache reads on every turn. Monitor cache_creation_input_tokens and cache_read_input_tokens in your session logs. If cache reads are consuming 90%+ of your token budget (which community analysis shows is common), consider shorter context windows or more aggressive session boundaries.

5. Enable usage credits with a hard limit. If you are on a Max plan, go to the Claude Console and set a monthly spend limit on your usage credits. This prevents the silent overflow scenario where Pool 2 exhausts and you start paying API rates without noticing.

Where Cost fits

This is the part where I disclose that I built Cost.botzone.ai, and it is relevant here for a specific reason.

The fundamental problem the June 15 change surfaces is that teams cannot see which agent runs cost what. Claude Code gives you a per-session token counter. It does not attribute cost per subagent, per workflow step, or per feature. If you run 10 subagents across 3 different projects, you have no way to know that project A's subagents are 6x more expensive than project B's.

Cost is an SDK that runs inside your infrastructure and attributes LLM cost per route, per feature, per workflow step. It is designed for exactly this problem: when you cannot see where the money is going, you cannot decide what to change. Cost gives you the per-agent-run attribution that Claude Code's built-in tools do not.

That said, even without Cost, the five controls above will save most teams from the worst of the Pool 2 surprises. Start with model tiering and a subagent budget guard. See how your bills look at the end of the month. Then decide if you need per-run attribution on top.

Have you checked your Claude Code usage since June 15? I would be curious to hear what your Pool 2 burn rate looks like.