Clarify/support interactive Claude Code CLI backend after June 15 Agent SDK billing split

[saxyguy81]

Context

Anthropic has announced a billing behavior change for Claude subscription users starting June 15, 2026:

• Claude Agent SDK usage and claude -p usage move to a separate monthly Agent SDK credit.
• Interactive Claude Code in the terminal/IDE remains on the normal Claude subscription usage limits.

Official sources:

• Anthropic Help Center: https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan
• Claude Code programmatic usage docs: https://code.claude.com/docs/en/headless
• Claude Code CLI reference: https://code.claude.com/docs/en/cli-reference

The Help Center language is explicit that the new credit applies to the Claude Agent SDK, claude -p, GitHub Actions, and third-party apps built on the Agent SDK, while it does not apply to interactive Claude Code in the terminal or IDE.

Current ccproxy behavior as I understand it

ccproxy currently appears to have two Claude paths:

1. claude_api / /claude/v1/...

   • Direct Anthropic Messages-style HTTP proxy backed by OAuth/API-style credentials.
   • This is not the interactive Claude Code terminal surface.

2. claude_sdk / /claude/sdk/v1/...

   • Uses claude_agent_sdk and ClaudeSDKClient(...).query(...).
   • The SDK itself spawns the official claude binary, but with an SDK entrypoint and non-interactive stream-json plumbing.
   • That means this path still appears to be Agent SDK usage, not normal interactive Claude Code usage.

Relevant files in current main:

• ccproxy/plugins/claude_sdk/client.py
• ccproxy/plugins/claude_sdk/adapter.py
• ccproxy/plugins/claude_sdk/routes.py
• ccproxy/plugins/claude_api/adapter.py
• ccproxy/plugins/oauth_claude/*

Question / feature request

Does ccproxy intend to support a third Claude backend that drives the official interactive Claude Code CLI session, i.e. claude without -p / without the Agent SDK entrypoint, for users who want requests to run through the same usage bucket as interactive Claude Code after June 15?

If yes, it would be useful to document the plan and expected limitations.

If no, it would be useful to document that:

• /claude/sdk is Agent SDK-backed and should be expected to draw from the new Agent SDK credit pool after June 15.
• /claude/v1 is API/OAuth-style proxying and not interactive Claude Code usage.
• ccproxy does not currently provide an interactive-CLI-backed API compatibility layer.

Why this matters

Users may reasonably assume that because claude_sdk uses the local Claude Code tooling, it is equivalent to using interactive Claude Code. The June 15 change makes that distinction operationally important.

A true interactive-CLI backend would probably be a very different implementation from the existing SDK adapter. It would likely need to manage one or more PTY-backed claude sessions, send prompts into the terminal session, parse terminal/transcript output, handle permission prompts/session state, and translate that into Anthropic/OpenAI-compatible HTTP responses. That sounds harder and less API-compatible than the SDK route, but the billing/usage distinction makes it worth clarifying explicitly.

Suggested outcome

One of:

1. Add documentation clarifying the current billing/usage implications of claude_api vs claude_sdk after June 15.
2. Add an explicit roadmap/non-goal statement for interactive Claude Code CLI backend support.
3. If maintainers are open to it, track an experimental claude_interactive backend separately from claude_sdk, with clear warnings about limitations and brittleness.

I am not asking for a billing workaround or ToS bypass. This is a request to clarify ccproxy's backend semantics and whether an interactive Claude Code backend is in scope.

[saxyguy81]

Following up on this because I could not find another public ccproxy issue or discussion tracking the June 15 Agent SDK billing split.

I re-checked current main and the public repo threads:

• /claude/sdk still appears to be implemented through claude_agent_sdk / ClaudeSDKClient, so it should be treated as Agent SDK-backed usage unless I am missing another code path.
• I do not see a PTY/session-backed interactive claude backend, i.e. a backend that drives the normal Claude Code terminal session without the Agent SDK / claude -p entrypoint.
• The only repo discussion I found is unrelated to this billing/backend distinction.

The operational question is time-sensitive because Anthropic says that starting June 15, 2026, Claude Agent SDK and claude -p usage draw from the Agent SDK credit pool, while interactive Claude Code in the terminal/IDE remains under normal Claude subscription usage limits.

Could a maintainer please confirm one of these?

1. claude_sdk is intentionally Agent SDK-backed and no interactive-Claude-Code backend is planned.
2. An interactive CLI backend is in scope, but not implemented yet.
3. There is already a branch or intended implementation path that I missed.

If the answer is 1, a short docs note would probably be enough to prevent user confusion. Suggested wording would be something like:

/claude/sdk uses the Claude Agent SDK and should be expected to follow Anthropic's Agent SDK billing/usage behavior. ccproxy does not currently expose an API compatibility layer backed by the normal interactive Claude Code terminal session.

I am not asking for a billing workaround or ToS bypass; I am asking for clear backend semantics so users can choose the right ccproxy route before the June 15 change takes effect.