Any risk that CLIProxyAPI calls are going to be flagged as SDK or -p sessions with these new rules?

[ironbelly]

[ultrano]

A few thoughts after digging through the executor code (internal/runtime/executor/claude_executor.go + helps/utls_client.go) and what Anthropic has actually announced for June 15.

Short version: if you register Claude through OAuth (not as an API-key provider), the project is already engineered to look like genuine Claude Code traffic at every layer Anthropic can cheaply inspect. Day-1 impact on round-trip usage should be minimal. The medium-term risk is pattern-based reclassification, not fingerprint-based.

What CLIProxyAPI actually sends upstream (OAuth mode)

• Endpoint: POST https://api.anthropic.com/v1/messages?beta=true — the same first-party endpoint Claude Code uses.
• Auth: Authorization: Bearer sk-ant-oat... obtained via the Claude Code OAuth client_id against claude.ai/oauth/authorize. The token is functionally equivalent to what the real CLI obtains.
• TLS: utls with HelloChrome_Auto over HTTP/2, scoped to api.anthropic.com. JA3/JA4 looks like a Chrome desktop, not Go's default crypto/tls.
• Headers (applyClaudeHeaders): Anthropic-Version: 2023-06-01, Anthropic-Beta pinned to the Claude Code 2.1.63 beta set (claude-code-20250219, oauth-2025-04-20, interleaved-thinking-2025-05-14, context-management-2025-06-27, prompt-caching-scope-2026-01-05, structured-outputs-2025-12-15, fast-mode-2026-02-01, redact-thinking-2026-02-12, token-efficient-tools-2026-03-28), X-App: cli, the X-Stainless-* SDK 0.74.0 tuple, X-Claude-Code-Session-Id (stable per token), and per-request x-client-request-id. Anthropic-Dangerous-Direct-Browser-Access is only emitted in API-key mode, matching the real CLI.
• Body shape: applyCloaking rebuilds the system array to match the real Claude Code structure — system[0] is the x-anthropic-billing-header (cc_version, cc_entrypoint, cch, optional cc_workload), system[1] is the agent identifier line, system[2] is the static Claude Code prompt bundle. Client-supplied system text is moved to the first user message and, in OAuth mode, replaced with a short generic placeholder so third-party prompt fingerprints don't leak.
• Body signing: signAnthropicMessagesBody computes cch = xxHash64(body, seed) & 0xFFFFF and substitutes it into the billing header. The real Claude Code computes this too; a missing or wrong cch is a clear third-party signal, which is why the project does it.
• Other body work that aligns with the real CLI: metadata.user_id is injected, cache_control breakpoints are auto-inserted if missing (capped at 4, with TTL ordering normalised), betas from the body are hoisted into the Anthropic-Beta header.

In other words: TLS layer looks like Chrome, HTTP layer and body look like Claude Code 2.1.63 with valid cch. Anthropic's cheap classifiers (header set, beta set, client_id, body schema, billing header presence + signature) all see "Claude Code".

Where the policy still creates risk

The June 15 split puts claude -p, GitHub Actions, and Agent SDK / third-party apps into a separate, hard-capped programmatic pool. Crucially, claude -p itself uses the same binary, same OAuth token, same cch algorithm, and same headers as interactive claude — yet it has to land in the new pool. So Anthropic must already have, or be about to ship, signals that distinguish interactive from programmatic behind the headers. Likely candidates:

1. cc_workload in the billing header. CLIProxyAPI plumbs it through (generateBillingHeader accepts a workload arg, sourced from the X-CPA-Claude-Workload request header), but the default is empty. Genuine claude -p likely sets something like print, and interactive claude likely sets interactive or similar. An empty workload is ambiguous and probably gets a default classification — which way that default points is the open question.
2. Traffic shape per token: 24/7 concurrent calls from one OAuth credential, no human-typing cadence, datacenter egress IP, etc. Headers and cch won't help against this.
3. cc_entrypoint parsed from the incoming User-Agent. Third-party clients (OpenClaw, Cline, Roo, etc.) don't send the claude-cli/x.y.z (external, cli) pattern, so the parser falls back to cli. cli is the safe default but not a guarantee.
4. The presence of sanitizeForwardedSystemPrompt already shows the maintainers assume Anthropic may look at body content, not just headers — that's a reasonable assumption and worth keeping in sync.

Practical takeaways

• OAuth-mode usage on June 15: very likely unchanged. The project's fingerprint surface is already aligned with the real Claude Code, OAuth-side, all the way down to cch.
• Over the next 1–3 months: worth watching upstream response headers (x-credit-bucket, new 429 reason codes, anything new in Anthropic-Beta acks) and surfacing them in the management/usage UI. Any new beta token or signing field that ships in Claude Code 2.1.64+ should be mirrored here quickly to keep the interactive classification.
• Heavy non-interactive workloads: if upstream visibly starts routing third-party agent traffic into the new pool, splitting those workloads onto API-key mode is the clean fallback — that path is unaffected by the policy because it bills against the console account from day one.
• Don't add multi-OAuth round-robin to dodge caps — that increases the surface for pattern-based detection across tokens and risks the whole OAuth path being tightened.

So to answer the thread's original question directly: I don't see the new rules breaking the protocol or the OAuth round-trip itself, and the project already does the heavy lifting that keeps OAuth traffic indistinguishable from Claude Code at the request layer. The real exposure is behavioural reclassification over time, and that's mitigable by keeping the Claude Code fingerprint (especially cc_workload, beta set, and cch) in sync with whatever the official CLI ships after June 15.

[ultrano]

If I understand correctly, it's like a usage-pool going to be seperated to two usage-pool(interactive and programmatic).
after 6/15, cpa would use interactive-pool as it does so long.
the matter is "what about programmatic-pool?".
I think, cpa might able to use the programmatic-pool too(cuz there is api provider for claude exist).
... or not i'm not sure :) haha

[ironbelly]

Except the programmatic pool is billed at API usage rates, while interactive at the same rates we enjoy now