Monday morning. I opened my inbox, saw Anthropic’s subject line “Important changes to Claude Agent SDK billing,” and before opening it I flipped over to another tab to pull up the dashboard and check how many times I’d hit claude -p this week.[1][2]
The number wasn’t shocking, but it wasn’t comfortable either, because I know my usage pattern isn’t typical.
“Starting June 15, 2026, Agent SDK and
claude -pusage on subscription plans will draw from a new monthly Agent SDK credit, separate from your interactive usage limits.”[1]
In other words: interactive Claude Code doesn’t change — typing at Claude in your terminal or IDE still draws from subscription limits, no problem. But the moment you reach for claude -p (non-interactive mode), the Agent SDK, Claude Code GitHub Actions, or any third-party Agent SDK app, June 15 onward all of that gets pulled from a separate monthly credit pool, billed at full API rates, and once the credit’s gone you just keep paying full API rates.[1][3]
The credit looks like this:
| Plan | Monthly Agent SDK Credit |
|---|---|
| Pro | $20 |
| Max 5x | $100 |
| Max 20x | $200 |
| Team Standard | $20 / seat |
| Team Premium | $100 / seat |
| Enterprise Premium | $200 / seat |
Community reactions split into two camps. One side says “fine, $200 free, the real point is carving out the cost of third-party wrapper abuse.” The other side translates this directly as “price hike” — because if you’ve been running heavy programmatic loads inside your subscription, June 15 is the day you start paying API rates the moment your credit drains.[3][4]
But what I want to talk about isn’t “is this a price hike or not.” For me, this email’s real meaning is that the unit of billing just changed.
What claude -p Actually Is in My Agent Team
If you’ve been following this series, you know my Agent Team isn’t the kind Anthropic specs out — “same codebase, multiple teammates reviewing the same PR.” My GM, Em, A7, A7sus4, C7 each have their own working directory, their own CLAUDE.md, their own skills, their own identity. They’re a team of specialists, not a team of workers.
The cost of this architecture: agents can’t talk to each other through a shared session — they have to talk through the filesystem. Em finishes a wiki ingest and drops a markdown into GM’s inbox. GM wakes up later, sees it, dispatches the next step to A7. In article 30 I used OS IPC as the analogy: a filesystem mailbox is just file + flock(), and an agent waking up to read its mailbox and rebuild context is essentially one TLB miss.
And the key that flips an agent from “not running” to “awake” is claude -p.
- A remote agent fired off by
/schedulewakes up at 3am and bootstraps viaclaude -pin non-interactive mode[5] - A hook-triggered sub-task (e.g., a file change that needs Em to sync the wiki) runs
claude -punderneath - Long-run persistence — “waking up still knowing how to work” — uses headless at the wake moment
- Even the audit scripts I write to do ad-hoc analysis on a git diff wrap
claude -p
For me, claude -p isn’t nice-to-have — it’s OS-level infrastructure.
So when every “wake a teammate” call on June 15 starts pulling directly from that $200 pool, this stops being a billing question. It becomes an architecture question — every dispatch, every hook, every schedule, things that lived in my mental model as “free” primitive operations, now each carry a price tag.
Code doesn’t have to be free of cost. But you’ll start to calculate: does this hook really need to fire? Does this sub-task really need to spawn? Does this scheduled job really need to wake every 30 minutes? The moment a billing unit invades your mental model, designs that used to flow start to stutter.
Right? This Is When You Start Looking at Codex
Right?
I already am. In OpenAI’s Codex Plugin for Claude Code I made the case: model and runtime are decoupling. Codex has its own codex CLI, its own headless mode, and its billing logic is either ChatGPT subscription (Plus / Pro / Business / Enterprise) with [research-preview] quotas, or an OpenAI API key that goes straight to API. There’s no “carve programmatic usage out of subscription and bill it again” mechanism — at least, not yet.[6]
For the past few weeks I’ve been moving some high-frequency, low-risk tasks to codex headless:
- First-pass wiki ingest (deciding whether an article is worth indexing)
- First-pass git diff audit (catching the obvious stuff)
- Late-night scheduled news research
It works better than I expected, because these tasks never needed the full surface area of Claude Code. They need “a headless agent that can read a prompt and emit structured output,” and at that interface layer it doesn’t much matter who delivers it.
So why haven’t I migrated everything? Three reasons:
- Skill / subagent ecosystem — my GM / Em / A7 live on top of Claude Code skills and agent definitions. There’s no 1:1 mapping. Migrating means rebuilding the identity system end to end.
- The filesystem-mailbox idiom — Claude Code’s hooks, CLAUDE.md hierarchy, and agent directory structure are deeply welded to my mailbox model. Swapping runtimes isn’t just swapping CLIs, it’s swapping idioms.
- Controllability — Codex’s system prompt and tool behavior aren’t Claude Code’s. The regression test cost of a migration isn’t trivial.
So my current strategy is mix, don’t replace: critical path stays in Claude Code (interactive, unaffected by the new billing); high-frequency headless gradually moves to Codex. The migration itself will be a worthwhile series — I plan to write about the migration map, idiom translation, the rakes I step on, and which pieces turn out to be runtime-agnostic versus locked-in.
There’s also another direction I haven’t covered: local models. If a headless task’s quality bar isn’t extreme, you can hand the sub-task to a local model (via Ollama / llama.cpp / your own inference server) — no API bill at all, just electricity. For high-frequency audit / classification / ingest workloads it’s actually enough. Local models aren’t a full replacement for Claude or Codex, but they can serve as the backend for a few specific teammates in your Agent Team — keep the flagship-grade reasoning in the cloud, push everything else local, and the total cost picture changes a lot.
I’ll write about that later. For now, back to Agent View.
A Quick Word on Agent View: Why It Isn’t What I Need
Same week, Anthropic shipped Agent View — May 11, Research Preview, available on Pro / Max / Team / Enterprise / API.[7][8]
The official pitch is plain enough:
“See at a glance which agents are waiting on you, which are still working, and which are done.”[7]
How it works: claude agents opens a dashboard, a list with one session per row showing status, last output, last interaction time. Inside any session you can press left to jump back to the view and Enter to dive into a session. Pair it with /goal (autonomous across turns) and /bg (background sessions), and the combo is designed to make parallel-session management smooth.
Most coverage frames it as “finally, a multi-agent dashboard.” But that framing presumes one thing: that your “multi-agent” means multi-session, not multi-identity.
Back to article 27: Claude Code’s Agent Teams is designed for “team of workers” — every teammate shares the same working directory, the same CLAUDE.md, the same skills, differing only in the spawn instruction. Agent View is the visual extension of that assumption — it shows you “what each worker is doing inside one codebase.”
That isn’t the same problem as my specialist pattern.
I don’t need “multiple sessions on one screen.” I need:
- A cross-identity observation window: what’s GM dispatching? How tall is Em’s inbox? Where did A7sus4’s last audit leave off? Each agent has its own working directory; state is scattered across the filesystem.
- Mailbox traffic visualization: who wrote to whom, when, was it read, are there stale messages sitting in inbox.
- Cross-machine, cross-time long-run observation: how to aggregate state across local + cloud schedule + Claude Code Cowork — the problem from article 34.
Agent View doesn’t cover any of that. It does something else — and does it well — it’s just not the gap I’m trying to fill.
The A7sus4 / Overmind observation layer is what specialist pattern actually needs, but there’s no off-the-shelf product for that yet. You have to grow it.
My Take
Maybe these two Anthropic moves, viewed together, reveal the direction more clearly than either does alone.
Carving claude -p into its own billing pool is the official declaration that interactive (human present) and programmatic (human absent) are two different products — different cost structures, different sensible usage shapes, different billing logic. Gluing them under one subscription was a transitional state, not a long-term answer. From Anthropic’s seat that’s reasonable — they need a mechanism to separate wrapper abuse from honest power users.
Agent View echoes the same direction on a different axis: orchestrating multiple interactive sessions is itself a product — hence the dashboard, /goal, /bg. How many claude -p calls you spin up behind the scenes is a separate axis.
For those of us who built our own Agent Team architecture, the combined takeaway is this: figure out which kind of multi-agent you actually have.
| Your pattern | What you should care about |
|---|---|
| Worker pattern (multiple sessions, one codebase) | Look forward to Agent View on 5/11; the 6/15 billing change has limited impact (you’re mostly interactive) |
| Specialist pattern (multi-identity, filesystem mailbox) | Agent View doesn’t address your pain; 6/15 billing hits your core primitives |
| Hybrid (both) | Evaluate both — especially which specialist actions can move to Codex / local model |
The practical suggestion is probably: before June 15, spend an afternoon listing every place you use claude -p, and mark which are critical path (must be Claude) and which are commodity headless (anyone can do it). For the commodity batch, start evaluating Codex, local models, or batching multiple tasks into one call. For the critical batch, accept the new billing logic and put it in the budget.
For Anthropic this is a reasonable product decision. For us, it’s a good reason to re-examine the architecture. The agent world has been decoupling anyway — runtime, model, and billing each going their own way — so a single Agent Team backed by multiple runtimes was always going to happen. June 15 just pulls that day closer.
References
[1] Anthropic Help Center — Use the Claude Agent SDK with your Claude plan: https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan
[2] Claude Code Docs — Run Claude Code programmatically: https://code.claude.com/docs/en/headless
[3] The Decoder — Claude subscriptions get separate budgets for programmatic use, billed at full API prices: https://the-decoder.com/claude-subscriptions-get-separate-budgets-for-programmatic-use-billed-at-full-api-prices/
[4] Hacker News — Claude subscription changes coverage of claude -p: https://news.ycombinator.com/item?id=48126281
[5] GitHub Issue #37686 — claude -p suggested to Max subscriber caused unintended API billing: https://github.com/anthropics/claude-code/issues/37686
[6] Zed Blog — What Anthropic’s New Claude Billing Means for Zed Users: https://zed.dev/blog/anthropic-subscription-changes
[7] Anthropic — Agent view in Claude Code: https://claude.com/blog/agent-view-in-claude-code
[8] Geeky Gadgets — Claude Code: Agent View, Goal Command, and Background Sessions Update: https://www.geeky-gadgets.com/claude-code-agent-view-update/
Support This Series
If these articles have been helpful, consider buying me a coffee