Proposal: revisit ralphex as a native Claude Code skill (no claude -p wrapper) in light of the new Agent SDK billing split

[rushisan]

Context: Anthropic's June 15 billing change

Anthropic notified Max 20x subscribers (email received today) that starting June 15, Max 20x plans will get a separate $200/month credit for Claude Agent SDK usage and claude -p, including third-party tools built on the Agent SDK. After that:

• Agent SDK / claude -p usage → drawn from the new $200 credit pool (and from explicitly-enabled "extra usage" beyond that). It no longer counts against subscription limits.
• Subscription limits → reserved for interactive Claude Code, Claude Cowork, and chat.

Today ralphex invokes Claude by shelling out:

claude --dangerously-skip-permissions --output-format stream-json --verbose -p "<prompt>"

This is unambiguously Agent-SDK-style usage. So under the new policy, every ralphex run will draw from the $200 SDK credit, not from the user's subscription quota — even though the user has a Max 20x subscription that may sit underused during long autonomous loops.

For users who want to spend their actual subscription on autonomous work (and who's biggest reason to buy Max 20x was exactly "I want to run agents a lot"), this is a meaningful regression in flexibility.

Proposal

I recall umputun mentioning on a recent Radio-T episode that he had experimented with packaging ralphex itself as a Claude Code skill rather than as an external orchestrator that drives Claude via -p. With the upcoming billing split, it might be worth revisiting that direction more seriously.

A skill-native ralphex would:

1. Run inside Claude Code, not as an external binary that spawns claude -p. The plan loop, state tracking, and prompts live as skill instructions plus helper scripts, executed within a single Claude Code session (with subagents where isolation is needed).
2. Be billed to the user's interactive subscription rather than the new $200 SDK credit — giving Max 20x subscribers a way to keep ralphex on the quota they're already paying for.
3. Delegate independent verification to a different skill / tool instead of spawning a fresh same-model claude -p review session. For example: an ask-codex / ask-gemini skill, or any external-LLM tool that's:

• genuinely independent of the executor (different model family — closer to true cross-checking, not self-marking),
• billed separately from Claude usage (no double-dipping on the same budget),
• composable with other skills as the ecosystem grows.

The existing plugin from #40 is essentially a marketplace wrapper that still requires ralphex on $PATH (skills check which ralphex). A skill-native ralphex would be a different beast — the loop logic would have to live in the skill itself, not in the Go binary.

Why this is worth raising now

The billing change is effective June 15, and "should I run ralphex against my subscription or against my SDK credit?" is going to become a recurring user question. Having a first-class skill-mode answer — even as an alpha / experimental — would give users a clean answer and would line up with the experiment umputun has already prototyped.

[umputun]

skill-native alternative already exists and covers most of what ralphex does: planning:exec in https://github.com/umputun/cc-thingz. It's a Claude Code skill that runs the full plan loop (tasks, review phases, finalizer) using subagents for isolation, lives entirely inside a Claude Code session, and bills against the interactive subscription rather than the SDK credit pool.

capability	ralphex (CLI)	planning:exec (skill)
form factor	Go binary spawning claude -p per task	skill inside Claude Code, fans out via subagents
billing	new $200 SDK credit pool (June 15+)	interactive subscription
fresh context per task	yes (subprocess)	yes (Agent tool subagents)
internal review pipeline	claude → external → claude	4 phases: full sweep (5 agents), code smells, external (codex), critical-only (2 agents)
external tool review	codex / custom script	codex / external_review_cmd
stalemate handling	review_patience (N unchanged rounds)	early-exit on no critical/major findings
finalize / rebase	yes	yes
stats summary	no	yes (token/duration/git churn)
worktree isolation	yes	yes
git + hg	yes (vcs_command)	yes (codex/finalize skipped on hg unless overridden)
plan creation	--plan interactive	planning:make (separate skill in same plugin)
multi-session web dashboard	yes (SSE)	no
notifications	telegram/slack/email/webhook/custom	no
alternative provider for main loop	codex/gemini/copilot wrappers via <tool>-as-claude	n/a (Claude is the runtime)
session/idle timeout, manual break	yes	bound to Claude Code session
rate limit wait+retry	--wait	n/a
long unattended runs	hours, terminal-independent	bound to Claude Code session lifetime
Bedrock support	yes (docker wrapper)	inherits Claude Code auth

bottom line: for the standard task → review → finalize loop, planning:exec is a viable alternative today. Where ralphex still wins: multi-session monitoring, notifications, alternative providers for the main loop, long unattended runs, and a few edge cases (stalemate via patience, rate-limit retry).

ralphex itself is staying a Go binary. The June 15 split is irrelevant for users on API-based billing, either directly via ANTHROPIC_API_KEY (see --preserve-anthropic-api-key) or via Bedrock (see docs/bedrock-setup.md). For Max subscribers there are workarounds at the ralphex level being explored right now that don't require a rewrite. More on that when it's settled. That said, there's no telling what Anthropic decides to cut next - heavy-work skills could end up on the chopping block too. Unlikely, but given the developer-hostile pattern so far, hard to fully dismiss.

re #3 (independent external review): codex/gemini/copilot wrappers and custom external-review scripts already cover this. See docs/custom-providers.md and the external_review_tool / custom_review_script config options.

[umputun]

also: this should have been a Discussion in the first place, not an Issue ticket. The Discussions tab is the right place for proposals like this.

moved