New Agent SDK credits

[jfduhart]

What does the new pricing model starting june means for claudeclaw? Im a bit lost

[shashank-mugiwara]

Same here. Topping up on this. ClaudeClaw is being super helpful for me.

[TerrysPOV]

This is only really relevant if you are on a Team Standard, Team Premium or Enterprise plan. If you are on one of these plans then the new pricing applies to you. This will hit most for Enterprise plan users. If you are on a individual Pro or Max (5x/20x) plan there will be no change. See the table below for a summary:

Plan	Pricing logic	Practical meaning
Pro	$20/month, or $17/month annual	Individual productivity plan; includes Claude Code and Claude Cowork on Anthropic’s page. (Claude)
Max	From $100/month	5x or 20x more usage than Pro, higher output limits, priority access. (Claude)
Team Standard	$20/seat/month annual, $25 monthly	More usage than Pro, central admin/billing. (Claude)
Team Premium	$100/seat/month annual, $125 monthly	5x more usage than standard seats; includes Claude Code and Claude Cowork. (Claude)
Enterprise	$20/seat + API-rate usage	Lower headline seat price, but usage becomes the real cost driver. (Claude)

Does this answer your questions?

[christian-drescher]

Actually, according to the relevant article from Claude Support, Pro, Max, Team, and Enterprise plans are affected starting on June 15, 2026.

The key change is that ClaudeClaw usage will not count against your "interactive" use quota anymore, but against a separate quota for which you can claim a separate monthly credit. For instance, from their publication, the separate monthly credit will be 20$ on the Pro account.

What this effectively means for us is that ClaudeClaw (i.e., claude -p) will be billed at "extra usage"/API rates, but subscribers to Claude will receive a monthly credit.

Now, this credit will not be enough to cover your costs if your previous use of ClaudeClaw was exhausting the limits included in your subscription plan. If you trust the estimates circulating online, you are looking at a 2-10 fold increase of your costs.

[christian-drescher]

To address the question of the OP, for ClaudeClaw it means that

directly uses your Claude Code subscription

will not hold anymore. It will be billed at API rates like related projects (think OpenClaw), with the exception of a monthly credit for which you have to opt-in (but that will only get you started).

Of course, the web is looking at workarounds, like sending/reading to/from the interactive session. This would be a major overhaul of ClaudeClaw and - in a way - a new, separate project.

[frankniujc]

Category	ClaudeClaw	OpenClaw
Anthropic Will Come After You	Hmmm....	Yes

[TerrysPOV]

@christian-drescher is correct. I've just seen the point where the -p flag is no longer included as part of the subscription usage limits and now counts as part of the "credit" and when that is used jup API pricing applies.

[TerrysPOV]

Given the significant impact to users of this issue, I have begun architecting a solution using interactive sessions. This is going to be done over on ClaudeClaw+ to test it works first. I'm not going to implement here for now, as this really requires @moazbuilds to opine and he may be totally fine with it as it is. I have reached out to him to discuss. I will get an issue open on ClaudeClaw+ and will work on it over there. I'll post back here when there is something to share.

[aerolalit]

For anyone who does not want to move to API pricing after June 15: the change only affects programmatic usage (claude -p / Agent SDK). Interactive Claude Code sessions still run against your normal subscription limits, unchanged.

If a tool is driven by an interactive claude session instead of claude -p, the pricing change simply does not apply.

I built a separate project from scratch that works exactly this way — aerolalit/claudeclaw. It uses an interactive Claude session rather than claude -p, so it keeps running off your existing Pro/Max subscription with no API billing and no need to claim the monthly Agent SDK credit. It is a working alternative today for subscription users who want to keep going as-is.

[moazbuilds]

We're planning some approach to fully follow ToS while keeping this project alive after 15 june.

Will keep updated through issues.

Note: the terminal parsing in the interactive mode would be against ToS, we are planning something else.

[christian-drescher]

One avenue would be using Claude Code Channels (Telegram, Heartbeat/Cron daemon, etc) that is in research preview for some time already. When enabled, channels start and run with any interactive Claude Code session, but one would have to keep the interactive session running in the background (e.g., by using a terminal multiplexer such as tmux or screen). From what I see, @aerolalit did exactly that. No send-key to the interactive session, and no parsing.

I was hoping for a simpler/cleaner approach, though, leaving the choice of keeping the Claude Code interactive session to the user (tmux, screen, none), and simply start/resume the channels with Claude Code CLI.

[christian-drescher]

The challenge is to send scheduled messages to the interactive session. Claude Code has a mechanism for it, called /loop, which is what @aerolalit does. However, /loop has a problem: loops end automatically seven days after you start it. Instead of using /loop, I propose to use a custom channel that sends messages to the interactive session on schedule.

[aerolalit]

@christian-drescher spot on, on both counts — thank you for the careful read.

Yes, claudeclaw uses Claude Code Channels (research preview) running on top of an interactive session kept alive in tmux. The channels and the official scheduler are what drive it — no terminal output parsing. That is deliberate, exactly to stay clear of the ToS concern @moazbuilds raised.

And you are right about the /loop 7-day cap — recurring jobs auto-expire after 7 days and the heartbeat silently stops. I can confirm that from the CronCreate behavior. A fix is coming soon: the plan is to make the heartbeat self-re-arm before it hits the 7-day expiry (re-create the schedule from a SessionStart hook / the heartbeat tick itself), so it keeps running without manual intervention. A dedicated scheduling channel — the cleaner approach you described — is the longer-term direction.

[christian-drescher]

I have vibe-coded a scheduler-channel and combined it with the official Telegram channel (see christian-drescher/claude-plugins). Proactivity and Messenger integration can work beautifully like that.

The next challenge is maintaining the agent's identity in a Claude Code session that runs 24/7. What is your take @aerolalit and @TerrysPOV on integrating the identity of the agent?

Claudeclaw always appended to the system prompt with every message, so it was always in the context and always complete. I suppose this is going to be a different story when relying only on Claude Code's memory systems (CLAUDE.md and auto-memory). While CLAUDE.md is prepended to the first message of each session (thus, not reflecting changes to CLAUDE.md in an active session) and is being compacted away in long sessions, auto-memory requires the agent to actively look for it's identity.

[TerrysPOV]

@christian-drescher you are right to flag this and it is something that is being worked on as part of the work I'm doing over on ClaudeClaw+, which once complete and thoroughly tested, could provide the migration path for upstream (i.e. here).

The "append to every message" pattern worked for the old model because it was effectively a stateless wrapper around the API. In Claude Code that pattern blows the prompt cache and treats CC like a dumb pipe — fine for short tasks, expensive and slow for a 24/7 session. I'd push back on it being the baseline we're trying to recover.

Three distinct failure modes worth separating:

1. Compaction drops CLAUDE.md.

Solvable today with a PostCompact hook that re-reads CLAUDE.md (and any other identity files) and re-announces them as session context. Pay the cost when identity could decay, not on every turn. This is the easy case.

2. Mid-session drift before compaction fires.

The under-discussed one. Even when CLAUDE.md is technically still in context, in a long session the model's anchor for how it sounds drifts toward its own recent outputs, not the identity from turn 1. If the session never crosses the compaction threshold, the PostCompact fix doesn't help here.

The lightweight mitigation is a sparse UserPromptSubmit hook injection — a one-line "you are X" reminder every N turns, pulled from CLAUDE.md so there's a single source of truth. Tune N (every 20–30 turns feels about right) so it's cheap and rarely re-renders the cache. I've been experimenting with this exact pattern for another project and i'm confident this works.

3. Auto-memory is the wrong layer for identity.

Auto-memory is built around retrievable facts — the agent has to want to look. Identity needs to be pushed, not pulled. If you put "you are X" in auto-memory and trust the agent to retrieve it as the session ages, you've delegated drift-correction to the thing that's drifting, so I agree this is not the right tool for this problem.